So, hier ist mal ein Grundgerüst. Die Arbeit von heute Nachmittag....
Es ist ausdrücklich nicht vollständig. Kleinkram hab ich weggelassen. z.B. hab ich zu den Personen nicht noch Eigenschaften wie Geschlecht oder Namenszusätze spezifiziert. Für die Idee sind die erstmal egal. Du kannst die dann selbst ergänzen.
Die Diagramme hab ich mit dem SoftwareIdeasModeler (
www.softwareideas.net) gemacht. Das Prog läuft auch unter nem aktuellen Mono, was für mich als Linuxer recht praktisch ist. Das Programm hat zwar auch seine Macken (z.B. lassen sich zumindest unter Linux reflexive Assoziationen nicht so richtig positionieren), aber es ist benutzbar. Das Projekt ist im Anhang. Kannst du dir angucken.
Die Klassendiagramme sollten eigentlich recht selbsterklärend sein. Ich hab versucht sie möglichst einfach zu halten. Wenn dir die Dinger nicht so geläufig sind, guck einfach mal in die Wikipedia. Die Grundidee ist eigentlich ganz einfach.
So, dann legen wir mal los:
Zuerst einmal bauen wir uns ein Domänenmodell. Wir bauen also einfach die relevanten Teile der Wirklichkeit nach.
- Es gibt Personen und die sind irgendwie miteinander verwandt.
- Interessant ist nun wie man miteinander verwandt sein kann. Wär ja zu einfach, wenns da nur Mutter-Vater-Kind gäbe. Also, was gibts denn da für Sonderfälle?
* Verwitwet und später nochmal geheiratet ==> Das sind zwei getrennte Familien
* Geschieden und später nochmal geheiratet ==> dito
* Annulierte/für nichtig befundene Ehen ==> haben nie existiert; werden behandelt wie uneheliche Partnerschaften
* Uneheliche Kinder/Seitensprünge ==> Das wird schon lustiger. Ne Familie is sowas ja wohl nicht. Sollte man wohl ne eigene Klasse dafür machen.
* Ungeklärte Vaterschaften ==> solche Kinder könnte man zur vermuteten/vorgeblichen/wasauchimmer Familie packen und ne Notiz drankleben. Oder man erstellt dafür ne Familie mit unbekanntem Vater. Hierzu könnte man Dummy-Objekte oder nil-Werte speichern. Oder man führt ne neue Klasse ein.
* Ungeklärte Mutterschaften sind vermutlich seltener, könnte es aber auch geben; manche Daten lassen sich historisch vllt. einfach nicht mehr rekonstruieren ==> wie ungeklärte Vaterschaften
* Künstliche Befruchtung und Austragen durch eine Leihmutter. ==> Äh... hm... Das wird wohl ein zusätzliches Attribut
* Inzest ==> Keine Familie aber dennoch eine "Verbindung"
* Adoptionen ==> Hmm... ein Adoptivkind hat biologische Eltern und Adoptiveltern. Zudem könnte es auch sein, dass unverheiratete Einzelpersonen Kinder adoptieren. Ne Adoption ist demnach wohl was separates, gibt also ne eigene Klasse.
* Achso: Und man könnte mehrmals von unterschiedlichen Leuten adoptiert worden sein.
Hab ich jetzt alle möglichen und unmöglichen Fälle?
Aber zumindest ist eins sicher: Jeder Mensch hat nen Vater und ne Mutter - mögen sie bekannt sein oder nicht. Da ist wohl kaum dran zu rütteln. Deshalb kriegt TPerson je eine Referenz auf nen Vater und auf ne Mutter.
Bei solchen Objektgeflechten hat man zwei Möglichkeiten: Jede Info nur einmal (DRY principle) speichern und dadurch Redundanzen vermeiden oder das Objektgeflecht leichter navigierbar machen, dann aber eine hohe Zahl von Invarianten in Kauf nehmen. Beides hat seine Vor- und Nachteile. Hier, würde ich sagen, müssen wir leider das DRY-Prinzip etwas verletzen, damit wir leichter navigieren können. Also beispielsweise nicht nur von den Kindern zu den Eltern, sondern auch umgekehrt.
Nächster Schritt: Was haben wir an unterschiedlichen "Verbindungen"? Ehe, uneheliche Partnerschaft, Seitensprünge, Inzestfälle, teilweise ungeklärte Fälle, ... Wir könnten das in eine Klasse packen und einen Typ mit speichern oder für jedes eine eigene Klasse nehmen. Zumindest aber Ehen haben zusätzliche Attribute: Ein Datum der Eheschließung; ein Datum der Scheidung (durch Tod, Gerichtsbeschluss oder wie auch immer das gehen mag); wenn du die auch noch erwähnen willst: Trauzeugen, u.ä. ==> Am einfachsten ist, wir unterscheiden Ehen und sonstige Partnerschaften.
Ich hab zwar von Genealogie keine Ahnung, aber teilweise kann es wohl sein, dass es Daten gibt, die einfach unbekannt sind. Oder nur ungefähr bekannt "muss vor 1350 gestorben sein", "geboren um 1720", etc. Deshalb bauen wir uns eine Klasse bzw. hier einen Record, der mit sowas umgehen kann. TVagueDate. Durch überladene Operatoren kann man sowas dann fast benutzen wie ein normales TDate. Solltest du ne ältere Delphi-Version ahben, die noch keine Operatorenüberladung gestattet, musst du dafür eben Funktionen schreiben.
Jetzt haben wir ein Domänenmodell. Das tut aber bisher noch nix. Jetzt brauchen wir Operationen, die das Objektgefecht aufbauen und verändern. Dabei tun das die Objekte selbst. Es wird nicht von außen etwas gebaut und dann an den Objekten geändert, beispielsweise eine marriedTo-Eigenschaft gesetzt. Das wäre nicht objektorientiert. Stattdessen machen die Tperson-Objekte genau das, was reale Personen auch tun. Sie heiraten. Also gibt es eine Methode
marry(TPerson)
. Das Prinzip nennt sich "Tell, don't ask!" oder "Do ist myself"-Prinzip. Die Objekte werden nicht von außen geändert, sondern sie machen alles selbst.
In deiner kleinen Modellwelt machen die Personen also alles genau so, wie echte Menschen:
Delphi-Quellcode:
// Pseudocode
var
Alice, Bob: TPerson;
Charlie, Doris: TPerson;
Peter: TPerson;
...
Alice.marry(Bob, Now);
Charlie := Alice.giveBirthToChildFrom(Bob, Now);
Doris := Alice.giveBirthToChildFrom(Bob, Now);
Bob.die(Now);
Alice.marry(Peter, Now);
Alice.die(Now);
Und genau das ist es, was die OO so toll macht. Man kriegt sehr schönen lesbaren Code. Den Code oben kannst du jemandem zeigen, der von Programmierung keine Ahnung hat und mit n bisschen Überlegen wird er ihn trotzdem verstehen. Und auch du wirst das besser verstehen, weil sich der Code im Idealfall (und das Beispiel oben ist ziemlich nah dran an diesem Idealfall) liest wie ein englischer Text.
Tell, don't ask sieht man hier ganz deutlich:
Alice.marry(Bob, Now);
"Alice, marry Bob now!" Wir sagen Alice, was sie zu tun hat und die wird das auch pflichbewusst tun. Prozedural würde das so aussehen:
Delphi-Quellcode:
// vereinfacht
Alice.marriedTo := Bob;
Alice.marriageDate := Now;
Bob.marriedTo := Alice;
Bon.marriageDate := Now;
Eigentlich würde das noch nichtmal reichen. Was, wenn Bob bereits verheiratet ist? Also müssten weitere Abfragen rein. Und das außerhalb von TPerson. Aber eigentlich sollten die Personen doch selbst wissen, wie man heiratet. Deshalb gehört der Code in TPerson rein und die Personen tun alles, was zum Heiraten nötig ist, selbst.
Wie würde TPerson.marry() nun aussehen? In etwa folgendermaßen:
Delphi-Quellcode:
// Pseudocode; gerade bei dem ganzen Moglichkeits-Gedöns müsste man nochmal drüber gucken
const
MAX_AGE = 150;
// it is supposed that there are no older people
UNCERTAINTY = 200;
// if a date is marked uncertain, it is uncertain w.r.t. this number of years in the one or the other direction
function TPerson.marry(AOtherPerson: TPerson; ADate: TVagueDate): TMarriage;
var
Exception: EMarriageImpossibleException;
begin
assert(AOtherPerson <>
nil);
//////////// first handle error cases ////////////////////////////////////
// prevent overlapping marriages:
if not (ADate.isUnknown
or ADate.isUncertain)
then
begin
for m: TMarriage
in Self.Marriages
do
begin
if (m.Start < ADate)
and (m.
End > ADate)
then
begin
Exception := EMarriageImpossibleException.Create('
Overlapping marriage');
Exception.ConflictingMarriage := m;
raise Exception;
end;
end;
for m: TMarriage
in AOtherPerson.Marriages
do
begin
if (m.Start < ADate)
and (m.
End > ADate)
then
begin
Exception := EMarriageImpossibleException.Create('
Overlapping marriage');
Exception.ConflictingMarriage := m;
raise Exception;
end;
end;
end
else
begin
// do nothing
// do not prevent marriage, if end of other marriage is uncertain or unknown
end;
// prevent marriage of probably dead people
if Self.isProbablyDead(ADate)
or AOtherPerson.isProbablyDead(ADate)
then
begin
raise EMarriageImpossible.Create('
Dead people cannot be married.');
end;
// prevent marriage of people probably not born yet
if Self.hasProbablyBeenBorn(ADate)
or AOtherPerson.hasProbablyBeenBorn(ADate)
then
begin
raise EMarriageImpossible.Create('
People have to be born before they can marry.');
end;
//////////// error cases handled, now do the actual work /////////////////
Result := TMarriage.Create();
// if there is already a partnership convert partnership to marriage:
for p: TPartnershup
in Self.Partnerships
do
begin
// partnership with this person
if ((p.Mother = Self)
and (p.Father = AOtherPerson))
or ((p.Father = Self)
and (p.Mother = AOtherPerson))
then
begin
if not (p
is TMarriage)
then
begin
Result.Assign(p);
// copy values
p.Free;
// can be freed here because all references to it will be replaced
break;
// there can be only one partnership
end
else
begin
// this cound be ether a former marriage with is person which has been devorced
// or an overlapping marriage; The overlapping marriage is prevented above
end;
end;
end;
// set values
Result.Start := ADate;
// homosexual marriages leads to random assignment to Father and Mother
// this is no problem as they won't get own children and adoptation
// is treated separately
if Self.isFeamle
then
begin
Result.Mother := Self;
Result.Father := AOtherPerson;
end
else
begin
Result.Mother := AOtherPerson;
Result.Father := Self;
end;
Self.Partnerships.Add(Result);
AOtherPerson.Partnerships.Add(Result);
assert(Result <>
nil);
assert(Self.Partnerships.
Contains(Result));
assert(AOtherPerson.Partnerships.
Contains(Result));
end;
function TPerson.isDead(ADate: TVagueDate): Boolean;
begin
Result := ADate > Self.DateOfDeath;
// overloaded operator '>' takes care that this is only true when the date is certain
end;
function TPerson.isProbablyDead(ADate: TVagueDate): Boolean;
begin
Result := isDead
or (age > MAX_AGE)
or (probableAge > (MAX_AGE + UNCERTAINTY));
end;
Genau so geht es mit divorce(), die(), giveBirthToChildFrom(), ...
Zusätzlich zu den offensichtlichen Methoden gibt es noch ein paar weitere. Personen können nämlich nicht nur Kinder kriegen, sondern auch Eltern. Also natürlich nicht "Guck ma, ich hab heut ne Mama gekriegt!", sondern dadurch, dass man Ahnenforschung betreibt und so neue Namen erfährt. Das muss natürlich auch noch rein. Über addParents z.B. kann man eine bestehende Partnerschaft als Eltern einfügen. addMother würde eine neue Partnerschaft erzeugen, die Mutter-Rolle spezifizieren, den Vater erstmal undefiniert lassen und die neue Partnerschaft als Eltern der Person eintragen. addFather ebenfalls. Wenn addFather ausgeführt wird, wenn schon ne halbe Partnerschaft da ist (Mutter bekannt, Vater noch nicht), wird natürlich die bestehende Partnerschaft genutzt. Und wenn der Vater bereits bekannt ist, aber trotzdem addFather aufgerufen wird, ist wohl was faul ==>
Exception
Prinzip verstanden?
Ein weiterer Punkt noch:
Wie oben erwähnt, gibt es diverse Invarianten also Bedingungen, die immer gelten müssen, damit die Daten konsistent sind:
- Eine Person kann nicht gleichzeitig Vater und Mutter sein.
- Im Stammbaum darf es keine Zyklen geben, d.h. keiner kann sein eigener Vater sein.
- Es können nur Personen heiraten, die auch gleichzeitig leben.
- Kinder können nicht älter als ihre Eltern sein.
- Die Kinder, die in TPartnership aufgeführt sind müssen auch diese Partnership als Eltern angegeben haben
- ...
Auf diese Invarianten musst du besonders aufpassen. Wenn sich einmal Kinder und Eltern nicht mehr einig darüber sind, wer nun wen geboren hat, gibts furchtbaren Streit und du hast wunderbare Bugs, die du jagen darfst. Werfe also entsprechende Exceptions. Zudem gibt es Programmierfehler, die du über Assertions abfangen kannst. Oft sind das nil-Werte. Wenn du mal irgendwo ein nil stehen hast, wo keines hin gehört, wirds auch lustig. Also auch hier aufpassen.
Ich hatte dich ja gewarnt, dass es viel Arbeit sein wird. Hier kommt sie nämlich:
Folgendes solltest du jetzt tun:
- verstehen, was ich geschrieben habe
- bei Unklarheiten nachfragen
- meine Idee verstehen
- bei Unklarheiten nachfragen
- gucken, ob das fachlich passt. Ich hab von Genealogie nicht wirklich Ahnung. Vielleicht hab ich ja einen fachlichen Kapitalfehler gemacht.
- überlegen, ob du Adoptionen berücksichtigen willst; die kann man beispielsweise auch gut vorerst mal ausklammern und später einbauen
- überlegen, ob das mit TVagueDate nötig/sinnvoll/kontraproduktiv/wasauchimmer ist
- ggf. logische Fehler in meinem Ansatz finden
Dann solltest du
- weitere Invarianten finden und dokumentieren
- das Diagramm um wichtige weitere Operationen und Attribute ergänzen; verlieb dich da nicht allzu sehr ins Detail; das kostet nur Zeit. Also nicht jetzt Namenszusätze und anderen unwichtigen Kleinkram spezifizieren, sondern das, was wirklich gebraucht wird.
- mir das Ergebnis zeigen
Wenn du willst, kannst du probehalber auch schon was implementieren. Es kann nur sein, dass sich da noch was ändert.
Die dann folgenden Schritte wären:
- Speichern und Laden modellieren; dazu gibts wohl separate Klassen
- Die grafischen Repräsentationen, die den Stammbaum darstellen, modellieren
- Das Ganze auch implementieren und testen
- Jetzt den Kleinkram dazu
//Nachtrag: Ich sehe gerade: Die Grafik hat tansparenten Hintergrund und das Forum wählt Schwarz statt weiß als Default. ==> einfach auf der Platte speichern und so ansehen...
mfg
Christian