Zitat:
So kannst du das auch machen. Nur musst du dann Unterscheiden zwischen TPartnership-Objekten, die wirklich eine Partnerschaft darstellt, wobei ein Teil aber unbekannt ist und Einzelpersonen, die Kinder adoptieren. Da müsste man überlegen, was fachlich besser passt. Möglich ist aber beides.
Erklär mir bitte nochmal, wie Du dir das vorgestellt hast, verstehe ich nicht.
Möglichkeit a)
- Adoption ist keine Partnership, sondern was anderes ==> ne eigene Klasse
- Eine Adoption ist eine Beziehung zwischen einem Adoptivling und einem Adoptierer
- Adoptierer kann eine Einzelperson sein, aber auch eine "Familie" ==> eine TPartnership
- TGenealogyEntity ist Superklasse zu TPartnership und TPerson ==> Alle Objekte dieser Klasse - seien es jetzt TPersons oder TPartnerships - können adoptieren
Damit geschieht Adoption folgendermaßen:
- TGenealogyEntity hat ne Methode adopt(TPerson)
- adopt() erzeugt ein neues TAdoption-Objekt und registriert es bei Adoptivling und bei Adoptierer jeweils in einer Liste.
Möglichkeit b)
- Eine Adoption ist nur eine weitere Art Partnership; dazu verpasst du TPartnership ein typ-Feld, das es als Adoption ausweist; alternativ kannst du das auch tun, indem du TAdoption von TPartnership ableitest
- diese Partnership hat nun den Adoptivling als Kind in der Liste
Hier müssen aber ein paar Details berücksichtigt werden:
- Die Adoption-Partnership kann eine Person enthalten oder auch zwei; man kann ja auch als Einzelperson Kinder adoptieren
- Du musst aufpassen, dass du die Adoption-Partnerships nicht mit den normalen Partnerships mischst. Du kannst sie nicht mischen, weil du sonst nicht zwischen eigenen und adoptierten Kindern einer Partnerhip unterscheiden könntest. Du brauchst also für das verheiratete Ehepaar Alice und Bob, die bereits ihren biologischen Sohn Charlie haben eine weitere Partnership von Alice und Bob, wenn diese Doris adoptieren.
- Dadurch hast du eine bisher bestehende Invariante verändert. Bisher gilt ja, dass zwei Personen zu einem Zeitpunkt nur eine Partnership miteinander haben können. Sie können also nicht gleichzeitig zweimal miteinander verheiratet sein oder verheiratet sein, und gleichzeitig miteinander(!) uneheliche Kinder zeugen. Jetzt hast du ne Ausnahme in der Invariante drin. Bei Adoptionen geht sowas nämlich doch.
- Eine weitere Invariante kriegt ne Ausnahme: Bisher gilt: Eine Partnership gesteht immer aus zwei Personen. Es ist möglich dass eine der beiden unbekannt ist, aber es sind immer zwei. Jetzt kann es sein, dass eine Partnership aus nur einer Person besteht (was den Namen Partnersip ad absurdum führt).
- vielleicht gibts noch anderes zu beachten; wer weiß...
==>
IMHO ist Variante b) komplizierter, da die Invarianten komplizierter werden und schlechter nachvollziehbar/lesbar, weil Partnership auch Einzelpersonen beschreiben kann und nun auch Überlappungen existieren können. Ich würde also Variante a) empfehlen.
Zitat:
Zitat:
Between fehlt noch. Dazu braucht man nen weiteren TDate-Wert, nen Weiteren enum-Wert und ein paar weiter Invarianten.
Was wäre denn eine Invariante dafür? Mir fällt keine ein.
- wenn uncertainty <> ucRange ist (also der between-Fall), dann ist Value2 immer 0
- wenn uncertainty = ucRange ist, dann ist Value2 > Value1
Zitat:
Nun ist mir was Ein- bzw. Aufgefallen. Heirat, Scheidung, Geburt, Tod, Jugendweihe, Taufe etc. sind ja alles Ereignisse, nennen wir sie TEvents. Jedes Event besitzt ein Start- und ein Enddatum. Wäre es also nicht günstiger eine Klasse TEvents zu erstellen und ihr widerrum eine Variable zuweisen, die ihr sagt um welches Event es sich handelt (Hochzeit, Taufe...). So wird das auch im GEDCOM-Standard bearbeitet.
Nein, das ist keine allzu gute Idee. Warum? Wenn man so eine Klassifizierung einführt, muss man sie auch nutzen. Ansonsten ist sie nur unnötiger Overhead. Das ganze nennt sich "vapor class" (siehe hier:
http://www.christian-rehn.de/2009/08...hinen-und-ood/). Du nutzt die Abstraktion der "Events" nicht, sondern musst bei jedem Event wieder unterscheiden um was genau es sich nun handelt. Dadurch kriegst du fehleranfällige und vor allem unnötige if-Abfragen rein: "Wenn das ne Taufe ist, dann mal da Wasser hin, wenns ne Trauung ist, zwei Ringe und bei dem Sterbedatum n Kreuz und bei..." Das macht alles viel komplizierter. Du könntest jetzt sagen, dann leite ich eben Taufe, Trauung, Tod, etc. von Event ab und benutze Polymorphie. Das wäre wieder objektorientierter und du sparst dir die if-Konstruktionen. Einfacher macht es das aber trotzdem nicht. ==> Bleib mal lieber bei den einfachen Attributen.
Zitat:
Und nochmal zu einer alten Frage von dir, war ich nur 15 Personen im Stammbaum darstellen will. Wenn nach mir ginge, gern auch mehr Generationen, da ist jedoch das Problem mit der Bildschirmbreite & -höhe, dass muss man halt bei der erstellung eines solchen Controls beachten.
Kennst du Scrollbars?
Zitat:
Wie verfahren wir weiter?
Ergänze meinen Ansatz um alles Nötige. Operationen zum sterben, sich scheiden lassen, Ehen entfernen (wenn man falsche Daten hatte), ...
Das kannst du direkt im Diagramm tun. Wenn du aus irgendwelchen Gründen nicht so gerne das Zeug im Diagramm machen willst, schreib den interface-Teil des Codes. Also Felder und Methoden. Wenn du mir das Ergebnis zeigst, kann ich drüber gucken, eventuelle Probleme anmerken und danach beschäftigen wir uns mit der Datensepicherung.
mfg
Christian