Methode "Free" selbst implementieren (Assembler-Problem?)

[VizeTE]

Ich glaube ich habe jetzt eine bessere Methode und hoffe das die hier mehr Zuspruch findet :wink: [Nochmal vielen Dank an maximov, das war wohl der entscheidende Tip]
Ich übernehme einfach das Owner-Modell von TComponent.

Besitzt ein Objekt keinen Owner und wird meiner Liste hinzugefügt so wird automatisch die Liste als Owner gesetzt.
Besitzt es bereits einen Owner so bleibt dieser unangetastet. Soll das Objekt nie freigegeben werden so trage ich als Owner einfach sich selbst an. (Dann ist es quasi vogelfrei, wie mal irgendein Papst das ausgedrückt hat)

Wenn ich die Liste dann freigebe werden alle Objekte die der Liste gehören freigegeben, klar.

Und das Besete an der Lösung: Ich kann die Liste auch noch für alle von TComponent abgeleitete Elemente verwenden. Das ich da nicht gleich d'rauf gekommen bin! :wall:

Oder seht ihr hier Probleme?

[maximov]

Zitat:

Zitat von VizeTE

....
Besitzt ein Objekt keinen Owner und wird meiner Liste hinzugefügt so wird automatisch die Liste als Owner gesetzt.
Besitzt es bereits einen Owner so bleibt dieser unangetastet. Soll das Objekt nie freigegeben werden so trage ich als Owner einfach sich selbst an. (Dann ist es quasi vogelfrei, wie mal irgendein Papst das ausgedrückt hat)
...

Sich selbst als Owner zu setzen ist vielleicht ein bisschen unglücklich. Das könnte zu rekursionen führen, die nicht gewollt sind. Ich würde den einfach NIL setzen, als zeichen das er niemanden gehört.

An sonsten hört sich das vernünftig an :)

[VizeTE]

Zitat:

Zitat von maximov

...Ich würde den einfach NIL setzen, als zeichen das er niemanden gehört.

mmm...dann muß ich aber den Ansatz verwerfen, daß Elemente die einer Liste hinzugefügt werden und keinen Owner haben automatisch Kinder dieser Liste werden. :cry:

[maximov]

Zitat:

Zitat von VizeTE

Zitat:

Zitat von maximov

...Ich würde den einfach NIL setzen, als zeichen das er niemanden gehört.

mmm...dann muß ich aber den Ansatz verwerfen, daß Elemente die einer Liste hinzugefügt werden und keinen Owner haben automatisch Kinder dieser Liste werden. :cry:

Warum? Das bietet sich doch erstrecht an:

Delphi-Quellcode:

procedure liste.fügehinzu(element)
begin
  TuInListe(element);
  if element.besitzer = nil then
    element.besitzer = mirSelbst;
end;

oder so. Frage mich wo das problem liegt. Allerdings kenne ich deine implementierung auch nicht.

[VizeTE]

Zitat:

Zitat von maximov

Warum? Das bietet sich doch erstrecht an:

Delphi-Quellcode:

procedure liste.fügehinzu(element)
begin
  TuInListe(element);
  if element.besitzer = nil then
    element.besitzer = mirSelbst;
end;

Das Problem ist, daß ich bei dieser Implementation nicht festlegen kann, daß ein Element nie zu einer List gehören soll da jedes Element welches keinen Besitzer hat automatisch der List zugeordnet wird.
Würde ich das freie Element mit Owner=ichselber angeben so würde es nicht nil sein und von der Liste nicht adoptiert werden.

Meine Idee wäre es, den Owner nicht automatisch von der Liste vergeben zu lassen (obwohl das komfortabler wäre) sondern das beim Konstruktor als Parameter anzuhängen.

[maximov]

Aber irgend einen owner muss ein objekt doch haben. Und wenn es keinen habenm soll, dann füge es nirgends ein.

Zitat:

Meine Idee wäre es, den Owner nicht automatisch von der Liste vergeben zu lassen (obwohl das komfortabler wäre) sondern das beim Konstruktor als Parameter anzuhängen.

so wie bei TCompoennt? Dort wird es im prinzip ähnlich gemacht:

Delphi-Quellcode:

constructor TComponent.Create(AOwner: TComponent);
begin
  FComponentStyle := [csInheritable];
  if AOwner <> nil then AOwner.InsertComponent(Self); // <-- AOwner.InsertComponent
end;

...
procedure TComponent.InsertComponent(AComponent: TComponent);
begin
  ...
  Insert(AComponent); // <-- Insert
  ...
end;

...
procedure TComponent.Insert(AComponent: TComponent);
begin
  if FComponents = nil then FComponents := TList.Create;
  FComponents.Add(AComponent);
  AComponent.FOwner := Self;
end;

...nur das auf die prüfung verzichtet wird.

Aber, darf ich fragen, worauf dein klassen-model (fals du eins hast) im endeffekt hinaus laufen soll? Was willst du realisieren? Wenn wir das wissen, dann können wir das problem evtl. viel gezielter lösen :wink:

[VizeTE]

Hallo,

also mein Plan ist folgender...
Ich möchte eine List schaffen, welche Objekt beinhaltet und dabei möglichst flexibel und automatisch ihre Items verwaltet. Dabei soll berücksichigt werden, daß Items der Liste selbst wieder Listen beinhalten und deren Elemente eventuell ebenfalls freigegeben werden.

Meine ursprüngliche Idee mit den Elementen ohne Owner war die, daß auch Elemente in einer Liste hinzugefügt werden können ohne das sie zu jemanden gehören. Dazu hatte ich zunächst die Möglichkeit in Betracht gezogen einfach den Owner auf nil zu setzen. Dann könnte ich aber nicht Elemente die einer Liste hinzugefügt werden automatisch adoptieren. Alternativ könnte man ja auch die freien Elemente einfach das Objekt wo es ersetellt wurde als Owner mitgeben. Da bin nich mir aber noch nicht richtig schlüssig welche Variante die bessere ist.

[maximov]

Mit anderen worten: Du willst eine baum-komposition (Kompositum) realisieren -> http://www.dofactory.com/Patterns/PatternComposite.aspx

sowas? Der code dort lässt sich bestimmt leicht adaptieren.

Was mich interessiert ist, ob die objekte in deiner list nur eine liste haben sollen, oder mehrere? Kann ein objekt in mehreren listen enthalten sein?

Wenn ein objekt zB. in einer liste ist, die nicht der owner ist, so hat sie keine möglichkeit sich dort automatisch zu entfernen, wenn es freigegeben wird. Für dieses problem kann man prima Observer (oder Refenzzählung) einsetzen.

Wie auch immer. In TComponent sind beide konzepte verbaut (Child/owner und RegisterNotification). Das ist sehr lehrreich, auch wenn die implementierung schon fast als historisch betrachtet werden muss.

Machst du das nur just-for-fun oder dient das einem höheren ziel? Denn dann könnte man das noch ein bisschen konkreter betrachten :wink:

[VizeTE]

Zitat:

Zitat von maximov

Was mich interessiert ist, ob die objekte in deiner list nur eine liste haben sollen, oder mehrere? Kann ein objekt in mehreren listen enthalten sein?
...
Machst du das nur just-for-fun oder dient das einem höheren ziel? Denn dann könnte man das noch ein bisschen konkreter betrachten

Ja, Objekt sollen in mehreren Listen vorkommen dürfen und Objekte sollen selbst mehrere Listen haben können.
Zur Zeit mach ich das mehr oder weniger just-for-fun, mit dem Ziel, daß später ernsthaft einzusetzen. Von daher möchte und kann ich hier keine konkreten Ziele nennen. Ich versuche es möglichst allgemein zu halten um die Lösung dann später auf möglichst viele Probleme anwenden zu können.

Mit den Links zu den Pattern kann ich leider nichts anfangen. Entweder liegt das am Server oder am aspx (habe ich bisher noch keine Erfahrungen, muß ich da bestimmte Voraussetzungen erfüllen (PlugIns...)?). Aber ich denke der Referenzzähler kommt nicht in Frage da die Objekte ja auch ohne Liste existieren können sollen. Das andere Pattern muß ich mir dann nochmal anschauen.

[maximov]

OK! Da hast du dir eine schöne aufgabe gesucht. Willst du mit interfaces arbeiten, oder komplett ohne?

Ich würd das dann so machen, dass dein objekt lediglich eine beziehung zur deiner liste hast. Beim einfügen in die liste wird im objekt ein observer registriert, sodass die die liste benachrichtigt wird, sobald sich das objekt zerstört. Wird das objekt normal aus der liste entfernt, so kann es den der observer auch wieder aus dem objekt entfernt werden.

Jedes objekt kann jetzt soviele listen haben wie es will, da die listen die beziehungen managen. Ein objekt kann dan auch in vielen listen sein, denn wenn es sich ändert (zB. zerstört) dann werden alle listen benachrichtigt, in denen es enthalten ist. Wenn sich eine liste zerstört, so wird der observer entfernt, sodass sie nicht mehr benachrichtig wird. Alle listen haben immer ihr objekt als owner, sodass sie evtl. benachritigungen an ihn weiter geben können.

Die benachrichtigungen würd ich sehr allgemein halten (notify-basis-klasse), sodass nicht nur auf zerstörung, sondern auch auf andere änderungen reagiert werden kann.

Bleibt nur noch das problem mit den besitzverhältnissen. Evtl. macht es sinn, geweils einer list eine besondere bedeutung zu geben -> Child/owner liste! Evtl kann man hier eine ListenKlasse ableiten, die beim einfügen sich selbst als Owner im objekt setzt und wenn die liste zerstört wird, dann auch alle elemente zerstört.

:drunken:

...das sind jetzt nur meine ideen dazu. Das muss nicht so laufen. Gibt bestimmt noch andere wege/muster/techniken. Du könntest allerdings relativ schnell ein zyklisches problem kriegen, da sich die liste in den schwanz beissen können. Zumindest für den Child/owner baum solltest du zyklenfreiheit garantieren können :wink: