Instanz welcher abgeleiteten Klasse?

[stoermi]

Hallo!

Angenommen, ich habe eine abstrakte Klasse Fahrzeug;
Davon leiten sich die Klassen Auto, Fahrrad und Motorrad ab.

Im Quelltext arbeite ich dann mit der Variable einFahrzeug : TFahrzeug!
Kann ich nun irgend wie testen bzw. abfragen, von welcher Sub-Klasse das Fahrzeug nun genau ist, also ob es ein Auto, Fahrrad, etc. ist?

[dizzy]

Der is-Operator dürfte dein Problem lösen ;).

Gruss,
Fabian

[nailor]

du könntest mit dem is/as operator arbeiten. aber das ist in deinem falle wohl nicht im sinne von OOP.

[stoermi]

Zitat:

Zitat von dizzy

Der is-Operator dürfte dein Problem lösen ;).

Gruss,
Fabian

Danke! Wusste doch, dass es etwas ganz simples sein muss, hab aber wohl zwecks Wortwahl nichts gefunden.

[jim_raynor]

Erstmal bekommst du über Classname den Klassennamen als Text.
2. Kannst du den Operator is verwenden (also z.B. Fahrzeug is TAuto). Wobei das auch true ergibt wenn das Objekt widerrum von TAuto abgeleitet ist
3. Über ClassInfo bekommst du die genaue Klasse. Mit einer einfachen Abfrage Fahrzeug.ClassInfo=TAuto kannst du fragen, ob das Objekt wirklich TAuto ist. Ist es abgeleitet von TAuto ergibt der vergleich false (im Gegensatz zu is).

[stoermi]

Zitat:

Zitat von nailor

du könntest mit dem is/as operator arbeiten. aber das ist in deinem falle wohl nicht im sinne von OOP.

Das heißt? Hast du einen besseren Vorschlag?

[stoermi]

Zitat:

Zitat von jim_raynor

3. Über ClassInfo bekommst du die genaue Klasse. Mit einer einfachen Abfrage Fahrzeug.ClassInfo=TAuto kannst du fragen, ob das Objekt wirklich TAuto ist. Ist es abgeleitet von TAuto ergibt der vergleich false (im Gegensatz zu is).

Also mit Fahrzeug.ClassInfo=TAuto funktioniert es nicht!
Da meckert der Compiler! Er weis da nichts mit TAuto anzufangen.
Und ClassInfo gibt mir ja nur einen Pointer...

[stoermi]

Zitat:

Zitat von stoermi

Also mit Fahrzeug.ClassInfo=TAuto funktioniert es nicht!
Da meckert der Compiler! Er weis da nichts mit TAuto anzufangen.
Und ClassInfo gibt mir ja nur einen Pointer...

Gut, mein Fehler! Hatte gerade die Unit bei uses vergessen, mit der ich getestet habe.
Der Compiler bleibt still!
Dennoch klappt der if-Vergleich nicht.

[jim_raynor]

oh sorry. Hatte was verwechselt. Statt ClassInfo nimm ClassType. :duck:

[stoermi]

Zitat:

Zitat von jim_raynor

oh sorry. Hatte was verwechselt. Statt ClassInfo nimm ClassType. :duck:

Danke! So funktionierts.

[nailor]

Zitat:

Zitat von stoermi

Zitat:

Zitat von nailor

du könntest mit dem is/as operator arbeiten. aber das ist in deinem falle wohl nicht im sinne von OOP.

Das heißt? Hast du einen besseren Vorschlag?

wenn du in der basisklasse wissen willst, welche abgeleitete variante du hast, hast du mit hoher wahrscheinlichkeit eine aufgabe nicht weit genug nach unten durchdelegiert. wenn du zum beispiel eine meldung ausgeben willst "ich bin ein MOTORRAD" könntest du das mit dem "is"-operator in der basisklasse machen. sauberer wäre eine abstrakte methode, die die nachkommen implementieren müssen. und da diese wissen, welchen typ sie haben, braucht man keinen "is" operator.

ja, es mag auch fälle geben, wo man den operator braucht, aber das sollte die ausnahme sein.

[stoermi]

Zitat:

Zitat von stoermi

Zitat:

Zitat von jim_raynor

oh sorry. Hatte was verwechselt. Statt ClassInfo nimm ClassType. :duck:

Danke! So funktionierts.

Warum funktioniert es jedoch nicht mit case .. of?

Delphi-Quellcode:

case objekt.ClassType of  
    TAuto  : edKat.Text := 'Auto';
    TMotorrad  : edKat.Text := 'Motorrad';
    TFahrrad  : edKat.Text := 'Fahrrad';
  end;

Compiler bringt:Ordinalty erforderlich!?

[Chewie]

Zitat:

Zitat von stoermi

Warum funktioniert es jedoch nicht mit case .. of?

Delphi-Quellcode:

case objekt.ClassType of  
    TAuto  : edKat.Text := 'Auto';
    TMotorrad  : edKat.Text := 'Motorrad';
    TFahrrad  : edKat.Text := 'Fahrrad';
  end;

Compiler bringt:Ordinalty erforderlich!?

Na weil deine Klassentypen keine Ordinalwerte sind! Ordinalwerte sind Werte, die alle einen eindeutigen Nachfolger und einen eindeutigen Vorgänger haben. Nur so können case-Anweisungen implementiert werden, da dort eine Sprungtabelle aufgebaut wird.

[stoermi]

Zitat:

Zitat von Chewie

Na weil deine Klassentypen keine Ordinalwerte sind! Ordinalwerte sind Werte, die alle einen eindeutigen Nachfolger und einen eindeutigen Vorgänger haben. Nur so können case-Anweisungen implementiert werden, da dort eine Sprungtabelle aufgebaut wird.

Heißt das, dass dies hier Ordinalwerte sind?
Beispiel aus Delphi-Hilfe...

Delphi-Quellcode:

case MyColor of

  Red: X := 1;
  Green: X := 2;
  Blue: X := 3;
  Yellow, Orange, Black: X := 0;
end;

case Selection of

  Done: Form1.Close;
  Compute: CalculateTotal(UnitCost, Quantity);
else
  Beep;
end;

Dann sind diese Beispiel sehr irreführend...!

[nailor]

ja sind (verkappte) ordinal-werte.

[jim_raynor]

MyColor ist ja so definiert.

Delphi-Quellcode:

MyColor = (Red,Green,Blue,Yellow,Orange,Black);

Das bedeutet, das nach Red Green kommt, nach Green Blue usw. Wird halt einfach durchnummeriert

Red=0
Green=1
Blue=2

Es ist ein Ordinaltyp weil es immer einen definierten Vorgänger und Nachfolger gibt.

Bei Klassen ist es so, dass zum Beispiel TAuto nur auf die Klasseninformationen zeigt könnte also $123456 oder $654321 liegen. TMotorrad könnte dann bei $765432 oder $234567 liegen. Du kannst also nicht sagen, dass nach TAuto TMotorrad kommt. Sind halt nur Zeiger.

Vielleicht kann man es einfach mit einem Trick lösen in dem man ClassType zu Interger castet. Kann es leider nicht testen.

Delphi-Quellcode:

case Integer(objekt.ClassType) of 
    Integer(TAuto)  : edKat.Text := 'Auto';
    Integer(TMotorrad)  : edKat.Text := 'Motorrad';
    Integer(TFahrrad)  : edKat.Text := 'Fahrrad';
  end;

[maximov]

Zitat:

Zitat von stoermi

...Warum funktioniert es jedoch nicht mit case .. of?

Delphi-Quellcode:

case objekt.ClassType of  
    TAuto  : edKat.Text := 'Auto';
    TMotorrad  : edKat.Text := 'Motorrad';
    TFahrrad  : edKat.Text := 'Fahrrad';
  end;

Compiler bringt:Ordinalty erforderlich!?

IMO sind explizite abfragen auf klassen-typen nicht sehr dynamisch und behindern nur die OOP. Und für diesen zweck drängt sich eine virtuelle geradezu auf. Warum lääst du nicht das fahrzeug sagen, wie sein 'DisplayTypeName' ist.

Und es gilt auch hier: 'Wer case verwendet, der hat objektorientiere programmierung nicht verstanden' :mrgreen: ...Ist vielleicht ein bisschen drastisch formuliert, aber was wahres drann *duck*

:-D

[GuenterS]

Zitat:

Zitat von nailor

Zitat:

Zitat von stoermi

Zitat:

Zitat von nailor

du könntest mit dem is/as operator arbeiten. aber das ist in deinem falle wohl nicht im sinne von OOP.

Das heißt? Hast du einen besseren Vorschlag?

wenn du in der basisklasse wissen willst, welche abgeleitete variante du hast, hast du mit hoher wahrscheinlichkeit eine aufgabe nicht weit genug nach unten durchdelegiert. wenn du zum beispiel eine meldung ausgeben willst "ich bin ein MOTORRAD" könntest du das mit dem "is"-operator in der basisklasse machen. sauberer wäre eine abstrakte methode, die die nachkommen implementieren müssen. und da diese wissen, welchen typ sie haben, braucht man keinen "is" operator.

ja, es mag auch fälle geben, wo man den operator braucht, aber das sollte die ausnahme sein.

is brauchst Du dann, wenn Du zum Beispiel Objecte in einer Liste speicherst, welche nicht unbedingt aller derselben Basisklasse (außer TObject) angehören.

[Chewie]

Zitat:

Zitat von GuenterS

is brauchst Du dann, wenn Du zum Beispiel Objecte in einer Liste speicherst, welche nicht unbedingt aller derselben Basisklasse (außer TObject) angehören.

Wieso? Von den Objekten, die ich in eine Liste reinspeicher, sollte ich doch wissen, was es für welche sind.

Ich denke auch, dass man bei OOP in "Reinform" kein is braucht, nur: Wem bringt es was, ein Programm zu haben, das als Musterbeispiel in einem Buch über OOP gelten könnte, das Programm dafür aber viel einfacher und schneller implementiert hätte werden können, wenn man die OOP weniger streng ausgelegt hätte?
IMHO muss man da stets zwischen Theorie und Realität abwägen.

[GuenterS]

Zitat:

Zitat von Chewie

Zitat:

Zitat von GuenterS

is brauchst Du dann, wenn Du zum Beispiel Objecte in einer Liste speicherst, welche nicht unbedingt aller derselben Basisklasse (außer TObject) angehören.

Wieso? Von den Objekten, die ich in eine Liste reinspeicher, sollte ich doch wissen, was es für welche sind.

Ich denke auch, dass man bei OOP in "Reinform" kein is braucht, nur: Wem bringt es was, ein Programm zu haben, das als Musterbeispiel in einem Buch über OOP gelten könnte, das Programm dafür aber viel einfacher und schneller implementiert hätte werden können, wenn man die OOP weniger streng ausgelegt hätte?
IMHO muss man da stets zwischen Theorie und Realität abwägen.

Das muss nicht sein, dass Du das unbedingt immer wissen musst.

Könnte ja auch sein, dass Du diese Liste zur Laufzeit füllst, mit Buttons, StringListen, CheckBoxen, Panels, Frames, eigenen Objekten, etc.

Es gibt auch Componenten ich denke da an GridComponenten beispielsweise an ein VerticalGrid, da kann man verschiedenartige Spalten bzw. Zeilen einfügen (auch zur Laufzeit). Wenn Du jetzt durchiterierst über alle Spalten oder Zeilen kannst nicht mehr wissen was das genau ist und nimmst daher den is operator.

[Chewie]

Hm, klar, manchmal ist er ganz nützlich. Auch wenn man FindComponent benutzt (wobei man sich auch fragen kann, ob das Design nicht schon Mist ist, wenn man FindComponent braucht ;) ).