Inherited "überspringen"?

[Rabenrecht]

Man betrachte folgende Struktur:

Delphi-Quellcode:

  Oberklasse = class(TObject)
  protected
    procedure Proc; virtual;

  Unterklasse1 = class(Oberklasse)
  protected
    procedure Proc; override;

  Unterklasse2 = class(Unterklasse1)
  protected
    procedure Proc; override;

Man nehme weiterhin an, dass ich als Programmierer nur den Code ab Unterklasse2 modifizieren kann (weil zb. der Rest in irgendwelchen Standardbibliotheken ist).

Zudem sei Unterklasse1.Proc so implementiert, dass es in Randfällen im Anwendungskontext, in dem auch Unterklasse2 steht (also das Programm, von dem Unterklasse2 ein Teil ist), zu Fehlern kommt.
Dies ist überhaupt erst der Grund, warum ich in Unterklasse2 Proc nocheinmal implementiere.

Nun ist es so, dass in Unterklasse1.Proc inherited, also Oberklasse.Proc aufgerufen wird. Diesen Aufruf würde ich auch gerne behalten.

Wenn ich aber Unterklasse2.Proc folgendermaßen implementiere:

Delphi-Quellcode:

procedure Unterklasse2.Proc;
begin
  [...]
  inherited;
end;

würde der (fehlerhafte) Code von Unterklasse1.Proc wieder aufgerufen werden.

Lange Rede, kurze Frage: ist es möglich beim inherited Stufen in der Hierarchie zu "überspringen"? Oder eine spezifische Implementierung von Proc aufzurufen?

[Ghostwalker]

Naja....du könntest z.B. folgendes machen:

Delphi-Quellcode:

procedure Unterklasse2.Proc;
begin
  [...]
  Oberklasse.proc;
end;

[Rabenrecht]

Hm... Tatsache. Tja, manchmal geht's es ganz einfach
Danke!

[Uwe Raabe]

Zitat von Ghostwalker:

Delphi-Quellcode:

procedure Unterklasse2.Proc;
begin
  [...]
  Oberklasse.proc;
end;

Das hatte ich auch erst gedacht, aber weder unter Berlin noch XE2 compiliert das überhaupt:

Zitat:

[DCC Fehler]E2076 Diese Form des Methodenaufrufs ist nur für Klassenmethoden erlaubt

Funktioniert das denn bei dir?

[hoika]

Hallo,
ist es möglich beim inherited Stufen in der Hierarchie zu "überspringen"? Oder eine spezifische Implementierung von Proc aufzurufen?

Kurze Antwort: nein
Lange Antwort: es kommt drauf an

In deiner eigenen Klasse kannst du das inherited ja weglassen,
musst dann aber wissen, was in den darüberliegenden Klasse gemacht wird,
dann könntest du aber gleich reintroduce nehmen.
Oder du rufst das inherited auf und korrigierst dann die falschen Daten,
falls das geht.

[bra]

Eventuell so?

Delphi-Quellcode:

procedure Unterklasse2.Proc;
begin
  [...]
  Oberklasse(Self).proc;
end;

[SProske]

Zitat von bra:

Eventuell so?

Delphi-Quellcode:

procedure Unterklasse2.Proc;
begin
  [...]
  Oberklasse(Self).proc;
end;

Das funktioniert nur solange beide Klassen in der selben Unit sind und Proc protected, aber nicht strict protected ist. Für den beschriebenen Anwendungsfall also ungeeignet.

[Rabenrecht]

Zitat von Uwe Raabe:

Funktioniert das denn bei dir?

Ne...

Mein spezifisches Problem war anders lösbar, weil die Oberklasse.Proc nen Einzeiler mit nem Zugriff auf eine Published Property war (check auf Ereignisbehandlung) und ich das deshalb schmerzfrei nachbauen konnte.

Die Diskussion interessiert mich dennoch. Ähnliche Fälle werden in Zukunft wahrscheinlich nochmal auftreten.

Zitat von Ghostwalker:

Da du aber Unterklasse2 eh nur wegen eines Fehlers in Unterklasse1 baust, warum
leitest du das ganze nicht direkt von Oberklasse ab ? Dann kann Unterklasse1 über die
Klinge springen.

Weil im Unterschied zu meinem aufs Notwendigste reduzierte Beispiel im konkreten Fall Unterklasse1 eine ganze Menge notwendiger Funktionalität enthält

[Zacherl]

Noch eine Dritte Variante ohne Assembly oder RTTI:

Delphi-Quellcode:

{ TA }

procedure TA.X(I: Integer);
begin
  ShowMessage('1: ' + I.ToString);
end;

{ TB }

procedure TB.X(I: Integer);
begin
  inherited;
  ShowMessage('2: ' + I.ToString);
end;

{ TC }

procedure TC.X(I: Integer);
type
  TProc = procedure(Sender: TA; I: Integer);
begin
  //inherited;
  TProc(@TA.X)(Self, I);
  ShowMessage('3: ' + I.ToString);
end;

[MichaelT]

Nein. Solltest du meiden.

Es gibt in C++ diese Art des Aufrufs, mit dem wird aber im Falle von Multiple Inheritance zwischen den Base Classes unterschieden in erster Linie.

Gute Frage wäre ob du nicht einfach ein Objekt der entfernten Basisklasse erzeugst und das Ergebnis verwendest. Ob das Sinn macht sei dahingestellt.

Ich würde nicht ausschließen, ...