Aufruf abstrakter Methode führt zu Fehler

[Jazzman_Marburg]

Zitat von Hansa:

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.

Jazzman

[BUG]

Zitat von Jazzman_Marburg:

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

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 von BUG:

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

@BUG : das ist kapitaler Denk-Bug. "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 : virtual; abstract und 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 von Hansa:

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 von BUG:

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

Zitat von Hansa:

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
Eine Art Documentation by Design

[Bummi]

[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".