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.)
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.
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.
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:
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.