Warum virtual / override bei destructor / constructor?

[HJay]

Hallo! Ich möchte endlich mal verstehen, warum es so ist. In der Unit System wird TObject eingeführt und der Constructor ohne "virtual", aber der Destructor mit "virtual" deklariert.

Entsprechend muss man bei der Ableitung beim Destructor das Schlüsselwort "override" angeben, während man beim Constructor einfach so Create() überschreiben kann. In beiden Routinen kann und soll man dann mit "inherited" die Vorfahrroutine aufrufen.

WARUM bloß ist das so? Warum ist bei Create kein "virtual" deklariert und es geht trotzdem alles und warum braucht man beim Destructor das "virtual > override"?

Hätten die Entwickler von TObject nicht beide Prozeduren analog deklarieren können? Also beide mit oder beide ohne "virtual"?

Gibt es einen Grund, warum es so ist? Mich irritiert es schon immer, dass ich bei Create ohne override auskomme, bei Destroy es aber angeben muss, sich aber beide Prozeduren ansonsten identisch zu verhalten scheinen, abgeleitet und überschrieben werden können und "inherited" auch verwendbar ist.

Danke im voraus für jede Erhellung des Sachverhalts!

Delphi-Quellcode:

{ unit System }
TObject = class
public
  constructor Create;
  { ...}
protected
  destructor Destroy; virtual;
   
{... }

constructor TObject.Create;
begin
end;

destructor TObject.Destroy;
begin
end;

und die Verwendung in abgeleiteten Klassen:

Delphi-Quellcode:

TMyObject = class(TObject)
constructor Create;
destructor Destroy; override;
{ ...}

implementation

constructor TObject.Create;
begin
  inherited;
  { ... } 
end;

destructor TObject.Destroy;
begin
  { ... }
  inherited;
end;

[Olli73]

Delphi-Quellcode:

var
  AObj: TObject;
begin
  AObj := TMyObj.Create; // hier gibst du eh konkret an, ob ein TMyObj oder ein TObject oder sonstwas erstellt werden soll, auch wenn die Variable als TObject deklariert ist
  ...
  AObj.Destroy; // bzw. Free;  // ohne das virtual würde hier der Destructor von TObject aufgerufen, mit virtual wird korrekterweise der von TMyObj aufgerufen
end;

[HJay]

Danke für die schnelle Antwort. Aber warum funktioniert das Ableiten von Create auch ohne "virtual"? Das Konzept, warum "virtual" mal nötig und mal nicht nötig ist, leuchtet mir nicht ein.

Warum ruft "inherited" trotzdem die richtige Vorfahrroutine auf und ist verwendbar?

Ich hätte eigentlich gedacht, dass man "virtual" deklarieren muss, wenn man möchte, dass die Klasse überschrieben werden kann? Es ist ja nicht einmal ein "reintroduce" nötig, man kann einfach Create neu definieren ohne Probleme...

[Olli73]

Das inherited hat damit nicht direkt was zu tun. Damit sagst du nur, ob und an welcher Stelle die Methode des Vorfahren aufgerufen wird, was man in der Regel will, um nicht alles neu implementieren zu müssen bzw. bei Änderungen alle Nachfahren anfassen zu müssen.

Das Virtual bedeutet nur, dass das Programm zur Laufzeit prüft ob es in obigem Beispiel wirklich ein TObject (so ist die Variable deklariert) oder ein Nachfahre davon ist. Ist es ein Nachfahre wird dessen Destructor aufgerufen. Ohne das Virtual würde in diesem Fall TObject.Destroy aufgerufen, was ja falsch wäre.

[Zacherl]

Virtual bei Create benötigt man z.b. in folgendem Falle:

Delphi-Quellcode:

type
  TBaseClass = class(TObject)
  public
    constructor Create; virtual;
  end;

  TClassA = class(TBaseClass)
  public
    constructor Create; override;
  end;

  TClassB = class(TBaseClass)
  public
    constructor Create; override;
  end;

  TClassType = class of TBaseClass;

..

function DynamicCreate(ClassType: TClassType): TBaseClass;
begin
  Result := ClassType.Create;
end;

Hätte man den Constructor hier nicht als virtual deklariert, würde immer Der von TBaseClass aufgerufen. Mit virtual ruft die Funktion korrekt den Constructor der konkreten Klasse auf.

[HJay]

Das bedeutet dann aber auch, dass die Entwicklung der Unit System problemlos sowohl den Constructor Create als auch den Destructor Destroy hätten analog mit "virtual" deklarieren können und alles funktionieren würde? Ist das so?

Dieses Analogie der Deklarationen würde sicherlich vielen Anfängern Irritationen ersparen.