Final-Methoden zwar nicht überschreibbar, aber verdeckbar?

[Der schöne Günther]

Hallo-

Ich bin etwas schockiert. Ich möchte in der Oberklasse verhindern, dass in der Unterklasse eine Methode überschrieben wird. Der Heilsbringer ist bekanntlicherweise das Schlüsselwort final .

Erstens verstehe ich nicht, warum die Methode dafür - laut Delphi - dann auch zwingend virtual sein muss.

Zweitens kann ich die Methode jetzt zwar nicht mittels override überschreiben. Aber nach Standard-Compilereinstellungen bekomme ich nur eine Warnung, wenn ich das override einfach weglasse und die Methode der Überklasse verdecke? Das ist doch sittenwidrig!


Warum sollte man so etwas zulassen? Ich verstehe das nicht. Möglicherweise ist das in anderen Sprachen auch so und mir ist es nie aufgefallen, bitte nicht hauen.

[Elvis]

Überdecken ist etwas ganz anderes als überschrieben!
beim Überdecken gibt es in der neuen Klasse eine Methode, die so heißt. D.H. du brauchst eine Referenz vom Typen deiner neuen Klasse, um diese Methode aufrufen zu können.
Der Sinn von virtuellen Methoden ist aber, dass du mit einer Referenz vom Typen der Klasse, die diese Methode zum ersten Mal deklariert, die speziellen Implementierungen der Nachfahren aufrufen kannst:

Delphi-Quellcode:

type
  A = class
  public
    function Miep : Integer; virtual; abstract;
  end;

  B = class(A)
  public
    function Miep : Integer; override; // returns 1
  end;

  C = class(A)
  public
    function Miep : Integer; override; final; // returns 2
  end;

  D = class(C)
  public
    function Miep : Inteher; // returns 3
  end;

Im letzten Beispiel siehst du trotzdem 2, nicht 3. Denn hier gelten nur die Methoden, die bereits in A deklariert sind.
Durch überschreiben können Nachfolger ihren Code an der Stelle ausführen lassen. Überdeckende Methoden sind einfach andere methoden und bekommen einen anderen Slot in der VMT.

Delphi-Quellcode:

var 
  a : A;
  d : D;
begin
  a := B.Create();
  WriteLn(a.Miep()); // 1
  a := C.Create();
  WriteLn(a.Miep()); // 2
  a := D.Create();
  WriteLn(a.Miep()); // 2!
  d := D.Create();
  WriteLn(d.Miep()); // 3

[Der schöne Günther]

Danke für die Antwort.

Was was ist habe ich schon verstanden. Nur ich habe ehrlich gesagt übersehen, dass man (normalerweise) wohl auch nicht mit Referenzen auf die konkreten Unterklassen arbeitet, solange nicht nötig.

Hat man eine Referenz auf eine Unterklasse und führt nun einen Upcast durch, wird wieder die "ursprüngliche" finale Methode aufgerufen.

Trotzdem habe ich hiermit noch eine Standard-Einstellung in Sachen Compiler gefunden mit der ich nicht glücklich bin. Zum Glück kann mir niemand verbieten, dass in allen laufenden und zukünftigen Projekten direkt als Fehler zu behandeln - Ich finde das Verwirrungspotential hier viel zu groß.

[Elvis]

Virtuelle Methoden sind ja virtuell um sie als solche zu verwenden.
Wenn du die gar nicht virtuell nutzt, bringt dir doch auch das final nix.
Wie du schon schriebst sind das Konventionen, die du in deinem Projekt etablieren kannst.

btw: So verhält sich auch zum Beispiel C#. Es wäre ja für einige use-cases absolut fatal, wenn man keine Methode "Xyz" erzeugen könnte (z.Bsp Code-Generatoren).
In C# bekommst du die Warnung weg, wenn du "new" davor packst. Delphi gibt Ruhe, wenn du reintroduce dahinter packst.