Reintroduce / Override bei Virtual / Dynamic im Bezug auf OOP - Prinzipien

[Jonas Shinaniganz]

Hallo Community...

Vor einiger Zeit habe ich die S.O.L.I.D Prinzipien kennengelernt zu denen auch das Liskovsches Substitutionsprinzip zählt.

So wie Wikipedia es zusammenfast:

Zitat:

Das Liskovsche Substitutionsprinzip (LSP) oder Ersetzbarkeitsprinzip fordert, dass eine Instanz einer abgeleiteten Klasse sich so verhalten muss, dass jemand, der meint, ein Objekt der Basisklasse vor sich zu haben, nicht durch unerwartetes Verhalten überrascht wird, wenn es sich dabei tatsächlich um ein Objekt eines Subtyps handelt. Es wurde 1993 von Barbara Liskov und Jeannette Wing formuliert.[3] In einem nachfolgenden Artikel wurde es folgendermaßen formuliert:

Wenn man eine Methode in einer vererbten Klasse deklariert, welche den gleichen Namen hat, wie eine Methode in Ihrer Eltern-Klasse, dann versteckt man die Methode der Elternklasse.

Dann kann man zwischen "reintroduce" und "override" wählen um die Methode zu überschreiben. "override" nur wenn die Elternmethode "virtual" oder "dynamic" war. Ohne Schlüsselwort gibt der Compiler eine Warnung, welche man selbstverständlich nicht möchte.


Der traditionelle Weg eine Methode einer Elternklasse zu überschreiben ist "override". Hierbei wird die Methode der vererbten Klasse aufgerufen und nicht die der Elternklasse, wenn man eine Instanz der Kindklasse als Basisklasse 'casted' oder meint ein Element der Elternklasse vor sich zu haben.

Delphi-Quellcode:

// type
  
  Tpapa = class
  public
    { public declarations }
    procedure say; dynamic;
  end;


  Tsohn = class(Tpapa)
  public
    { public declarations }
    procedure say; override;
  end; 

// Implementation


var
  Sohn : Tsohn;

begin 
  Sohn := Tsohn.Create;
  Tpapa(Sohn).say;

Meine Frage: Wird hier gegen das Liskovsche - Prinzip verstoßen? Normalerweise müsste doch die say-Methode des Tpapa aufgerufen werden wenn dem Prinzip, dass

Zitat:

...eine Instanz einer abgeleiteten Klasse sich so verhalten muss, dass jemand, der meint, ein Objekt der Basisklasse vor sich zu haben, nicht durch unerwartetes Verhalten überrascht wird,...

So würde ja immer das 'unerwartete' say von TSohn aufgerufen werden.

Mit reintroduce anstelle von override bekommt man das erwartete Ergebnis...

Wieso verstoßen wir (oder bin Ich damit alleine) dann gegen das Prinzip? Oder ist das Prinzip veraltet / nur ein Ideal?

[Stevie]

Es geht darum, dass TSohn.Say auch was sagt und nicht was komplett anderes macht, was derjenige, der die Say Methode aufruft, nicht erwartet.

[himitsu]

OK, abgesehn davon, daß virtual meist besser geeignet ist, als dynamic ...

Im Prinzip geht es doch beim OOP um Erweiterung/Vervollständigung?

Siehe TStrings oder TStream.
Diese Basisklassen stellen eine allgemeingültige Schnittstelle zur Verfügung.
Hinter den Methoden steckt eine gewisse Funktionalität und die nachfahren überschreiben nun diese Methoden, um die spezifischen Anforderungen des jeweiligen Zielsystems bereitzustellen.


Wenn ich mir dieses LSP so durchlese, dann bekomm ich das Gefühl, das weder Reintroduce, Virtual, Dynamic, noch Override erlaubt seien.
Also es dürften keine Funktionen verdeckt oder überschrieben werden.

Du könntest also nur noch Klassen um neue andersbenamte Methoden erweitern und dürftest keine der Vorgängerfunktionen verändern.
Und schon hast du mit der OOP ein Problem, denn sowas wie mit TStream und TStrings wäre nicht möglich. (außer bei den Interfaces)

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1153318)

Es geht darum, dass TSohn.Say auch was sagt und nicht was komplett anderes macht, was derjenige, der die Say Methode aufruft, nicht erwartet.

Um das Beispiel mal etwas auszuschmücken:

Delphi-Quellcode:

procedure TPapa.Say;
begin
  Writeln('Hallo! Wie geht''s?');
end;

procedure TSohn.Say;
begin
  Writeln('Eyh Alter! Was geht ab?');
end;

[DeddyH]

Oder noch krasser:

Delphi-Quellcode:

procedure TPapa.Say;
begin
  Writeln('Hallo! Wie geht''s?');
end;

procedure TSohn.Say;
begin
  FormatLocalHardDrives;
end;

[Jonas Shinaniganz]

Vielen Dank himitsu und Stevie für eure Antworten... es beschäftigt mich, da Ich mich noch in meiner Ausbildung befinde.

Demnach sollte Ich bei Erweiterung/Vervollständigung die Methode überschreiben.

laut Stevie:
Ansonsten auch darauf achten, dass Ich in der überschriebenen Methode nicht etwas völlig anderes mache.

Vielleicht nimmt sich noch Jemand die Zeit und schreib etwas aus seiner Erfahrung dazu?

Danke, Jonas


:D

DaddyH beweißt Humor =)

Dann würde Ich aber voher noch inherited aufrufen.

Delphi-Quellcode:

procedure TSohn.Say;
begin
  inherited;
  FormatLocalHardDrives;
end;

Writeln('Hallo! Wie geht''s?');
:!: Boom
Dann gehts es mir garantiert scheiße :D

[DeddyH]

Nee, eben kein inherited. Es ging ja darum, dass TSohn.Say etwas komplett anderes tut als TPapa.Say. Mit inherited würde die Methode ja lediglich erweitert, was ja regelkonform wäre.

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1153334)

Oder noch krasser:

Delphi-Quellcode:

procedure TPapa.Say;
begin
  Writeln('Hallo! Wie geht''s?');
end;

procedure TSohn.Say;
begin
  FormatLocalHardDrives;
end;

Ja, das trifft den Terminus "überrascht" ziemlich gut!

Also, das LSP sagt ja nur etwas über das erwartete Verhalten aus. Dies ist aber eben i.A. in der Implementation der Methode versteckt und nicht in irgendwelchen semantischen Feinheiten. In meinem Beispiel wäre das LSP nicht verletzt, bei obigem bei gleicher Semantik (override) allerdings schon.

[Sir Rufo]

Das Geraffelt mit dem virtual/dynamic und reintroduce ist - mal runter gebrochen - eigentlich nur DocumentationByCode.
Darum gibt der Compiler ja auch nur Warnungen und keine Fehler aus.

(virtual und dynamic bedeuten von der Logik her ein und dasselbe, der Compiler optimiert nur anders)

Bei der Definition einer (Basis-)Klasse macht man sich ja im Allgemeinen Gedanken, wie da was funktionieren soll. Um nun zu dokumentieren, wo man abweichende oder konkrete Implementierungen erwartet gibt es halt die Schlüsselwörter

Delphi-Quellcode:

virtual;

für eine (nicht zwingende) abweichende oder zwingend konkrete

Delphi-Quellcode:

virtual; abstract;

Implementierung.

Methoden ohne diese Schlüsselwörter werden somit als "ich erwarte nicht, dass diese Methoden in den abgeleiteten Klassen verändert werden" markiert.

Steht man aber nun doch vor dem Problem eine solche Methode doch überschreiben zu müssen, dann wird nicht die Basis-Klasse verändert (Methode als virtual deklarieren), sondern man markiert in der abgeleiteten Klasse diese Methode mit

Delphi-Quellcode:

reintroduce

.
Einfach nur um zu dokumentieren "ja, ich weiß ich soll die nicht ableiten, aber in diesem speziellen Fall ist aber zwingend notwendig"

Ach ja und das mit dem LSP meint ja nur, dass man eben nicht überrascht werden soll, wie in diesem Beispiel:

Delphi-Quellcode:

TKoerper = class
  function Gewicht : real; virtual; abstract;
  function Oberflaeche : real; virtual; abstract;
end;

TKugel = class( TKoerper )
  function Gewicht : real; override;
  function Oberflaeche : real; override;
end;

function TKugel.Gewicht : real;
begin
  Result := {Formel für die Oberfläche};
end;

function TKugel.Oberflaeche : real;
begin
  Result := {Formel für das Gewicht};
end;

[DeddyH]

Ich wollte ja auch ein Negativbeispiel bringen. Wenn eine Methode einer Elternklasse z.B. SaveToFile heißt, dann erwarte ich, dass etwas in einer Datei gespeichert wird. Wenn nun aber jemand diese Methode in einer abgeleiteten Klasse überschreibt, dabei kein inherited aufruft und stattdessen etwas komplett anderes tut, dann verstößt er damit gegen das angesprochene Prinzip.

[edit] Hoppla, da hat sich noch ein Post dazwischengemogelt. [/edit]

[Jonas Shinaniganz]

Zitat:

Zitat von Sir Rufo (Beitrag 1153342)

Steht man aber nun doch vor dem Problem eine solche Methode doch überschreiben zu müssen, dann wird nicht die Basis-Klasse verändert (Methode als virtual deklarieren), sondern man markiert in der abgeleiteten Klasse diese Methode mit

Delphi-Quellcode:

reintroduce

.
Einfach nur um zu dokumentieren "ja, ich weiß ich soll die nicht ableiten, aber in diesem speziellen Fall ist aber zwingend notwendig"

Mit Reintroduce erhalte Ich also die Funktion der Basisklasse und die abgeleitete Klasse wird erweitert?

Delphi-Quellcode:

Tpapa(Sohn).say;

Mit reintroduce kann ich dann den Sohn als Papa behandeln ohne das er sich noch wie der Sohn verhält, ohne die Papa-Klasse zu ändern und ohne gegen Regeln zu verstoßen.

[Sir Rufo]

Zitat:

Zitat von Jonas Shinaniganz (Beitrag 1153345)

Zitat:

Zitat von Sir Rufo (Beitrag 1153342)

Steht man aber nun doch vor dem Problem eine solche Methode doch überschreiben zu müssen, dann wird nicht die Basis-Klasse verändert (Methode als virtual deklarieren), sondern man markiert in der abgeleiteten Klasse diese Methode mit

Delphi-Quellcode:

reintroduce

.
Einfach nur um zu dokumentieren "ja, ich weiß ich soll die nicht ableiten, aber in diesem speziellen Fall ist aber zwingend notwendig"

Mit Reintroduce erhalte Ich also die Funktion der Basisklasse und die abgeleitete Klasse wird erweitert?

Delphi-Quellcode:

Tpapa(Sohn).say;

Mit reintroduce kann ich dann den Sohn als Papa behandeln ohne das er sich noch wie der Sohn verhält, ohne die Papa-Klasse zu ändern und ohne gegen Regeln zu verstoßen.

Nein, du dokumentierst damit nur, dass du ganz bewusst diese Methode überschrieben hast.

Delphi-Quellcode:

TBasis = class
  procedure TuDasImmer;
  procedure TuNormalDasHier; virtual;
end;

TAbleitung = class( TBasis )
  procedure TuNormalDasHier; override;
end;

TAbleitungAusnahme1 = class( TBasis )
  procedure TuDasImmer; // Warnung
end;  

TAbleitungAusnahme2 = class( TBasis )
  procedure TuDasImmer; reintroduce;
end;

Es wird alles funktionieren, nur der Compiler gibt eine Warnung aus ... mehr nicht

[DeddyH]

Das ist quasi der Sledge Hammer-Schalter:

Zitat:

Vertrauen Sie mir – ich weiß, was ich tue!

[mkinzler]

Ich glaube er hat noch auf den kleinen Unterschied beim Cast auf eine Superklasse angespielt.

[Stevie]

Auf StackOverflow gibt es imho eine sehr gute Antwort dazu. Dort wird darauf eingegangen, dass es beim LSP um die Austauschbarkeit der Klassen und eventuelle Pre und Postconditions geht.

[Sir Rufo]

Hmmm, da hatte ich doch für

Delphi-Quellcode:

reintroduce

etwas völlig falsches im Kopf ... tstststs ... (meine Kaffeemaschine zickt auch rum ... ob es da einen Zusammenhang gibt?)

Ok, alles was ich im Bezug auf

Delphi-Quellcode:

reintroduce

von mir gegeben habe am besten wieder vergessen.

Mit

Delphi-Quellcode:

reintroduce

können virtuelle Methoden überschrieben werden, wo sich die Parameterliste verändert.

Delphi-Quellcode:

TBase = class
  procedure ShowMe( const Info : string ); virtual;
end;

// TFromBase1 kennt nur eine Methode ShowMe

TFromBase1 = class( TBase )
  procedure ShowMe( Info : integer ); reintroduce;
end;

// TFromBase2 kennt beide Methoden von ShowMe

TFromBase2 = class( TBase )
  procedure ShowMe( Info : integer ); overload;
end;

[himitsu]

Da wird nichts überschrieben. Es schaltet nur die Wanung ab, wenn man etwas absichtlich "verdecken" (nicht "überschreiben") will.

Und das "Verdecken" bezieht sich nur auf den Namen und nicht auf die Parameter.

Mit Overload gibt man an, daß man etwas Gleichnamiges, aber mit anderer Parametersignatur, "überladen" will.
Alle Methoden existieren gleichzeitig innerhalb der selben Klasse, bzw. auf alle ist zugreifbar.

Override "überschreibt" quasi die "Links", welche von Virtual oder Dynamic erstellt wurden.

[DeddyH]

http://docwiki.embarcadero.com/RADSt...en#Reintroduce:

Zitat:

Reintroduce

Die Direktive reintroduce unterdrückt Compiler-Warnungen, wenn zuvor deklarierte virtuelle Methoden verdeckt werden. Zum Beispiel:

Delphi-Quellcode:

procedure DoSomething; reintroduce; // In der Vorfahrklasse ist ebenfalls 
                                    // eine DoSomething-Methode vorhanden

Verwenden Sie reintroduce, wenn eine geerbte virtuelle Methode durch eine neue Deklaration verdeckt werden soll.

[Jonas Shinaniganz]

Frisch aus dem Mittagspäuschen!

Also ich fasse zusammen:
"virtual" : speed optimiert
"dynamic" : memory optimiert

beide ermöglichen in einer vererbten Klasse override zu benutzen. Wobei virtual das zu bevorzugende Schlüsselwort ist.

"abstract" : Methode sollte in der vererbten Klasse implementiert werden wenn man sie benutzen will.

"overload" : hat damit erstmal nichts zu tun, sondern ermöglicht Methoden den gleichen Namen zu geben und durch die unterschiedlichen Signaturen der Methoden unterschiedliche Parameter zu empfangen und immer anders zu verarbeiten.

"reintroduce" : Eine geerbte virtuelle Methode durch eine neue Deklaration verdecken. Wird die vererbte Klasse als die Basisklasse behandelt am Beispiel (TPapa(Sohn)) würde die Methode say von Tpapa aufgerufen werden, beim weglassen von "reintroduce" ist es eigentlich genauso, allerdings mit Warnung, welche ja berechtigt ist weil vielleicht Tpapa's Methode Abtract war und nicht existiert, Stichwort: AbstractError

"override" : Verweißt auf die Methode der Vererbten Klasse, sodass immer diese aufgerufen wird und nicht die virtuelle methode der Elternklasse welche ja vielleicht abstract ist und dann nicht existiert und das aufrufen zu einem Fehler führen würde.

Delphi-Quellcode:

program Override_Reintroduce_Unterschied;


{$APPTYPE CONSOLE}


uses
  SysUtils;


type
  Tpapa = class
  public
    { public declarations }
    procedure say; virtual; abstract;
  end;


  Tsohn = class(Tpapa)
  public
    { public declarations }
    procedure say; override;
  end;


var
  Sohn : Tsohn;


procedure Tsohn.say;
begin
  Writeln('Hi!');
end;


begin
  try
    Sohn := TSohn.Create;
    TPapa(Sohn).say;


    ReadLn;
    { TODO -oUser -cConsole Main : Code hier einfügen }
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;


end.

Ich habe das Gefühl es ein wenig verstanden zu haben.

Thumbs Up

[Jonas Shinaniganz]

Angenommen Ich habe eine Klassenmethode mit Virtual; kenntlich gemacht und erwarte das diese überdeckt werden soll. (Das ist ja die Bedeutung von Virtual;) Wieso brauche Ich dann ein Reintroduce in der Vererbten Klasse um eine Warnung zu unterdrücken? Ich müsste doch glücklich sein, wenn jemand meine Klassenmethode verbirgt...

Verborgen wird sie doch auch wenn Ich kein Virtual in der Elternklasse habe und kein Reintroduce in der vererbten Klasse.

Das Gleiche Resultat habe ich auch wenn ich einfach nur in der vererbten Klasse Reintroduce einsetze ohne, dass in der Elternklasse etwas davon stand.


Der einzige Sinn des Ganzen ist doch nur der, dass falls jemand meinte, das seine Methode in vererbten Klassen überschrieben werden sollte, ein virtual; verbaut.

Und damit der, der die Erbung macht, sozusagen: "Ja, ist angekommen", zu verstehen geben kann, ein Reintroduce anhängt.

Und der Compiler spielt hierbei die Rolle der Vermittelnden Person zwischen den beiden Programmierern. Quasi eine Compiler SMS :D

Gut, jetzt weiß Ich wie der Hase läuft.

[DeddyH]

So ganz hast Du es anscheinend noch nicht.
- virtual /dynamic -> kann überschrieben werden
- abstract -> muss überschrieben werden
- override -> wird überschrieben
- overload -> neue Methode gleichen Namens mit abweichender Signatur
- reintroduce -> wird "neu eingeführt" und hat nichts mit der übergeordneten Klasse zu tun

[Jonas Shinaniganz]

Wieso hat denn reintroduce nichts mit der übergeordneten Klasse zu tun?

Wenn ich die Vererbte Klasse als Element der Basisklasse betrachte und virtual / reintroduce in den entsprechenden Klassen verwendet habe Also: TPapa(Sohn).say;

Dann wird die Funktion der Basisklasse aufgerufen obwohl es sich um eine Instanz der vererbten Klasse handelt?

Wenn Ich override benutzt habe, dann haben die Klassen nichts mehr miteinander zu tun, weil ich die Elternmethode überschreibe...

Die anderen Begrifflichkeiten habe Ich genauso verstanden wie du es aufgeschrieben hast.

[DeddyH]

Lass doch mal Dein komisches Typecasting weg. Reintroduce unterdrückt wie schon weiter vorn gesagt die Warnung, wenn eine Methode verdeckt wird. Verdecken wiederum bedeutet ja, dass ich so tue, als gäbe es die Methode in der übergeordneten Klasse gar nicht.

[Jonas Shinaniganz]

Gut dann noch kurz eine Frage, gibt es einen Unterschied zwischen verdecken und überschreiben?
:) Ich weiß deine Geduld zu schätzen

[Jonas Shinaniganz]

Ich würde jetzt halt noch gerne wissen bei welchem Aufruf / Fall der unterschied deutlich wird und mir fällt nichts außer dem typecast ein...

[Stevie]

Das Stichwort heißt Polymorphie

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

type
  TFoo = class
    procedure Something; virtual;
  end;

  TBar = class(TFoo)
    procedure Something; override;
  end;

procedure TFoo.Something;
begin
  Writeln('TFoo.Something');
end;

procedure TBar.Something;
begin
  Writeln('TBar.Something');
end;

var
  foo: TFoo;
begin
  foo := TBar.Create;
  foo.Something; // Ausgabe bei override: TBar.Something - Ausgabe bei reintroduce: TFoo.Something;
  Readln;
end.

[DeddyH]

Ja. Schau Dir einmal dieses Beispiel an:

Delphi-Quellcode:

type
  TSomeClass = class
  protected
    procedure DoSomethingVirtual; virtual;
    procedure DoSomething; virtual;
  end;

  TSomeOtherClass = class(TSomeClass)
  public
    procedure DoSomethingVirtual; override; //Überschreiben
    procedure DoSomething; reintroduce;  //Verdecken
  end;

{ TSomeClass }

procedure TSomeClass.DoSomething;
begin
  ShowMessage('TSomeClass.DoSomething');
end;

procedure TSomeClass.DoSomethingVirtual;
begin
  ShowMessage('TSomeClass.DoSomethingVirtual');
end;

{ TSomeOtherClass }

procedure TSomeOtherClass.DoSomething;
begin
  ShowMessage('TSomeOtherClass.DoSomething');
end;

procedure TSomeOtherClass.DoSomethingVirtual;
begin
  inherited;
  ShowMessage('TSomeOtherClass.DoSomethingVirtual');
end;

procedure TForm14.Button1Click(Sender: TObject);
var
  aClass: TSomeClass;  //Variable vom Typ der Elternklasse
begin
  //Instanz der Kindklasse anlegen
  aClass := TSomeOtherClass.Create;
  try
    //Methode der Kindklasse wird aufgerufen
    aClass.DoSomethingVirtual;
    //Methode der Elternklasse wird aufgerufen
    aClass.DoSomething;
  finally
    aClass.Free;
  end;
end;

Siehe dazu auch http://docwiki.embarcadero.com/RADSt..._und_Verdecken

[edit] Kein roter Kasten [/edit]

[Jonas Shinaniganz]

Bleibt noch zu sagen: Danke für die ganze Unterstützung. :thumb: