property nur für klassen der selben unit schreibbar machen

cbs · Beiträge: 207 Erhaltene Danke: 1

huhu

ich hab ein object das mehrere objecte in einer TList verwaltet. das funktioniert soweit super. jetzt hab ich aber festgestellt das es programmtechnisch sinnvoll wäre wenn jedes object in der liste den eigenen index weiss, also die position an der das object in der TList liegt.

vom prinzip her hab ich das bisher so gelöst, das die procedure die ein neues object in der liste hinzufügt auch gleich den neuen index dem neuen object übergibt. da ich versuche das ganze so "sauber" wie möglich zu schreiben bin ich auf ein kleines problem gestossen

die eigenschaft INDEX sollte natürlich schreibgeschütz sein, da die liste ja ein object verwaltet und damit auch den index entsprechend setzt wenn ich ein object der liste hinzufüge oder verschiebe etc.

wie deklariere ich das nun am dümmsten in meiner klasse?

bisher wollte ich das so lösen (bsp)

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:

TObjectA = class (TObject)
private
  FIndex: Integer;
  {...}
public
  constructor Create(const Index: Integer = -1);
  destructor Destroy; override;
  property Index: Integer read FIndex;
  {...}
end;

TObjectB = class(TObject)
private
  FItems: TList;
  {...}
public
  constructor Create;
  destructor Destroy; override;
  function AddItem: TObjectA;
  {...}
end;

{...}

function TObjectB.AddItem: TObjectA;
var Item: TObjectA;
begin
  Item:= TObjectA.Create;
  Item.FIndex:= FItems.Add(Item);
  Result:= Item;
end;

da sich ObjectA und ObjectB in der selben Unit befinden kann ich direkt auf FIndex von ObjectA zugreifen. von "außen" geht es nicht da ich die property entsprechend schreibgeschützt habe.

lange rede kurzer sinn: mich stört jetzt das ich von ObjectB aus direkt auf eine Varibale von ObjectA zugreife. wie kann man das "vernünftig" lösen ohne das man von "außen" drauf zugreifen kann?

oder habe ich generell einen falschen ansatzt?

AndyB · Beiträge: 1173 Erhaltene Danke: 14 RAD Studio XE2

Warum musst du eigentlich von außen auf die Eigenschaft schreibend zugreifen? Kann sich TObjectB nicht komplett um die TObjectA Objekte kümmern?

_________________
Ist Zeit wirklich Geld?

cbs · Beiträge: 207 Erhaltene Danke: 1

AndyB hat folgendes geschrieben:

Warum musst du eigentlich von außen auf die Eigenschaft schreibend zugreifen? Kann sich TObjectB nicht komplett um die TObjectA Objekte kümmern?

jup so solls auch sein. nur objectB sollte schreibend auf die eigenschaft zugreifen können.

naja habs jetzt so gelöst das ich die IndexOf function von TList verwende um den index eines Objects zu ermitteln. so muss ich nicht mehr den aktuellen index im object selbst speichern. is nur ne frage wie schnell die suchfunktion von IndexOf ist :wink:

. aber andererseits müsste ich den index von allen objecten aktualisieren wenn ich ein object in der liste verschiebe. ich denke mal das is dann noch die bessere alternative.

aber trotzdem danke an die die sich darum ne rübe gemacht haben :wink:

oder bin ich wieder auf dem holzweg?

Shark · Beiträge: 87 98, XP D3, D5, D7

Warum leitest TObjectB nicht direkt von TList ab?
Sich den Index in dem Objekt selbst zu merken ist schlecht, da Du alle nachfolgenden Objekte eines gelöschten Objekts anpassen musst...

cbs · Beiträge: 207 Erhaltene Danke: 1

Shark hat folgendes geschrieben:

Warum leitest TObjectB nicht direkt von TList ab?

hmm ok ich versteh was du meinst..

ich erkenne aber nich auf anhieb warum das besser is. ich meine dann müsst ich ja zb die Add function von TList überschrieben da diese den index zurückgibt. ich hätte aber gerne das object selbst. aber evtl hab ich ja tomaten auf den augen :wink:

Shark hat folgendes geschrieben:

Sich den Index in dem Objekt selbst zu merken ist schlecht, da Du alle nachfolgenden Objekte eines gelöschten Objekts anpassen musst...

jup deshalb hab ich jetzt die lösung mit IndexOf gewält (also das object in der liste suchen)

mein vorbild für meine "architektur" ist das TListItems object. dort gibs eine property names Item die ein object TListItem über einen Index zurückgibt. das was mich so verwundert ist das das TListItem object auch eine eigenschaft Index und eine procedure Delete hat. woher weiss das TListItem den Index? oder wie kann es sich selbst aus der liste löschen?

es gibt zwar eine eigenschaft Owner vom typ TListItems aber mir is denoch nicht klar wie sich ein TListItem selbst löscht wenn ich Delete aufrufe.

jedenfalls soll mein ObjectA so änlich wie TListItem und ObjectB so änlich wie TListItems aufgebaut sein. mit änlich meine ich eigentlich nur das handling was ich super einfach finde. ein grossteil hab ich schon nachgebildet. aber wie gesagt mir leuchtet nicht so recht ein wie TListItem sich selbst löscht.

Shark · Beiträge: 87 98, XP D3, D5, D7

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

Type TObjectA = class(TPersistent)

private 
  List: TList;
public
  Delete;
...
function TObjectA.Delete: boolean
begin
  if List <> nil then
   if List.IndexOf(self) > -1 then
    begin
      List.Delete(List.IndexOf(self));
      result := true;
    end;
    ...  //freigeben

end;

Mal schnell hingetippt

Die Add-Methode muss man nicht überschreiben. Man kann ja einen anderen Namen nehmen...

cbs · Beiträge: 207 Erhaltene Danke: 1

ok danke Shark, habs geschnallt :wink:

mein gedankenfehler war, anzunehmen das objectA nix von objectB wissen muss, da objectB ja schon wieder was spezielles is.. TList zu übergeben darauf bin ich garnicht gekommen, super idee

thx

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme