Vererbung und Polymorphie

[Jumpy]

Wenn wir zunächst bei deiner Vererbungstruktur aus #1 bleiben sind zumindest die Namen TJob und TSchule unglücklich gewählt (als Kinder von TMensch). Besser wäre TMenschMitJob und TMenschInDerSchule.

Schaust du dir den Azubi-Berufsschüler an, beruht der bei dir auf TJob, braucht aber auch eigenschaften als Schüler und bekommt die wieder extra. Das ist doch irgendwie blöd. Mehrfachvererbung gibt es ja (in Delphi) nicht, sonst wäre das vllt. gegangen.

Somit ist doch irgendwie der ganze Ansatz schon nicht gut. Mal als Verbesserungsvorschlag. Definiere eine Klasse TJob und TSchulinfo oder so. Als separate Klassen, die nicht von TMensch erben! Stattdessen bekommt TMensch nun variablen für Objekte des Typs TJob und TSchulinfo. Vererbung ist bei der OOP nicht alles (und wird glaub ich immer weniger (wg. Testbarkeit???) genutzt. Stattdessen werden Klassen verknüpft (Aggregation/Assoziation) (wg. Testbarkeit meist über Interfaces).

Du kannst dem TMensch ja dann noch Boolean-Funktionen ala "IstSchüler" "HatJob" mitgeben.
Jetzt soll Mensch 12 aus der Liste angeschaut/editiert werden:

Code:

//Edit-Felder des Formulars mit Werten aus TMensch verknüpfen oder füllen.
if TMensch(Menschliste[12]).HasJob then
  begin
  //Zusätzlich einen Frame (Unterform) laden, mit EditFeldern für Job
  //Edit-Felder mit Werten versorgen
  end
//Analog für Schulinfo

[stahli]

Die Menschen- und Schachfigurenbeispiele passen nicht so richtig zusammen.

Die Schachfiguren sind quasi alle gleich. Sie sehen etwas unterschiedlich aus und gestatten etwas andere Züge. Sie stehen alle auf einem Schachbrett rum und können versetzt oder davon entfernt werden.
Insofern müsste man die Figuren nicht unbedingt in unterschiedlichen Klassen abbilden.

Bei den Personen sieht es schon anders aus. Sie stehen in unterschiedlichen Kontexten und eigentlich haben Schüler mit Mitarbeitern nichts weiter zu tun - außer dass alles Menschen sind (i.d.R. ) und über einen Namen und Geburtsdatum verfügen.

In einer realen Anwendung würde man vermutlich Schüler und Angestellte in verschiedenen Listen verwalten und jeweils angemessen mit beiden Listen umgehen.

Wenn man nun alle Namen und Zusatzinfos auflisten will würde man zunächst AlleAngestelltenToString und dann AlleSchülerToString aufrufen.

Wenn Du (warum auch immer) lieber AlleMenschen (durcheinander) in einer Liste verwalten willst, kannst Du auch AlleMenschenToString aufrufen. TMensch.ToString wäre dann in TAngestellter und TSchüler überschrieben.
Die Funktion muss dann nicht wissen, ob sie hier einen Angestellten oder Schüler vor sich hat.

Wenn Du letzteres willst, dann brauchst Du nur ein FormAngestellter und FormSchüler definieren, bei dessen OK-Button einen TAngestellten oder TSchüler erzeugen (sowie die Edit-Daten in das Objekt schreiben) und das jeweilige Objekt in die Menschenliste werfen.
AlleMenschen kannst Du später wie oben beschrieben als String ausgeben.

Wenn das das Ziel ist, sollte das kein Problem sein.


Für eine reale Anwendung taugt der Ansatz aber nicht wirklich.
Ich habe z.B. in meiner Turniersoftware Spieler definiert. Ein Spieler hat einen Status (spielt gerade, wartet, ist bereit, ist verletzt usw).
Ein Spieler ist natürlich auch eine Person und die Person ist wiederum Mitglied in einem Verein (oder in mehreren). Ein Spieler kann wiederum in verschiedenen Turnieren spielen und dort unterschiedliche Stati haben.
Daher verwalte ich in Spielern und Vereinsmitgliedern lediglich Instanzen auf ein und die selbe Person.
Je nach Gegebenheit kann so etwas auch eine sinnvolle Lösung sein.


Handelt es sich bei Deiner Aufgabe um eine Übungsaufgabe, die nur die Strings liefern soll oder gibt es da noch einen weiteren Hintergrund? Vielleicht können wir das noch besser einordnen wenn mir noch mehr erfahren...

[Sir Rufo]

Das ist doch alles vom Ansatz schon total falsch

Hier wird gerade alles durcheinander geworfen.

Wie kann man TJob von TMensch ableiten?
Selbst TSchueler kann man nicht von TMensch ableiten.

Denn TSchueler ist eine Rolle die ein TMensch einnimmt. Somit wäre das also eine Eigenschaft, die man hat oder nicht oder nicht mehr hat.

Somit ist also TMensch ein Aggregat und kann eben Bezug zu diesen Rollen haben mit entsprechenden Eigenschaften.

Daraus würde sich dann folgender Ansatz ergeben

Delphi-Quellcode:

TRolle = class
end;

TMensch = class
  property Rollen[Index:Integer] : TRolle read GetRolle;
end;

TSchule = class
end;

TSchulKlasse = class
  property Schule : TSchule;
end;

TSchueler = class( TRolle )
  property Klasse : TSchulKlasse;
end;

Jetzt kann man z.B. alle Menschen herausfiltern, die Schüler der Schule xy sind.

[BUG]

Zitat von Sir Rufo:

Das ist doch alles vom Ansatz schon total falsch

Das hilft aber auch nicht wirklich weiter

Zitat von StepByStep:

Mir ist der Sinn von OOP deutlich, die Klassenhierarchie kommt auch nicht von mir, sondern ist mir vorgegeben worden. ... Also suche ich nach einem Ansatz, wie ich das lösen kann, sodass die Aufgabenstellung erfüllt wird.