Aufruf abstrakter Methode führt zu Fehler

[Bummi]

[r2c2]

Und noch mehr: Man erhält i.d.R. eine Warnung zur Compiletime (in anderen Sprachen sogar einen Fehler). Das hilft Bugs gar nicht erst entstehen zu lassen.

Das mit den leeren Methoden kann auch seinen Sinn haben. Wenn diese von anderen (nicht abstrakten) Methoden aufgerufen werden, wären das dann so genannte HookMethods. Also quasi Stellen, in die ich Code einfügen kann, aber nicht muss. Abstrakte Methoden sind hingegen eher TemplateMethods. Hier *muss* ich etwas implementieren. Beides braucht man oft, wenn man n Framework schreibt.

Abstrakte Methoden, die nicht unbedingt intern aufgerufen werden, gibt es auch sehr oft in Klassen, die die Anwendungsdomäne modellieren.

In leeren Methoden, die keine HookMethoden sind, sehe ich momentan keinen sonderlichen Sinn. Fällt euch einer ein?

Fakt ist, dass die Exception "Abstrakter Fehler" auf einen Bug hindeutet. Man könnte die Exception unterdrücken, wenn man ne leere Methode dafür einsetzt. Der eigentliche Bug wird dadurch aber nicht behoben...

mfg

Christian

[Sir Rufo]

Eine relativ simple Klasse die man sich als Beispiel dazu anschauen kann ist TStrings und als Ableitung davon TStringList

[Hansa]

Zitat von BUG:

Ohne abstract hätte ich nicht mitgekriegt, das überhaupt etwas schief laufen könnte.

Du kriegst es aber erst mit, wenn es zu spät ist. Weil das hier :

Zitat von Sir Rufo:

Eine Art Documentation by Design

so nicht stimmt. Man könnte allenfalls sagen : "Dokumentation durch Laufzeitfehler". Ich sehe das allerdings wohl zu sehr aus Sicht des Endbenutzers. Leere Methode einbauen oder lediglich sowas : showmessage ('Funktion kommt mit nächster Version'); Alternative : nur "abstract" deklarieren und es kommt das:

Zitat:

---------------------------
Testpro
---------------------------
Zugriffsverletzung bei Adresse 004DD37D in Modul 'TestPro.exe'. Lesen von Adresse 00000000.
---------------------------
OK
---------------------------

Ungeduldiger Enduser würde wohl folgendes sagen : Fall 1 : "wann geht denn das endlich ?" Fall 2 : "ihr Scheissprogramm geht ja immer noch nicht ! Kommen morgen immer noch Fehlermeldungen, dann wollen wir unser Geld zurück !" Die Theoretiker können ja dann mit ABSTRACT ankommen, dass das eben so ist. Ähnlich sieht es auch mit der Frage aus, um die es hier geht. Ohne ABSTRACT bräuchte man hier gar nicht zu diskutieren.

[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?