Aufruf abstrakter Methode führt zu Fehler

[Sir Rufo]

@Hansa ich weiß nicht wo du bist, wir sprechen hier über virtal abstract und da gibt es einen Compiler-Fehler wenn nicht deklariert wurde.

Vielleicht hast du dich ja im Thread geirrt

Ach, das mit der Dokumentation meine ich nicht als Doku für den Enduser sondern für den Entwikler der eine Basisklasse erweitern möchte/soll/muss.

[Hansa]

Zitat von Sir Rufo:

... wir sprechen hier über virtal abstract...

Du meinst wohl "virtual". Ich rede jedenfalls über so etwas :

Delphi-Quellcode:

type
  TKlasse1 = class
     procedure test; virtual; abstract;
  end;

  TKlasse2 = class (TKlasse1)
     procedure test;
  end;

var
  Klasse1 : TKlasse1;
  Klasse2 : TKlasse2;

ABSTRACT alleine geht überhaupt nicht !

Zitat:

..und da gibt es einen Compiler-Fehler wenn nicht deklariert wurde

Nein, aber wenn es fehlerhaft implementiert ist, also :

Delphi-Quellcode:

type
  TKlasse1 = class
     procedure test; virtual; abstract;
  end;

var
  Klasse1 : TKlasse1;

procedure TKlasse1.UndeklarierteImplementierung;
begin
end;

aber nicht deklariert ist (in der Klassen-Definition), dann ist die Prozedur erstens "unknown identifier" und zusätzlich kommt noch "Ungenügende Forward- oder External-Deklaration". Ist die Prozedur deklariert mit ABSTRACT, dann reicht das. Mehr geht nicht mal (insbesondere keine konkrete Implementierung). Dann kommt nämlich hier :

Delphi-Quellcode:

procedure TKlasse1.test;
begin
  ShowMessage('');
end;

dieser Compilerfehler :

Zitat:

[Fehler] TestUnit.pas(45): Definition für abstrakte Methode 'test' nicht erlaubt

In obigem Fall muss/darf die procedure TKlasse1.Test; nicht implementiert werden, man kann im Programm trotzdem auf diese Prozedur zugreifen und produziert damit erst zur Laufzeit einen Fehler. Trotz des Fehlers lässt sich eine EXE erstellen, die lauffähig ist und eben Fehlermeldungen produziert. So richtig nach dem Motto : "es compiliert, wir können ausliefern".

[Hawkeye219]

Hallo,

bei neueren Delphi-IDEs kann man Warnungen des Compilers über die Projektoptionen in Fehlermeldungen umwandeln (Delphi-Compiler -> Hinweise und Warnungen: "Ausgabewarnungen"). Für ältere IDEs stellen die DDevExtensions eine entsprechende Funktionalität bereit.

Gruß Hawkeye

[alzaimar]

Hansa's Ansatz bedeutet einfach: "Die Methode kannst Du überschreiben, musst Du aber nicht". Der 'abstract' Ansatz bedeutet einfach: "Du musst die Methode noch überschreiben".

Schön wäre es, wenn der Compiler beim abstract-Ansatz wirklich einen Fehler moniert. Leider macht er das wohl nicht, aber man kann sich auch so herausreden, das ein guter Entwickler sowieso eine umfangreiche Test-Unit mit seiner Klasse ausliefert, die dann auf nicht implementierten Methoden prüft.

Ansonsten rennt ihr euch hier in Klugscheißerei fest, wenn ihr so weiter macht. Bisher ist davon natürlich weit und breit nichts zu sehen.

[Hansa]

Zitat von alzaimar:

..Schön wäre es, wenn der Compiler beim abstract-Ansatz wirklich einen Fehler moniert. Leider macht er das wohl nicht...

Der Compiler wird das nie machen KÖNNEN ! Wie denn ? Der hat ja nur einen Namen und das wars. Und er muss das abstrakte ja compilieren. Sonst ist bei virtual; abstract; ja nichts da. Beim Debugger gehts dann weiter. Wo soll denn der anhalten ?

Mir wirds aber auch zu blöd. Wer unbedingt unnötige Fehlermeldungen im eigenen Programm haben will, der soll die Implementierung (auch wenn sie leer sein sollte) eben einfach weglassen.

[FaTaLGuiLLoTiNe]

Eine Klasse ist abstrakt, wenn sie entweder selber abstrakte Methoden deklariert oder solche von einer Elternklasse erbt, aber nicht selbst implementiert (überschreibt).

Da das Deklarieren einer abstrakten Klasse an sich nichts Verwerfliches ist, gibt der Compiler natürlich keine Warnung aus, wenn er eine solche findet. Die Warnung kommt erst dann, wenn man versucht, eine abstrakte Klasse zu instanziieren.

Delphi-Quellcode:

program AbstraktTest;

{$APPTYPE CONSOLE}

uses
  SysUtils;

type
  TAbstraktBasis = class(TObject)                // Abstrakte Klasse, da abstrakte Methode deklariert
  public
    procedure Methode; virtual; abstract;
  end;

  TAbstraktAbgeleitet = class(TAbstraktBasis);   // Abstrakte Klasse, da abstrakte Methode geerbt

  TKonkretAbgeleitet = class(TAbstraktBasis)    // Keine abstrakte Klasse, da Methode implementiert
  public
    procedure Methode; override;
  end;

{ TKonkretAbgeleitet }

procedure TKonkretAbgeleitet.Methode;
begin
 WriteLn('Methode wurde implementiert');
end;

{ Programmcode }

var AbstraktBasis: TAbstraktBasis;
    AbstraktAbgeleitet: TAbstraktBasis;
    KonkretAbgeleitet: TKonkretAbgeleitet;

begin
 // Versuche, abstrakte Basisklasse zu instanziieren:
 AbstraktBasis := TAbstraktBasis.Create;

 // Versuche, abstrakte abgeleitete Klasse zu instanziieren:
 AbstraktAbgeleitet := TAbstraktAbgeleitet.Create;

 // Versuche, konkrete abgeleitete Klasse zu instanziieren:
 KonkretAbgeleitet := TKonkretAbgeleitet.Create;
end.

Zitat von Delphi 7 - Compiler:

[Warnung] AbstraktTest.dpr(36): Instanz von 'TAbstraktBasis' mit der abstrakten Methode 'TAbstraktBasis.Methode' wird angelegt
[Warnung] AbstraktTest.dpr(39): Instanz von 'TAbstraktAbgeleitet' mit der abstrakten Methode 'TAbstraktBasis.Methode' wird angelegt

Also ist die Aussage, der Compiler würde 'beim abstract-Ansatz keinen Fehler monieren', schlichtweg falsch. Oder habe ich jetzt das Thema verfehlt?

[Blup]

Die einzige Schwachstelle des Compilers ist, das er an dieser Stelle nicht warnt:

Delphi-Quellcode:

procedure TKonkretAbgeleitet.Methode;
begin
 inherited Methode; // <- keine Warnung 
 WriteLn('Methode wurde implementiert');
end;

Und dieser Programmierfehler wird auch hier die Ursache des Problems sein.