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.
...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
mâxîmôv.
{KDT}