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