override - overload - reintroduce - virtual

[cn-tools]

Hi @ all!

Könnte mir bitte jemand auf die Sprünge helfen bzw. sagen ob das überhaupt funktioniert?

Delphi-Quellcode:

TModelKlasseA = class(TObject)
end;
TModelKlasseB = class(TModelKlasseA)
end;

TKlasseA = class(TObjec)
  function GetMD: TModelKlasseA; virtual; abstract;
end;

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseB; ????????
end;

Was muss ich bei TKlasseB.GetMD hinten angeben dass Delphi das richtig macht?
Das Programm soll, wenn TKlasseA.GetMD aufgerufen wird, die Methode TKlasseB.GetMD aufrufen.

thx@all4help
DANKE

lg aus Österreich

[himitsu]

virtual und dynamic besagen, daß diese Methode in Nachfahren überschreibbar ist

override sagt, daß diese Methode eine virtuelle/dynamische Methode eines Vorfahren überschreiben soll

abstract besagt, daß diese virtuelle/dynamische Mathode in der "ausgangsklasse" zwar deklariert, aber nicht implementiert ist.

overload besagt, daß es eine gleichnamige Methode gibt (natürlich mit anderen Parametern)
und diese paralell/alternativ aufrufbar sind

mit reintroduce sagt man, daß es in den Vorfahren eine gleichnamige Methode gibt,
man diese aber "absichtlich" verdecken will. (ohne reintroduce würde der Compiler eine entsprechende Warnung anzeigen



Lösung deines Problems: override
[edit] stümmt :oops:, also reintroduce und ohne virtual


[add]
http://www.delphi-treff.de/object-pa...akte-methoden/

[schlecki]

Zitat:

Zitat von himitsu

Lösung deines Problems: override

Nicht ganz, da sich der Rückgabetyp der Funktion geändert hat. Richtig wäre hier reintroduce, welches besagt, dass sich die Signatur der überschriebenen Methode verändert hat (wobei der Rückgabetyp eigentlich nicht zur Signatur gehört)

[himitsu]

Stimm, hast Recht.

OK, Aufrufsignatur gehört der nicht, aber zur Gesamten schon.

Delphi-Quellcode:

TModelKlasseA = class(TObject)
end;
TModelKlasseB = class(TModelKlasseA)
end;

TKlasseA = class(TObjec)
  function GetMD: TModelKlasseA; 
end;

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseB; reintroduce;
end;

function TKlasseA.GetMD: TModelKlasseA;
begin
  result := TModelKlasseA.Create;
end;

function TKlasseB.GetMD: TModelKlasseB;
begin
  result := TModelKlasseB.Create;
end;

Ich würde es dennoch mit Override lösen,
wobei hier TKlasseB dennoch TModelKlasseB ausliefen kann, da diese ja von TModelKlasseA abgeleitet ist.

Delphi-Quellcode:

TModelKlasseA = class(TObject)
end;
TModelKlasseB = class(TModelKlasseA)
end;

TKlasseA = class(TObjec)
  function GetMD: TModelKlasseA; virtual; abstract;
end;

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseA; override;
end;

// TKlasseA.GetMD ist nicht implementiert

function TKlasseB.GetMD: TModelKlasseA;
begin
  result := TModelKlasseB.Create;
end;

Delphi-Quellcode:

TModelKlasseA = class(TObject)
end;
TModelKlasseB = class(TModelKlasseA)
end;

TKlasseA = class(TObjec)
  function GetMD: TModelKlasseA; virtual;
end;

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseA; override;
end;

function TKlasseA.GetMD: TModelKlasseA;
begin
  result := TModelKlasseA.Create;
end;

function TKlasseB.GetMD: TModelKlasseA;
begin
  result := TModelKlasseB.Create;
end;

[mleyen]

Zitat:

Zitat von cn-tools

Das Programm soll, wenn TKlasseA.GetMD aufgerufen wird, die Methode TKlasseB.GetMD aufrufen.

Ich glaube du meintest es andersrum:
Das Programm soll, wenn TKlasseB.GetMD aufgerufen wird, die Methode TKlasseA.GetMD aufrufen.
Ansonsten müsstest du nochmal TKlasseB in TKlasseA instanziieren, solange TKlasseB von TKlasseA abgeleitet ist.

[cn-tools]

Danke erstmal @ all für die schnellen Antworten ... bin gerade am abarbeiten eurer Vorschläge

@mleyen:
ich meinte eigentlich wenn in der Klasse "TKlasseA" die Methode "GetMD " aufgerufen wird.
Somit soll das Programm - weil in TKlasseA ist die Mehtode ja ABSTRACT - die Methode von TKlasseB aufrufen.

[himitsu]

Zitat:

Zitat von cn-tools

ich meinte eigentlich wenn in der Klasse "TKlasseA" die Methode "GetMD " aufgerufen wird.
Somit soll das Programm - weil in TKlasseA ist die Mehtode ja ABSTRACT - die Methode von TKlasseB aufrufen.

Dann mußt es natürlich virtual/dynamic + override sein, aber bei sowas darf sich die Signatur nicht ändern.

[Hansa]

Es fehlt ein Stichwort :

Delphi-Quellcode:

inherited;

Ich würde es so programmieren :

Delphi-Quellcode:

TKlasseA = class(TObject)
  function GetMD: TModelKlasseA; virtual; // überschreibbar machen
end;

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseB; override; // Vorgänger wird überschrieben
end;
..
function TKlasseA.GetMD: TModelKlasseA;
begin
// vorerst mal leer, kann/wird sich aber ändern. Nötig, weil abstract fehlt. 
// wird abstract gewünscht, dann besser die function für TKlasseA wegen Überflüssigkeit
// gleich weglassen und erst in TKlasseB einführen. Ausnahme : es handelt sich um eine Komponentenklasse,
// die verkauft werden soll etc.
end;

function TKlasseB.GetMD: TModelKlasseB;
begin
  inherited; // zuerst GetMD von TKlasseA ausführen. Wird das weggelassen, dann wird TKlasseA.GetMD NICHT ausgeführt
// der Krempel, den TKlasseB zusätzlich zu TKlasseA noch braucht
end;

Also nochmals im Klartext : auf abstract verzichten und lieber leere Methode einbauen, die sofort eingesetzt werden kann, selbst wenn sie anfangs nichts macht. Macht mans anders, dann ist die Gefahr ziemlich hoch, sich dauernd "abstracte" Compiler-Fehlermeldungen einzufangen.

[mkinzler]

Oder man macht es richtig! Den die Verwendung von abstrakten Methoden macht Sinn. Bei neueren Delphiversionen kann man zudem mit strikt abstrakte Methoden nehmen ( Fehler nicht erst zur Laufzeit bei Zugriff)

[himitsu]

Zitat:

Zitat von mkinzler

Oder man macht es richtig! Den die Verwendung von abstrakten Methoden macht Sinn. Bei neueren Delphiversionen kann man zudem mit strikt abstrakte Methoden nehmen ( Fehler nicht erst zur Laufzeit bei Zugriff)

Selbst die älteren Compiler geben aber zumindestens Warnungen aus.

Und wie mkinzler schon richtig sagte, sind abstrakte Methoden nicht zu verachten, jedenfalls wenn sie in Basis-Klassen liegen, welche selber niemals direkt instantiirt werden ... die quasi nur eine gemeinsame Schnittelle definieren, wie z.B. TStrings.
Vorteil hierbei ist nämlich, daß der Compiler sich dann meldet, wenn man was in der Ableitung vergißt zu implementieren.
(bei den leeren Methoden würde man sich frühestens zur Laufzeit wunden, wenn irgendwas aus unerklärlichen Gründen nicht so läuft, wie gewollt)

[DeddyH]

Das ist aber manchen Leuten zu abstrakt :mrgreen:

[mkinzler]

Zitat:

Zitat von DeddyH

Das ist aber manchen Leuten zu abstrakt :mrgreen:

so neumodisches Zeugs ... :lol:

[cn-tools]

Zitat:

Zitat von Hansa

Also nochmals im Klartext : auf abstract verzichten und lieber leere Methode einbauen, die sofort eingesetzt werden kann, selbst wenn sie anfangs nichts macht. Macht mans anders, dann ist die Gefahr ziemlich hoch, sich dauernd "abstracte" Compiler-Fehlermeldungen einzufangen.

Wenn ich das so mache, kann ich nicht compilieren weil die Meldung:
[Pascal Fehler] Source.pas(37): E2037 Deklaration von 'GetMD' unterscheidet sich von vorheriger Deklaration

Ausserdem würde in diesem Fall doch das Problem sein, wenn in der Klasse TKlasseA die Mehtode GetMD aufgerufen wird auch jene der TKlasseA verwendet wird und nicht - wie gewünscht - jene von TKlasseB.

Zitat:

Zitat von mkinzler

Oder man macht es richtig! Den die Verwendung von abstrakten Methoden macht Sinn. Bei neueren Delphiversionen kann man zudem mit strikt abstrakte Methoden nehmen ( Fehler nicht erst zur Laufzeit bei Zugriff)

Muss jetzt blöd fragen: wie wäre es richtig? :?:

[himitsu]

Laut deinen Vorgaben/Wünschen das Mittlere in der #4

Zitat:

Zitat von cn-tools

Wenn ich das so mache, kann ich nicht compilieren weil die Meldung:
[Pascal Fehler] Source.pas(37): E2037 Deklaration von 'GetMD' unterscheidet sich von vorheriger Deklaration

Wie gesagt, beim Override muß die Signatur (die Deklarationen aller Parameter-Typen und des Results) übereinstimmen.

Zitat:

Delphi-Quellcode:

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseB; override;

Bei Hansa war das entweder ein Copy&Paste-Fehler oder er hat es einfach nur übersehn TModelKlasseB muß TModelKlasseA sein, also mit dem GetMD von TKlasseA übereinstimmen.

[mkinzler]

Zitat:

Wenn ich das so mache, kann ich nicht compilieren weil die Meldung:
[Pascal Fehler] Source.pas(37): E2037 Deklaration von 'GetMD' unterscheidet sich von vorheriger Deklaration

Das hat aber nicht mit abstract zu tun

Zitat:

Muss jetzt blöd fragen: wie wäre es richtig? Question

Das Prinzip der abstrakten Methoden/Klassen setzt man ein, wenn man ein bestimmtes Verhalten von abgeleiteten Klassen erzwingen will, eine Implementierung auf dieser Ebene nicht möglich/sinnvoll ist.
Das besondere an Delphi ist, dass es, im Gegensatz zu anderen Sprachen, möglich ist eine Klasse mit abstrakten Methoden zu instantiieren. Eine Fehlermeldung erfolgt erst zur Laufzeit bei dem Versuch auf eine solche Methode zuzugreifen. Hansa will das verhindern, in dem er Dummy-Implementationen in der Basisklasse einfügt. das halte ich für den falschen Weg; zudem wenn man leere Methoden verwendet ( man könnte auch ein Meldung ausgeben).

[Hansa]

Ja, war C+P Fehler. :zwinker: Wo liegt jetzt der Unterschied abstract / vorhandener, aber leerer Vorfahr ? Letzterer kann sofort benutzt oder mit Leben gefüllt werden. Auch wenn er am Anfang leer ist. Ohne grosse Änderungen auch erst später. Ohne nervige Fehlermeldungen. Unnötige wohlgemerkt ! Beide sollen direkt aufgerufen ja vorerst nichts machen. "Abstract" macht allerdings noch folgendes : Laufzeitfehler produzieren. Dann mal viel Glück, die verursachende Stelle zu finden. Ich kann nur aus der Praxis sagen, dass manchmal schon auch der Vorfahr mit irgendwas nachträglich bestückt wird.

Könnte sein, dass abstract 1 Byte spart, aber wen interessiert das ? Blöd ist ausserdem, dass man immer dran denken muss, wo inherited aufgerufen wird. Ist das die Vorfahrmethode, die nichts macht, dann kommt bei Abstract-Deklaration auch Laufzeitfehler, ansonsten passiert eben nichts.

Zitat:

Zitat von mkinzler

zudem wenn man leere Methoden verwendet ( man könnte auch ein Meldung ausgeben).

Welche Meldung ? Allerdings : in der Tat. War auch schon der Fall : showmessage ausgeben in Basisklasse. Dann gilt : 1 Zeile einfügen. Bei abstract : Methodenkopf in virtual ändern und die Methode erst mal schreiben. Und dann wieder alles zurück. D.h. showmessage-Zeile löschen oder Methodenkopf wieder abstract machen und Methode selbst löschen. Ich kenne abstract eigentlich nur von vorgefertigten Komponenten. Da hat sich der Entwickler Gedanken gemacht, was vielleicht von irgendwem gebraucht werden könnte und dementsprechend schon mal Namen dafür festgelegt. Mehr nicht ! Warum macht der das denn so ? Nun, wird der Quelltext nicht rausgerückt oder ist zu umfangreich um gewisse Stellen einfach zu finden, dann stehen zumindest die Methoden zur Verfügung (vom Namen her). Tja, wer im eigenen Programm von abstract stammende Fehlermeldungen braucht, der soll das dann eben damit machen. :shock:

[DeddyH]

Dazu einmal ein Beispiel: angenommen, man deklariert eine Basisklasse TTier. Jedes Tier bewegt sich fort, aber eben nicht auf die gleiche Weise (schwimmen, laufen, kriechen, etc.), so dass eine Implementierung in der Basisklasse keinen Sinn macht. Also deklariert man die Methode Fortbewegen abstrakt, damit die abgeleiteten Klassen diese jede für sich implementieren können bzw. müssen. Wird dies in einer dieser Klassen vergessen, bekommt man eine Fehlermeldung. Implementiert man hingegen leere Methoden in der Basisklasse, kommt keine Fehlermeldung, aber es kann passieren, dass eine abgeleitete Klasse dann die leere Elternmethode aufruft, was ja nicht im Sinne des Erfinders ist.

[cn-tools]

Danke für Eure Mühe...
Löse es jetzt ohne ABSTRACT und mit REINTRODUCE VIRTUAL...

Auch wenn es dann eigentlich nicht so implementiert ist wie ich es gerne hätte...

TROTZDEM DANKE @ ALL

[mkinzler]

Zitat:

Löse es jetzt ohne ABSTRACT und mit REINTRODUCE VIRTUAL...

Dirty is nicer .... :zwinker: