Komponente ableiten

[mkinzler]

In diesem Fall drafst du nicht Überschreiben, sondern Überladen

procedure TStammbaum.Click(Sender: TObject); overload;

[hansklok]

@mkinzler: Danke erstmal, und wie muss ich das Deklarieren?

[xZise]

Moin,
abgesehen davon, wäre es nicht sinnvoller zu speichern, welches markiert ist? Dann musst du nicht alle durchgucken um herauszufinden, welches markiert ist.

MfG
Fabian

[hansklok]

@xZise: ...ich speicher den Tag der markierten TPerson in einer Integer-Variable innerhalb von TStammbaum, jedoch muss ich ja dennoch alle anderen TPersons durchlaufen lassen, um deren Markiert auf False zu setzen, oder?

@DaddyH: Wie würde so etwas aussehen? Das erscheint mir logisch.

@mkinzler: Nun löst aber das Click Ereignis überhaupt nicht mehr aus.

[xZise]

Zitat von hansklok:

@xZise: ...ich speicher den Tag der markierten TPerson in einer Integer-Variable innerhalb von TStammbaum, jedoch muss ich ja dennoch alle anderen TPersons durchlaufen lassen, um deren Markiert auf False zu setzen, oder?[...]

Ich sehe gerade TPerson muss das wissen, um sich zu zeichnen. Aber dennoch musst du nicht alle durchlaufen. Du weißt ja wer markiert war.

Delphi-Quellcode:

type
  TStammBaum = class
  private
    FMarkiert : TPerson; // Statt Integer, so muss man nicht mehr rechnen.
    procedure SetMarkiert(const APerson : TPerson);
  public
    property Markiert : TPerson read FMarkiert write SetMarkiert;
  end;

procedure TStammBaum.SetMarkiert(const APerson : TPerson);
begin
  if Assigned(FMarkiert) then
    FMarkiert.Markiert := False;
  FMarkiert := APerson;
end;

Alternativ könnte die Person den Stammbaum auch fragen ob es markiert ist (z.B. mithilfe eines Events) aber ich denke diese Lösungs ist wohl besser.

MfG
Fabian

[r2c2]

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

[hansklok]

Lieber Christian,

das ist ja ne Menge.

Was die Verwandtschaftsverhältnisse betrifft, so hast du meines Wissens nach alle Eventualitäten genannt. Das ist für den Anfang ganz schön viel.
Den Vorschlag einer Adoption eine eigene Klasse zu widmen finde ich sehr gut, auch, wenn die gängigen Genealogieprogramme Adoptiveltern zulassen. Es wird eine neue Familie (TPartnership) erzeugt und das Kind hinzugefügt. Diesem wird dann der Status "adoptiert" zugeordnet. Im Gedcom-Standard ist diese Eigenschaft unter "PEDIGREE_LINKAGE_TYPE" definiert. Siekann folgende Werte annehmen:

• adopted - zeigt Adoptiveltern an
• birth - zeigt biologische Eltern an
• foster - zeigt an, dass das Kind in einer Pflegefamilie oder Vormundschaft war
• sealing - zeigt an, dass das Kind an andere als seine leibliche Eltern gesiegelt wurde (speziell bei Mormonen)

Erklär mir deine Überlegung mit "TAdoption" bitte nochmal genauer.

Zu TVagueDate Auch diese Überlegung ist richtig. Aber die Sache verkompliziert sich noch, da hier der Gedcom-Standard ebenfalls detailliertere Optionen bietet:

• DATE_APPROXIMATED - Datum, genähert

• ABT = “um” oder “circa”
• CAL = das Datum ist nicht exakt
• EST = mathematisch errechnet, z. B. durch ein Ereignis und ein Alter. auf der Basis eines Algorithmus und eines anderen Datums geschätzt.

DATE_EXACT - exaktes Datum (z.B. 01.01.2000)

DATE_PERIOD - Datum, Zeitspanne

• FROM = kennzeichnet den Beginn eines Ereignisses oder Status
• TO = kennzeichnet das Ende eines Ereignisses oder Status
• FROM Datum TO Datum

DATE_PHRASE - beliebige Aussage zum Datum, sozusagen benutzerdefiniert

DATE_RANGE - Datum, zeitlich eingegrenzt

• AFT = Das Ereignis fand nach dem angegebenen Datum statt
• BEF = Das Ereignis fand vor dem angegebenen Datum statt
• BET Datum AND Datum = Das Ereignis fand irgendwann zwischen dem 1. und dem 2. Datum statt

Da muss also TVagueDate noch überarbeitet werden

Das Beispiel, das eine Person eine weitere Person heiratet ist auch super verständlich. Warum kompliziert, wenns auch einfach geht

Was eine Exception ist weiß ich, aber was ist das: Exception: EMarriageImpossibleException; bzw. was hast du Dir darunter vorgestellt?

Selbst wenn eine Person bereits ein Vater zugewiesen ist, so muss ein erneuter Aufruf von AddFather nicht zwangsläufig zu einem Fehler führen, dann wird der vorhandene Vater einfach durch einen Anderen ersetzt!

Alle genannten Invarianten leuchten mir ein, stimme Dir zu!

Eine zusätzliche Invariante wäre z.B. noch

• Sterbedatum der Ehepartner muss nach dem Heiratsdatum liegen!

So das sind erstmal meine Anmerkungen zu deinem letzten Beitrag.

Eine ganz blöde Frage noch. Ich implementiere die Klasse TPerson und vorher TPartnership, da diese ja innerhalb der Klasse TPerson verwendet wird. Nun ruft aber die Klasse TPartnership innerhalb eventuell auch einmal TPerson auf. Beim Kompilieren kommt es zu einem Abbruch, logisch, woher soll TPartnership TPerson kennen, wenn es erst danach implementiert ist. Verstehst du? Gibts da ne Lösung für, bestimmt, nur ist sie mir nicht geläufig!

VG

hansklok

[r2c2]

Zitat von hansklok:

Was die Verwandtschaftsverhältnisse betrifft, so hast du meines Wissens nach alle Eventualitäten genannt. Das ist für den Anfang ganz schön viel.

Genau. Deshalb mein Vorschlag, die Adoption erst hinterher zu machen. Das geht in dem Fall ganz gut.

Zitat:

Den Vorschlag einer Adoption eine eigene Klasse zu widmen finde ich sehr gut, auch, wenn die gängigen Genealogieprogramme Adoptiveltern zulassen. Es wird eine neue Familie (TPartnership) erzeugt und das Kind hinzugefügt. Diesem wird dann der Status "adoptiert" zugeordnet. Im Gedcom-Standard ist diese Eigenschaft unter "PEDIGREE_LINKAGE_TYPE" definiert. Siekann folgende Werte annehmen:

• adopted - zeigt Adoptiveltern an
• birth - zeigt biologische Eltern an
• foster - zeigt an, dass das Kind in einer Pflegefamilie oder Vormundschaft war
• sealing - zeigt an, dass das Kind an andere als seine leibliche Eltern gesiegelt wurde (speziell bei Mormonen)

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.

Zitat:

Erklär mir deine Überlegung mit "TAdoption" bitte nochmal genauer.

Ein TGenealogyEntity kann Kinder adoptieren. Deshalb bietet diese Klasse eine Methode adopt() an. Diese Methode erstellt ein neues TAdoption-Objekt, weist die Werte zu und träge eine Referenz in den Adoptivling, sowie in die Adoptiveltern (TGenealogyEntity also entweder eine TPartnership oder eine TPerson) ein.

Zitat:

[INDENT]

• DATE_APPROXIMATED - Datum, genähert

• ABT = “um” oder “circa”
• CAL = das Datum ist nicht exakt
• EST = mathematisch errechnet, z. B. durch ein Ereignis und ein Alter. auf der Basis eines Algorithmus und eines anderen Datums geschätzt.

ABT entspricht "uncertain". CAL müsste man noch einführen. EST versteh ich nicht ganz. Das läuft doch auch wieder auf sowas wie CAL hinaus.

Zitat:

[*]DATE_EXACT - exaktes Datum (z.B. 01.01.2000)

ist drin.

Zitat:

[*]DATE_PERIOD - Datum, Zeitspanne

Wenn man sowas braucht, sollte man daraus wohl eher nen weiteren Typen machen. TVagueTimePeriod, das zwei TVagueDate-Werte enthält.

Zitat:

[*]DATE_PHRASE - beliebige Aussage zum Datum, sozusagen benutzerdefiniert

Wenn man das braucht, kann mans leicht ergänzen. Einfach nen zusätzlichen String-Wert.

Zitat:

[*]DATE_RANGE - Datum, zeitlich eingegrenzt

• AFT = Das Ereignis fand nach dem angegebenen Datum statt
• BEF = Das Ereignis fand vor dem angegebenen Datum statt
• BET Datum AND Datum = Das Ereignis fand irgendwann zwischen dem 1. und dem 2. Datum statt

[/LIST]

Before und after ist drin. Between fehlt noch. Dazu braucht man nen weiteren TDate-Wert, nen Weiteren enum-Wert und ein paar weiter Invarianten.

Zitat:

Was eine Exception ist weiß ich, aber was ist das: Exception: EMarriageImpossibleException; bzw. was hast du Dir darunter vorgestellt?

Eine Exception ist letztendlich ja auch ne Klasse. Die von dir zitierte Zeile tut also nix anderes als eine Variable von der Klasse EMarriageImpossibleException deklarieren. Instanziiert wird die Exception dann weiter unten. EMarriageImpossibleException ist also eine Klasse, die von Exception erbt und ggf. zusätzliche Attribute und Methoden enthält. Wie im Quelltext ersichtlich hat sie eine Property namens "ConflictingMarriage".

Zitat:

Selbst wenn eine Person bereits ein Vater zugewiesen ist, so muss ein erneuter Aufruf von AddFather nicht zwangsläufig zu einem Fehler führen, dann wird der vorhandene Vater einfach durch einen Anderen ersetzt!

Nein. Das macht Probleme.

Delphi-Quellcode:

Charlie := Alice.giveBirthToChildFrom(Bob, Now);
Doris := Alice.giveBirthToChildFrom(Bob, Now);
// Charlie und Doris haben beide als Vater Bob
// jetzt fällt uns auf, dass wir uns verlesen haben. Charlie stammt aus ner früheren Ehe:
Charlie.addFather(Archibald);

Die Folge:
- Auch Doris ist jetzt ein Kind von Archibald
- Alice ist nicht mehr mit Bob verheiratet o.ä.
- Alice ist nun zwei Mal mit Archibald verheitatet/"verpartnert"; womöglich sogar nach Archibalds Tod.

Deshalb muss hier ne Exception geworfen werden.

Zitat:

Eine ganz blöde Frage noch. Ich implementiere die Klasse TPerson und vorher TPartnership, da diese ja innerhalb der Klasse TPerson verwendet wird. Nun ruft aber die Klasse TPartnership innerhalb eventuell auch einmal TPerson auf. Beim Kompilieren kommt es zu einem Abbruch, logisch, woher soll TPartnership TPerson kennen, wenn es erst danach implementiert ist. Verstehst du? Gibts da ne Lösung für, bestimmt, nur ist sie mir nicht geläufig!

Sehr guter Punkt! Normalerweise hat man diese Probleme nicht, weil man Kreuzreferenzen eh vermeiden sollte. Die Dinger sind eigentlich schlecht. Ziemlich schlecht. Wie in vorherigem Post erläutert, brechen wir diese Regel hier bewusst [1] um anderen Problemen aus dem Weg zu gehen. Also: Wir haben erstmal dieses Problem, dass wir Kreuzreferenzen haben und der Compiler die nicht will. Da müssen wir was dagegen tun.

Die einfachste Lösung ist, das alles in eine Unit zu packen und Forward-Deklarationen zu verwenden:

Delphi-Quellcode:

TFoo = class; // forward declaration

TBar = class
  foo: TFoo;
end;

TFoo = class
  bar: TBar;
end;

Das ist nicht allzu schön, allerdings sind die Klassen TPerson und TPartnership eh schon recht stark aneinander gekoppelt (was auch nicht schön ist, aber nicht besser geht). Man muss eben Kompromisse eingehen. Das ist normal.

BTW. Bevor ichs vergesse. Das wollte ich gestern schon schreiben: Hier ist Typsicherheit recht wichtig. Du solltest also besser statt normalen TObjectLists, typisierte Listen verwenden. Also entweder ein neues Delphi einsetzen, das Generics kann oder von TObjectList ableiten und eine TPersonList, etc. draus machen oder Pseudo-Templates einsetzen.


[1] Softwareentwicklung ist IMHO das ständige Ausbalancieren von Prinzipien und Daumenregeln. Die oberste Daumenregel heißt dabei "Wenn du das Gefühl hast, eine Regel brechen zu müssen, tu es. Wundere dich aber nicht über die Konsequenzen." Da sich viele Regeln widersprechen, muss man diese Regel ziemlich häufig anwenden. Immer ein Mittelmaß finden...


mfg

Christian