Aufruf abstrakter Methode führt zu Fehler

[Jazzman_Marburg]

Hallo Gemeinde,
ich verstehe das Folgende nicht, und hoffe ihr habt eine Idee: Es kommt zum Fehler beim Aufruf einer abstrakten Methode.

Delphi-Quellcode:

  TFahrzeug = CLASS(TObject)

  ...
  PROCEDURE Verzoegern; VIRTUAL; ABSTRACT; // Fahrzeugabhängig, daher abstrakt.
  PROCEDURE Beschleunigen; VIRTUAL; ABSTRACT; // Fahrzeugabhängig, daher abstrakt.

  END;

  TPKW = CLASS(TFahrzeug)
  PRIVATE

  PROTECTED

  PUBLIC

    PROCEDURE Verzoegern; OVERRIDE;
    PROCEDURE Beschleunigen; OVERRIDE;

In meiner Oberklasse TFahrzeug habe ich zwei Methoden als Abstract deklariert, da sie erst im Nachfahren implementiert werden soll. Im Nachfahren habe ich diese Methoden mit OVERRIDE überschrieben und implementiert -- dennoch kracht es nun beim Aufruf einer dieser Methoden: 'Abstrakter Fehler'.
Ich sehe auch keine Warnung im Sinne von 'a verdeckt b'.

Jemand eine Idee, was ich da falsch mache?

Vielen Dank
Jazzman

[Hansa]

Welchen Vorteil erwartest Du denn von dem ABSTRACT ? Lasse das weg und mache leere Methode, die erst später konkret besetzt wird.

[USchuster]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1081310)

In meiner Oberklasse TFahrzeug habe ich zwei Methoden als Abstract deklariert, da sie erst im Nachfahren implementiert werden soll. Im Nachfahren habe ich diese Methoden mit OVERRIDE überschrieben und implementiert -- dennoch kracht es nun beim Aufruf einer dieser Methoden: 'Abstrakter Fehler'.
Ich sehe auch keine Warnung im Sinne von 'a verdeckt b'.

Jemand eine Idee, was ich da falsch mache?

Rufst Du zufällig

Delphi-Quellcode:

inherited Methodenname;

in den Implementierungen auf? (auch wenn das keinen Sinn macht)

Folgendes Beispiel funktioniert solange man nicht ABSTRACTERROR definiert.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

{.$DEFINE ABSTRACTERROR}

uses
  SysUtils;

type
  TFahrzeug = class(TObject)
    procedure Verzoegern; virtual; abstract;
    procedure Beschleunigen; virtual; abstract;
  end;

  TPKW = class(TFahrzeug)
  public
    procedure Verzoegern; override;
    procedure Beschleunigen; override;
  end;

{ TPKW }

procedure TPKW.Beschleunigen;
begin
  inherited {$IFDEF ABSTRACTERROR}Beschleunigen{$ENDIF};
  asm
    nop
  end;
end;

procedure TPKW.Verzoegern;
begin
  inherited {$IFDEF ABSTRACTERROR}Verzoegern{$ENDIF};
  asm
    nop
  end;
end;

var
  Fahrzeug: TFahrzeug;
begin
  try
    Fahrzeug := TPKW.Create;
    try
      Fahrzeug.Beschleunigen;
      Fahrzeug.Verzoegern;
    finally
      Fahrzeug.Free;
    end;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  ReadLn;
end.

[Jazzman_Marburg]

Zitat:

Zitat von Hansa (Beitrag 1081312)

Welchen Vorteil erwartest Du denn von dem ABSTRACT ?

Hmmm... ich dachte 'man' macht es so -- es steht so in den Lehrbüchern... keine Ahnung!

Darüber muß ich nochmal nachdenken. :gruebel:

Jazzman

[Jazzman_Marburg]

Zitat:

Zitat von USchuster (Beitrag 1081319)

Rufst Du zufällig

Delphi-Quellcode:

inherited Methodenname;

in den Implementierungen auf?

Nein.

Den Rest (Beispiel) verstehe ich nicht. :pale:

Trotzdem Danke
Jazzman

[BUG]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1081326)

Hmmm... ich dachte 'man' macht es so -- es steht so in den Lehrbüchern... keine Ahnung!

Der Vorteil besteht darin, das man die Methoden implementieren muss.

Wenn man eine Klasse schreibt, deren Elternklasse TPerson die abstrakte Methode aufDenKopfStellen hat, sollte man diese Methode implementieren, denn irgendwo gibt es Code, der sich darauf verlässt, das sich das Objekt auf den Kopf stellt (egal wie es das anstellt!), wenn diese Methode aufgerufen wird. Wenn die Methode in der Elternklasse einfach leer gelassen würde, wäre das nicht ersichtlich.

So würde der Code, der dem TPerson-Objekt ein paar warme TSocken anziehen soll, diesem die eventuell über die Ohren ziehen, weil sich das Objekt nicht ordnungsgemäß mit den Füßen nach oben auf den Kopf gestellt hat :drunken:

Und das würdest du beim Kompilieren dann nicht merken.

[r2c2]

Zeig mal den Methodenaufruf. Bist du dir sicher, dass du das richtige Objekt instanziiert hast und die richtige Methode aufrufst?

mfg

Christian

[Hansa]

Zitat:

Zitat von BUG (Beitrag 1081333)

Der Vorteil besteht darin, das man die Methoden implementieren muss.

@BUG : das ist kapitaler Denk-Bug. :mrgreen: "implementieren" würde ich an dieser Stelle auf deutsch als "umsetzen" bezeichnen. Oder "mit Leben erfüllen". Abstrakte Methoden zeichnen sich aber genau dadurch aus, dass sie nicht konkret vorhanden sind. Sie sind lediglich deklariert. Was wiederum heisst : es wurde ein Name vergeben für etwas, das nicht vorhanden, besser gesagt noch nicht umgesetzt ist. Denkt man jetzt, die Methode wäre bereits "implementiert", die ist es aber nicht, dann kommt "abstrakter Fehler", sofern man die benutzen will.

Deshalb mein Vorschlag, die Methode als leeren Rumpf zur Verfügung zu stellen und nicht nur zu deklarieren. Unterschied ist :

Delphi-Quellcode:

virtual; abstract

und

Delphi-Quellcode:

virtual;

machen beide nichts, was nicht implementiert ist. Kommt "abstract" zusätzlich ins Spiel, dann wird wie gesagt, nichts gemacht, ausser zusätzlich eine Fehlermeldung zu produzieren.

[BUG]

Ich glaube, ich habe mich etwas schwammig ausgedrückt.

Zitat:

Zitat von Hansa (Beitrag 1081370)

Denkt man jetzt, die Methode wäre bereits "implementiert", die ist es aber nicht, dann kommt "abstrakter Fehler", sofern man die benutzen will.

Das sehe ich als Vorteil. Leere Methoden sind nicht in allen Fällen korrekte Implementierungen für bestimmte Methoden.

Wenn ich einen abstrakten Fehler bekomme, habe ich dann die Wahl:

1. die Methode "richtig" zu implementieren
2. eine leere Methode zu erstellen und zu wissen, das irgendwas schief gehen kann

In beiden Fällen habe ich darüber nachgedacht, was ich tue.
Ohne abstract hätte ich nicht mitgekriegt, das überhaupt etwas schief laufen könnte.

[Sir Rufo]

Zitat:

Zitat von BUG (Beitrag 1081374)

Ich glaube, ich habe mich etwas schwammig ausgedrückt.

Zitat:

Zitat von Hansa (Beitrag 1081370)

Denkt man jetzt, die Methode wäre bereits "implementiert", die ist es aber nicht, dann kommt "abstrakter Fehler", sofern man die benutzen will.

Das sehe ich als Vorteil. Leere Methoden sind nicht in allen Fällen korrekte Implementierungen für bestimmte Methoden.

Wenn ich einen abstrakten Fehler bekomme, habe ich dann die Wahl:

1. die Methode "richtig" zu implementieren
2. eine leere Methode zu erstellen und zu wissen, das irgendwas schief gehen kann

In beiden Fällen habe ich darüber nachgedacht, was ich tue.
Ohne abstract hätte ich nicht mitgekriegt, das überhaupt etwas schief laufen könnte.

Genau so ist das :thumb:
Eine Art Documentation by Design