Vererbung und Polymorphie

[Jumpy]

Zitat von StepByStep:

Edit: Ich konnte das Problem gerade eben selber lösen, indem ich nicht den Umweg über die Set-Procedure gemacht habe. Aber wie geht das mit dieser?
UND bei der Ausgabe wird nicht der Wert von Schachfigur ausgegeben. Wie bekomme ich es hin, dass dieser dann auch ausgegeben wird?

Das Beispiel ist blöd. Man muss schauen, was alle Teile gemeinsam haben (Position,Form,Reichweite) und was anders ist (vllt. erlaubte Bewegungsart oder so) dann wird auch klarer was warum nicht geht. Aber sei es drum, nehmen wir das Beispiel wie es ist.

Du könntest den Figuren jeweile einen eigenen Konstruktor spendieren, der (um im Beispiel zu bleiben) mal die Form, mal die Position setzt. Oder, um mal Polymorphie auszunutzen: Die Basisklasse bekommt eine virtuelle abstakte Prozedur "Initialisieren" oder so. Die Prozedur wird in jeder Klasse anders überschrieben und setzt halt einmal die Form, ein anderes mal die Position, was weiß ich.

Dann kannst du folgendes schreiben:

Code:

var
  I: integer;
  temp: TSchachfigur;
begin
  fschachfiguren := Tobjectlist<TSchachfigur>.create;

  temp := TSchachBauer.create;
  temp.Initialisieren;
  fschachfiguren.add(temp);

[...]

Und schon haben deine Figuren auch was, das sie beim ToString ausgeben können.

------------------------------------

Du solltest aber besser auf dein ursprüngliches Problem zurückkommen: Was brauchst du wirklich für Klassen und wofür. Dann kann man vllt. besser helfen. Worin sollen sich die einzelnen Menschen unterscheiden?

[StepByStep]

Hallo Jumpy,

ich komme auf deinen Ratschlag mal zurück.

Ich habe eine Klasse TMensch:

Delphi-Quellcode:

    FHerkunft:      string;
    FName:          string;
    FGeburtsdatum:  Tdate;
    FGroeße:        extended;
    FGeschlecht:    boolean;
    FFamilienstand: string;

Dann eine Klasse TJob:

Delphi-Quellcode:

    FGehalt:      extended;
    FArbeitszeit: integer;
    FBeruf:       string;

Dann eine Klasse TSchule:

Delphi-Quellcode:

    FSchulfaecher:      string;
    FNotendurchschnitt: extended;
    FSchulform:         string;

Dann eine Klasse TArbeiter:

    FChef: boolean;

Dann eine Klasse TSportler:

Delphi-Quellcode:

    FSportart:         string;
    FErrungenschaften: string;

Dann eine Klasse TAzubi:

Delphi-Quellcode:

    FNotendurchschnitt: extended;
    FSchulfaecher:      string;
    FSchulform:         string;

Dann eine Klasse TSchueler:

Delphi-Quellcode:

    FKlassenfahrt:    boolean;
    FKlassensprecher: boolean;

Das sind alle meine Klassen mit den Variablen. Ein einem extra Formular lese ich Editfelder aus und möchte die gerne in eine Variable von TMensch schreiben, was aber nicht geht, da TMensch die Klassenvariablen aber nicht kennt. Ich hoffe das ist jetzt verständlich.

Gruß
Jan

[stahli]

Also mir ist nicht klar, was Du genau willst...

Den Inhalt von EditBeruf kannst Du nicht ein ein TMensch-Objekt schreiben.
Du musst dafür ein TJob-Objekt (TAngestellter wäre sicher passender) vorliegen haben.

Andersrum kannst Du in ein TJob-Objekt auch alles schreiben, was in TMensch deklariert ist.

Oder geht es Dir eher darum, wie Du die Eingabeformulare organisieren sollst?

[StepByStep]

Also ich soll mit einer Liste arbeiten, nämlich: Menschlist: TObjectList<TMensch>
Diese möchte ich befüllen, mit den Inhalten, die aus den Editfelder in einem anderen Formular ausgelesen werden.
Ich möchte diese ausgefüllten Sachen in eine Variable von TMensch schreiben, was aber nicht geht, da ich ja zum Beispiel nicht "Mensch.FSchulform" abfragen kann,
weil TMensch diese Variable nicht kennt. Dies soll nach dem Schema gehen, welches ich versucht habe mit den Schachfiguren zu verdeutlichen, aber ich schaffe es nicht.

Sobald das funktioniert, brauche ich eine ToString-Methode die mir die verschiedenen Werte in Strings umwandelt, damit ich das in einem Memofeld ausgeben kann.
Das bekomme ich ja mit "override" hin.

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

[Dejan Vu]

Zitat von StepByStep:

Das sind alle meine Klassen mit den Variablen. Ein einem extra Formular lese ich Editfelder aus und möchte die gerne in eine Variable von TMensch schreiben, was aber nicht geht, da TMensch die Klassenvariablen aber nicht kennt. Ich hoffe das ist jetzt verständlich.

Na du musst schon den konkreten Menschtypen instanziieren (Job, Schüler etc.) ist doch klar.

Das ist doch wie im richtigen Leben. Einen Deutschen sprichst Du deutsch an, einen Engländer englisch. Und einen 'Menschen'? Mit dem kannst Du nur in einer allen Menschen gemeinen Sprache sprechen (Mimik, Musik z.B.)

Na ja, hinkt vielleicht ein wenig.

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

[Dejan Vu]

Zitat von StepByStep:

Also ich soll mit einer Liste arbeiten, nämlich: Menschlist: TObjectList<TMensch>
Diese möchte ich befüllen, mit den Inhalten, die aus den Editfelder in einem anderen Formular ausgelesen werden.

Gut. Erste Zeile ist schon klar (im Button-Click-Handler)

Delphi-Quellcode:

//
Menschlist.Add (ErzeugeNeuenMenschen());
//

Zitat:

Ich möchte diese ausgefüllten Sachen in eine Variable von TMensch schreiben, was aber nicht geht, da ich ja zum Beispiel nicht "Mensch.FSchulform" abfragen kann,
weil TMensch diese Variable nicht kennt. Dies soll nach dem Schema gehen, welches ich versucht habe mit den Schachfiguren zu verdeutlichen, aber ich schaffe es nicht.

Delphi-Quellcode:

Function TForm1.ErzeugeNeuenMenschen() : TMensch;
Begin
  Case WelcherMenschSollErzeugtWerden of
    Arbeiter : 
      Result := ErzeugeArbeiter();
    Schueler : 
      Result := ErzeugeSchueler();
   ....
  End;
// Hier noch die allen Menschen gemeinsamen Eigenschaften setzen
End;

Function TForm.ErzeugeArbeiter() : TArbeiter;
Begin
  Result := TArbeiter.Create;
  Result.StundenLohn := StrToFloat(EditFeldStundenLohn.Text);
  Result.IstChef := CheckBoxIstChef.Checked;
End;

Function TForm.ErzeugeSchueler()  : TSchueler;
Begin
  Result := TSchueler.Create;
  Result.Schulform := ....
End;

Du erzeugst also konkrete Menschableitungen und setzt deren explizite Eigenschaften.
Jeder Schüler und jeder Arbeiter ist auch ein Mensch, aber nicht umgekehrt. Schau Dir genau die Deklaration an. Das passt so. Die Variable 'Result' (das Funktionsergebnis) ist vom Typ 'TMensch'. Ich kann ihr aber einen TArbeiter oder TSchueler zuweisen. In der Funktion 'ErzeugeSchueler' ist das Funktionsergebnis hingegen ein 'TSchueler'.

Da du der abstrakten Basisklasse 'TMensch' noch eine virtuelle Methode 'ToString' spendierst, und die dann in allen Kindklassen überschreibst bzw. erweiterst, solltest Du dann damit durch sein.