Referenzen auf ungültige Objekte

[Bernhard Geyer]

Mach es doch wie auch tausendfach in der VCL gemacht wird. Wenn du eine Zeiger auf ein objekt hast trägst du dich in die Notify-Liste für die Freigabe ein. Diese wird vor der Freigabe des Objekts durchlaufen und das andere Objekt kann seinen Member nillen.

[WM_CLOSE]

man sollte auch nicht vergessen, dass die "Pointer" in -NET keine klassischen Cardinal sind, sondern Klassen, so wie fast alles in .NET.
Da lassen sich Zeiger wunderbar um einen Notifier erweitern, dass allen anderen Zeigern sagt, dass sie jetzt ungültig sind.
Aber in Delphi sind die Zeiger ja Passiv.
Man könnte über Records diese .NET-Zeiger nachbauen, aber mit der IDE kann man dann vermutlich nicht mehr rechnen:
d.h. Kein InteliSense usw. Das Prob hatten wir scon mit den neuen Generics - andauernd fehler, die gar keine waren...
Und die Destruktoren für Records muss man dem Compiler auch erst mal einhämmern.(Aber gehen tut es)

[stahli]

@r2c2:
Mein Projekt arbeitet komplett mit Objekten. Diese beinhalten die Daten und die Geschäftslogik.
Obendrauf gibt es eine GUI-Ebenene zur Darstellung und Bearbeitung der Daten.

Die Objekte halten Referenzen aufeinander (ein Verein verwaltet eine Liste von Mitgliedern, jedes Mitglied enthält eine Instanz einer Person. Jedes Spiel hat zwei Spielparteien. Jede Spielpartei hat ein oder zwei Spieler. Jeder Spieler hat eine Referenz (keine Instanz) auf eine Person. Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Ich habe eine Lösung aus den beiden o.g. Punkten 1 + 2 realisiert. Dies funktioniert für meine Objekte schon sehr gut.

ABER ich halte z.B. auch in einem dynamischen Formular in einer Eigenschaft eine Referenz z.B. auf ein Turnierobjekt.

Wird dieses Turnierobjekt freigegeben, muss ich diese Formulareigenschaft explizit nilen - sonst geht das ggf. schief.

Wenn es dafür eine allgemeine Lösung gäbe, fände ich das hilfreich.


@Bernhard:
Das gibt es aber doch nur in Listen, meine ich!?
Oder kannst Du eine Lösung für mein o.g. Beispiel zeigen?


@WM_CLOSE:
Der Umweg über Records hört sich kompliziert an.
Ich hatte die Hoffnung, dass der Compiler (optional) einfach eine Liste der Referenzen anlegt und bei späteren Zugriffen "korrigiert".
Im Grunde mache ich das ja schon für meine Objekte, das ist aber noch nicht allgemein genug einsetzbar.

[alzaimar]

Ich kenne dein Konzept nicht, halte aber Referenzen, die -wupps- plötzlich invalid werden können, für kein gutes Design, auch wenn ich die Referenzen per Notify auf Nil setzen kann.

Deine Programmlogik kann dann an beliebigen Stellen gegen die Wand fahren. Du weisst nie, wann das der Fall sein wird, vielleicht sogar während einer elementaren Operation...

Wenn Du dir sicher bist, das dieser verteilte Zugriff
Du könntest diese Objekte auch über das Handle-Konzept realisieren:
Du instantiierst ein Objekt und bekommst von einer zentralen Vewaltung ein Handle zurück.

Du verwendest das dahinterliegende Objekt, indem Du es per Handle anforderst und automatisch gegen instantane Freigabe sperrst. Zum Ende der Verwendung gibst Du die Anforderung wieder frei.

Die Freigabe ist dann ein "gib es dann frei, wenn alle Anforderungen zurückgegeben wurden".

Du müsstest im Code nur dafür sorgen, das die Rückgabe so schnell wie möglich geschieht.

Delphi-Quellcode:

MyObject := ObjectManager.AcquireObjectByHandle(MyHandle);
If MyObjecty<>Nil Then 
  Try
    DoSomethingWith(MyObject);
    DoSomethingElseWith(MyObject);
  Finally
    ObjectManager.ReleaseObjectByHandle(MyHandle);
    // MyObject ist nun nicht mehr gültig
  End
Else
  Raise EHonestlyIDontKnowHowToHandleThis.Create;

[Lemmy]

Guten Morgen,

was spräche denn dagegen hier das Observer-Pattern einzusetzen? Der Observer wird vom Subject informiert wenn dieses freigegeben wird. Damit kann der Observer entsprechend reagieren und die Referenz entfernen...

Grüße

[stahli]

Ich versuche mal, auif die genannten Punkte einzugehen:

Grundsätzlich will ich voranstellen, dass ich die Objekte auf Dauer komplett im Speicher halte. Ich erzeuge diese also nicht vorübergehend, um eine Methode auszuführen.
Die Objekte bilden die gesamte Turnierstruktur ab und beinhalten die Daten.
(Alternativ will ich die Daten (Felder) in eine Datenbank auslagern, aber die Struktur und die Geschäftslogik soll in den Objekten abgebildet werden.)

Zitat von alzaimar:

Die Freigabe ist dann ein "gib es dann frei, wenn alle Anforderungen zurückgegeben wurden".
Du müsstest im Code nur dafür sorgen, das die Rückgabe so schnell wie möglich geschieht.
MyObject := ObjectManager.AcquireObjectByHandle(MyHandle);

Dies entspricht ja m.E. in etwa meiner angedeuteten Funktion IsValidObject, es erfolgt eine Prüfung, ob das Objekt noch existiert. Also dafür habe ich schon eine Lösung.

Zitat von Lemmy:

Guten Morgen,

was spräche denn dagegen hier das Observer-Pattern einzusetzen? Der Observer wird vom Subject informiert wenn dieses freigegeben wird. Damit kann der Observer entsprechend reagieren und die Referenz entfernen...

Grüße

Da habe ich ja eigentlich nichts dagegen, nur wollte ich gern eine weniger aufwendige Lösung.
Bernhard bezog sich ja (wie ich jetzt denke) auch auf BEISPIELE in der VCL.
Klar kann man das regeln. Aber man muss den betreffenden Objekten Listen hinzufügen, ggf. Schnittstellen definieren und gegenseitig aufzurufende Methoden implementieren.

Ich hätte eben gern eine mehr oder weniger automatisierte Lösung. Wenn ICH das für meine Objekte kann (es funktioniert ja grundsätzlich sehr gut), kann ich mir vorstellen, dass die Emba-Profis das auch allgemein regeln könnten. Die Programmierer müssten dann eben weniger auf Observer-Pattern setzen und könnten sich eine Menge Arbeit sparen.

Variablen (Pointer) können auf dem Weg ja auch nicht abgesichert werden.

Ein wenig könnte das wie FastMM laufen, das überwacht ja auch Zugriffe auf freigegebene Objekte. Vielleicht ließe sich darauf aufbauend ja eine Lösung finden, dass Referenzen auf solche Objekte genilt werden. So etwa waren meine Überlegungen dazu.

Zitat von Blup:

Das ist ein klassischer Fall für das Observer-Pattern und in der VCL auch so realisiert.
In allen existierenden Objekten nach einer Referenz zu suchen, halte ich für einen Designfehler.

Meine Lösung funktioniert halt diskret und ohne großen Aufwand im Hintergrund.
Eine Observer-Lösung für alle betreffenden Objekte wäre halt sehr viel aufwendiger.
Für alle "echten Datenobjekte" funktioniert meine Lösung ohne Probleme.
Nur wenn ich mal zusätzliche Variablen oder Eigenschaften nutze, unterliegen diese nicht einer "Bereinigung".

Zitat von r2c2:

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Zitat:

Zitat:

Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Versteh ich nicht.

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Zitat:

Zitat:

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Hier solltest du dir genau überlegen, was die Semantik des Löschens ist. Warum wird eine Person überhaupt gelöscht? Und wer tut das? Und was genau soll da passieren? Solche Probleme lösen sich oft durch die Beantwortung der folgenden Fragen:
- Zu wem gehört das Objekt?
- Wer ist dafür zuständig es frei zu geben?
- Wann und warum wird das Objekt freigegeben?

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.
Das Löschen wird durch den User veranlasst.
(Wann die Person nicht gelöscht werden darf (z.B. wenn sie schon gespielt hat) muss ich noch regeln - das wäre ja aber auch bei anderen Konzepten (SQL-DB) so).)

Zitat:

Im Idealfall hat man die folgenden beiden Fälle:
- Ein Objekt wird nur innerhalb einer Methode benutzt ==> Dann Create und Free mit try..finally in der Methode
- Ein Objekt gehört zu einem anderen Objekt (Komposition) ==> Dann create im Konstruktor und Free im Destruktur.

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

[r2c2]

Zitat von WM_CLOSE:

@Christian: es gibt theoretisch keine Pointer in .Net. Es gibt nur Referenzen.

Ja. Klar.

Zitat:

Auf diese Referenzen kann normalerweise nur das Framework bzw System.Object zugreifen.

Du meinst auf die Adresse, die hinter der Referenz steht. Ja.

Zitat:

Wie gesagt: Man könnte eine Klasse x und einen Record y herstellen. Record y wird sich, wenn ihm ein Wert zugewiesen wird bei der entsprechenden Instanz von x melden. Wird nun der Destruktor der Instanz aufgerufen, nilt er allen ys. eigentlich relativ einfach.

Das wären einfach die genannten Smart Pointer. Das heißt aber nicht, dass Referenzen selbst Objekte wären.

Zitat von stahli:

Zitat von r2c2:

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Ja, das ist klar. Aber dann hast du keine zusätzlichen Mitglied-, Spieler- und Schiedsrichter-Klassen. Sondern der Verein hat einfach ne Liste von Personen als Mitglieder. Vielleicht ist das bei dir ja auch schon so und ich hab dich einfach falsch verstanden. Solltest du Rollen brauchen, die im Verhalten von dem normaler Personen abweisen, bietet sich das Decorator-Pattern an.

Zitat:

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Das wäre ein klarer Fall für Events. Für was ne Funktion, die erst suchen muss?

Zitat:

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.

Dann passiert das einfach im Destruktor.

Zitat:

Das Löschen wird durch den User veranlasst.

Und welches Objekt ist dafür zuständig? Darum geht es.

Zitat:

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

Ja das ist klar. Aber hier stellt sich die Frage, was die fremden Objekte da zu suchen haben. "Don't talk to stragers".

- sind die "Fremden" weiter oben in der Hierarchie, können sie sicher sein, dass das Objekt noch exisiert. ggf. muss es über events benachrichtigt werden, aber oft ist noch nichtmal das erforderlich
- ist es niedriger in der Hierarchie, hat es das Objekt gar nicht zu kennen. Dann solltest du dein Konzept überarbeiten.
- ist es weder höher noch tiefer in der Hierarchie, sollte es entweder gar nix von dem Objekt wissen oder über Events benachrichtigt werden.

Das ist der normale Fall, so wie es alle Welt handhabt. Da etwas zu automatisieren, halte ich für gefährlich. Da werden Referenzen ungültig und ich krieg nix davon mit. Vor allem hat ein Objekt A nix an den Innereien von B zu schaffen. Das ist schon aus Prinzip eklig.

mfg

Christian

[stahli]

Zitat:

Zitat von stahli:

Eine Person gibt es nur einmal (mit Namen, Status etc). Diese Person kann Mitglied in einem Verein sein, Spieler in einer Mannschaft, Gastspieler in einer anderen Mannschaft oder sogar Schiedsrichter usw.
Deshalb wird dort die Referenz auf eine Person genutzt.

Ja, das ist klar. Aber dann hast du keine zusätzlichen Mitglied-, Spieler- und Schiedsrichter-Klassen. Sondern der Verein hat einfach ne Liste von Personen als Mitglieder. Vielleicht ist das bei dir ja auch schon so und ich hab dich einfach falsch verstanden. Solltest du Rollen brauchen, die im Verhalten von dem normaler Personen abweisen, bietet sich das Decorator-Pattern an.

Nein, ein Spieler und ein Schiedsrichter ist jeweils ein Objekt mit unterschiedlichen Eigenschaften und Methoden, dem jeweils eine Person "zugewiesen" wird (die Person ist dann wiederum eine Eigenschaft des Obektes - eigentlich ja nichts ungewöhnliches).
Die gleichen Zusammenhänge gibt es auch bei anderen Objekten. Egal warum nun ein Objekt freigegeben wird, sollen mögliche Referenzen darauf halt "angepasst" (genilt) werden.

Zitat:

Zitat:

Ist ein Spiel beendet, wird das übergeordnete Turnier veranlasst, die Platzierungen neu zu berechnen. Das Spiel kennt sein übergeordnetes Turnier aber nicht direkt. Das wird über eine Funktion ermittelt.

Das wäre ein klarer Fall für Events. Für was ne Funktion, die erst suchen muss?

Die Funktion durchläuft alle Owner ab dem Spiel und prüft, bis sie auf ein Turnierobjekt trifft.
Wenn ich ein Event verschicke, muss ich doch vorher auch den Adressaten ermitteln!?
Da erkenne ich keinen wirklichen Vorteil. Das ist auch eigentlich nicht mein Problem.

Zitat:

Zitat:

Das Personenobjekt wird gelöscht, wenn z.B. die Turnierveranstaltung gelöscht wird, da das Personenobjekt ein SubMember der Turnierveranstaltung ist.

Dann passiert das einfach im Destruktor.

Ja klar.

Zitat:

Zitat:

Das Löschen wird durch den User veranlasst.

Und welches Objekt ist dafür zuständig? Darum geht es.

Es ist doch rel. egal, wodurch ein Objekt gelöscht wird. WENN es gelöscht wird, will ich mögliche Referenzen darauf nilen.

Zitat:

Zitat:

Das habe ich ja so realisiert. Es geht mir ja aber um die fremden Zugriffe z.B. auf ein Personenobjekt, die nicht dessen Owner sind.

Ja das ist klar. Aber hier stellt sich die Frage, was die fremden Objekte da zu suchen haben. "Don't talk to stragers".

- sind die "Fremden" weiter oben in der Hierarchie, können sie sicher sein, dass das Objekt noch exisiert. ggf. muss es über events benachrichtigt werden, aber oft ist noch nichtmal das erforderlich
- ist es niedriger in der Hierarchie, hat es das Objekt gar nicht zu kennen. Dann solltest du dein Konzept überarbeiten.
- ist es weder höher noch tiefer in der Hierarchie, sollte es entweder gar nix von dem Objekt wissen oder über Events benachrichtigt werden.

Das ist der normale Fall, so wie es alle Welt handhabt. Da etwas zu automatisieren, halte ich für gefährlich. Da werden Referenzen ungültig und ich krieg nix davon mit. Vor allem hat ein Objekt A nix an den Innereien von B zu schaffen. Das ist schon aus Prinzip eklig.

Die Objektreferenzen sind ja nix ungewöhnliches. Macht ja schon DBGrid mit DataSource so. (Ich habe mir heute mal die Freigabeziehungen angesehen.)
Wenn die DataSource freigegeben wird, informiert diese halt (unter Zuhilfenahme komplexer Beziehungen, Listen und Methoden) das DBGrid, das dann seine Eigenschaft DataSource auf nil setzt.
Genau das passiert bei der Nutzung meiner Komponenten automatisch im Hintergrund, ohne dass sich der Programmierer darum kümmern muss.

Eine Lössung für meine Objekte habe ich damit, würde mir das aber auch als Grudsatzlösung wünschen.
Wenn Du das für gefährlich oder eklich hältst, dann muss ich das halt so hinnehmen.

Für lösbar halte ich das. Aber ok, ich gebe schon wieder Ruhe...


Dittsche hätte das aber sicher als Weltidee bezeichnet...

[Bummi]

Wenn Du eine eindeutige Referenz (1 Zeiger) hast kannst Du die Adresse im Konstruktor mit übergeben und im Destructor abräumen (auf nil setzen).
Allerdings kann es ja beliebig viele Kopien der Referenz geben (wie auch immer generiert/kopiert/zugewiesen) wer soll dann wissen was alles "genilt" werden soll.

[r2c2]

Zitat von stahli:

Mein Projekt arbeitet komplett mit Objekten. Diese beinhalten die Daten und die Geschäftslogik.
Obendrauf gibt es eine GUI-Ebenene zur Darstellung und Bearbeitung der Daten.

Das ist soweit vollkommen normal.

Zitat:

ein Verein verwaltet eine Liste von Mitgliedern,

OK.

Zitat:

jedes Mitglied enthält eine Instanz einer Person.

Huch. Wieso das? Ich denke doch eher ein Mitglied *ist* eine Person.

Zitat:

Jedes Spiel hat zwei Spielparteien. Jede Spielpartei hat ein oder zwei Spieler.

OK.

Zitat:

Jeder Spieler hat eine Referenz (keine Instanz) auf eine Person.

Und wieder: Ich denke eher ein Spieler *ist* eine Person.

Zitat:

Eine Funktion ermittelt übergeordnete Komponenten - Z.B. ein Turnier, in dem ein bestimmtes Spiel enthalten ist).

Versteh ich nicht.

Zitat:

Wird z.B. ein Personenobjekt gelöscht, müssen die anderen Komponenten, die eine Referenz darauf enthalten, diesen ungültigen Zeiger nilen.

Hier solltest du dir genau überlegen, was die Semantik des Löschens ist. Warum wird eine Person überhaupt gelöscht? Und wer tut das? Und was genau soll da passieren? Solche Probleme lösen sich oft durch die Beantwortung der folgenden Fragen:
- Zu wem gehört das Objekt?
- Wer ist dafür zuständig es frei zu geben?
- Wann und warum wird das Objekt freigegeben?

Im Idealfall hat man die folgenden beiden Fälle:
- Ein Objekt wird nur innerhalb einer Methode benutzt ==> Dann Create und Free mit try..finally in der Methode
- Ein Objekt gehört zu einem anderen Objekt (Komposition) ==> Dann create im Konstruktor und Free im Destruktur.

Dadurch ergeben sich Baumstrukturen von "gehört-zu-Beziehungen" und man hat i.d.R. keine Probleme mit der ganzen Freigeberei. Wenn man jetzt doch mal "außer der Reihe" ein Objekt freigeben will, stellt sich wie immer die Frage wer dafür zuständig ist und ob der weiß, wo überall Referenzen rumfliegen. Wenn du n Klassendiagramm postest, könnt ich mal drübergucken. Ich vermute, dass da was mit den Zuständigkeiten nicht passt. Observerpattern udn Events wurden bereits genannt. Das sind Möglichkeiten die Kopplung zu reduzieren und so das Problem gar nicht erst entstehen zu lassen.

//Nachtrag:
@WM_CLOSE: Seit wann sind Pointer in .NET Klassen? Ich hab zwar schon lang kein .NET mehr gemacht, aber das wär mir neu.

mfg

Christian