Komponente ableiten

**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.

markieren

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:

markieren

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

**hansklok**

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.

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.

Der Rest leuchtet mir ein.

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.

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.

Wie verfahren wir weiter?

Neue Gedankengänge oder Geistesblitze?

HG hansklok

**r2c2**

Zitat von hansklok:

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:

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

**hansklok**

...also nun hab ich das verstanden und Möglichkeit A scheint mir auch besser und vor allem weniger anfällig für Fehler.

Ich habe einen Entwurf für eine Event-Oberklasse gemacht, von ihm sind dann neue Objekttypen (z.B. Scheidung, Hochzeit etc.) abgeleitet.

Zitat:

Kennst du Scrollbars?

Ja die kenne ich. Natürlich kann man später auch alle Generationen darstellen, mal sehen wann wir an die stelle kommen. Ursprünglich dachte ich an die Übersichtlichkeit. lass uns mal gucken, wies aussieht, wenn wir das Problem gelöst haben.

LG hansklok

**r2c2**

Zitat von hansklok:

Ich habe einen Entwurf für eine Event-Oberklasse gemacht, von ihm sind dann neue Objekttypen (z.B. Scheidung, Hochzeit etc.) abgeleitet.

Aus welchem Grund? Tu sowas nur, wenn du einen Vorteil daraus hast. Das macht die Sache erstmal deutlich komplizierter. Damit du das wirklich nutzen kannst, müsstest du Polymorphie einsetzen können und da sehe ich momentan keine sinnvolle Möglichkeit. Modelliere wirklich nur das, was du auch brauchst. Ansonsten machst du dir nur das Leben schwer:

http://de.wikipedia.org/wiki/KISS-Prinzip

Weitere Daten kannst du - wenn nötig - entweder zu TPerson (oder andere Klassen) packen oder in ne generische Notizklasse auslagern. Du brauchst nicht zu allem, was dir einfällt, ne eigene Klasse.

Alles weitere in der Antwort auf deine Mail.

Zitat:

Kennst du Scrollbars?

Ja die kenne ich. Natürlich kann man später auch alle Generationen darstellen, mal sehen wann wir an die stelle kommen. Ursprünglich dachte ich an die Übersichtlichkeit. lass uns mal gucken, wies aussieht, wenn wir das Problem gelöst haben.

Ja, das sehen wir dann, wenn wir uns der grafischen Darstellung widmen.

mfg

Christian

**hansklok**

Zitat von r2c2:

Aus welchem Grund? Tu sowas nur, wenn du einen Vorteil daraus hast. Das macht die Sache erstmal deutlich komplizierter. Damit du das wirklich nutzen kannst, müsstest du Polymorphie einsetzen können und da sehe ich momentan keine sinnvolle Möglichkeit. Modelliere wirklich nur das, was du auch brauchst. Ansonsten machst du dir nur das Leben schwer:

http://de.wikipedia.org/wiki/KISS-Prinzip

Weitere Daten kannst du - wenn nötig - entweder zu TPerson (oder andere Klassen) packen oder in ne generische Notizklasse auslagern. Du brauchst nicht zu allem, was dir einfällt, ne eigene Klasse.

Das verstehe ich, nur ich hatte mir folgendes überlegt (wieder in Hinblick auf den Standard):

Eine Geburt oder eine Hochzeit sind genauso Ereignisse wie eine Taufe oder eine Scheidung. Nicht immer gibt es eindeutige Belege über den Zeitpunkt eines Ereignisses, deshalb können auch Zeitspannen (z.B. zwischen dem 31.01.2009 und 03.04.2009) angegeben werden. Alle diese exemplarischen Ereignistypen haben dieselben Standardeigenschaften (z.B. Datum, Ort). Deshalb habe ich neue Klassen von TEvent abgeleitet und beispielsweise bei TMarriage noch den Taufpaten als Eigenschaft hinzugefügt, verstehst du?

Ein Umzug, also ein Wohnortwechsel ist genauso ein Ereignis wie z.B. eine Volkszählung. Das war mein Hintergrundgedanke bei der ganzen Sache.

Erkläre mir bitte nochmal deine Alternative genauer!

HG hansklok

Komponente ableiten

AW: Komponente ableiten

AW: Komponente ableiten

AW: Komponente ableiten

AW: Komponente ableiten

AW: Komponente ableiten

AW: Komponente ableiten

AW: Komponente ableiten

Forumregeln