override - overload - reintroduce - virtual

[DeddyH]

Das ist aber manchen Leuten zu abstrakt :mrgreen:

[mkinzler]

Zitat:

Zitat von DeddyH

Das ist aber manchen Leuten zu abstrakt :mrgreen:

so neumodisches Zeugs ... :lol:

[cn-tools]

Zitat:

Zitat von Hansa

Also nochmals im Klartext : auf abstract verzichten und lieber leere Methode einbauen, die sofort eingesetzt werden kann, selbst wenn sie anfangs nichts macht. Macht mans anders, dann ist die Gefahr ziemlich hoch, sich dauernd "abstracte" Compiler-Fehlermeldungen einzufangen.

Wenn ich das so mache, kann ich nicht compilieren weil die Meldung:
[Pascal Fehler] Source.pas(37): E2037 Deklaration von 'GetMD' unterscheidet sich von vorheriger Deklaration

Ausserdem würde in diesem Fall doch das Problem sein, wenn in der Klasse TKlasseA die Mehtode GetMD aufgerufen wird auch jene der TKlasseA verwendet wird und nicht - wie gewünscht - jene von TKlasseB.

Zitat:

Zitat von mkinzler

Oder man macht es richtig! Den die Verwendung von abstrakten Methoden macht Sinn. Bei neueren Delphiversionen kann man zudem mit strikt abstrakte Methoden nehmen ( Fehler nicht erst zur Laufzeit bei Zugriff)

Muss jetzt blöd fragen: wie wäre es richtig? :?:

[himitsu]

Laut deinen Vorgaben/Wünschen das Mittlere in der #4

Zitat:

Zitat von cn-tools

Wenn ich das so mache, kann ich nicht compilieren weil die Meldung:
[Pascal Fehler] Source.pas(37): E2037 Deklaration von 'GetMD' unterscheidet sich von vorheriger Deklaration

Wie gesagt, beim Override muß die Signatur (die Deklarationen aller Parameter-Typen und des Results) übereinstimmen.

Zitat:

Delphi-Quellcode:

TKlasseB = class(TKlasseA)
  function GetMD: TModelKlasseB; override;

Bei Hansa war das entweder ein Copy&Paste-Fehler oder er hat es einfach nur übersehn TModelKlasseB muß TModelKlasseA sein, also mit dem GetMD von TKlasseA übereinstimmen.

[mkinzler]

Zitat:

Wenn ich das so mache, kann ich nicht compilieren weil die Meldung:
[Pascal Fehler] Source.pas(37): E2037 Deklaration von 'GetMD' unterscheidet sich von vorheriger Deklaration

Das hat aber nicht mit abstract zu tun

Zitat:

Muss jetzt blöd fragen: wie wäre es richtig? Question

Das Prinzip der abstrakten Methoden/Klassen setzt man ein, wenn man ein bestimmtes Verhalten von abgeleiteten Klassen erzwingen will, eine Implementierung auf dieser Ebene nicht möglich/sinnvoll ist.
Das besondere an Delphi ist, dass es, im Gegensatz zu anderen Sprachen, möglich ist eine Klasse mit abstrakten Methoden zu instantiieren. Eine Fehlermeldung erfolgt erst zur Laufzeit bei dem Versuch auf eine solche Methode zuzugreifen. Hansa will das verhindern, in dem er Dummy-Implementationen in der Basisklasse einfügt. das halte ich für den falschen Weg; zudem wenn man leere Methoden verwendet ( man könnte auch ein Meldung ausgeben).

[Hansa]

Ja, war C+P Fehler. :zwinker: Wo liegt jetzt der Unterschied abstract / vorhandener, aber leerer Vorfahr ? Letzterer kann sofort benutzt oder mit Leben gefüllt werden. Auch wenn er am Anfang leer ist. Ohne grosse Änderungen auch erst später. Ohne nervige Fehlermeldungen. Unnötige wohlgemerkt ! Beide sollen direkt aufgerufen ja vorerst nichts machen. "Abstract" macht allerdings noch folgendes : Laufzeitfehler produzieren. Dann mal viel Glück, die verursachende Stelle zu finden. Ich kann nur aus der Praxis sagen, dass manchmal schon auch der Vorfahr mit irgendwas nachträglich bestückt wird.

Könnte sein, dass abstract 1 Byte spart, aber wen interessiert das ? Blöd ist ausserdem, dass man immer dran denken muss, wo inherited aufgerufen wird. Ist das die Vorfahrmethode, die nichts macht, dann kommt bei Abstract-Deklaration auch Laufzeitfehler, ansonsten passiert eben nichts.

Zitat:

Zitat von mkinzler

zudem wenn man leere Methoden verwendet ( man könnte auch ein Meldung ausgeben).

Welche Meldung ? Allerdings : in der Tat. War auch schon der Fall : showmessage ausgeben in Basisklasse. Dann gilt : 1 Zeile einfügen. Bei abstract : Methodenkopf in virtual ändern und die Methode erst mal schreiben. Und dann wieder alles zurück. D.h. showmessage-Zeile löschen oder Methodenkopf wieder abstract machen und Methode selbst löschen. Ich kenne abstract eigentlich nur von vorgefertigten Komponenten. Da hat sich der Entwickler Gedanken gemacht, was vielleicht von irgendwem gebraucht werden könnte und dementsprechend schon mal Namen dafür festgelegt. Mehr nicht ! Warum macht der das denn so ? Nun, wird der Quelltext nicht rausgerückt oder ist zu umfangreich um gewisse Stellen einfach zu finden, dann stehen zumindest die Methoden zur Verfügung (vom Namen her). Tja, wer im eigenen Programm von abstract stammende Fehlermeldungen braucht, der soll das dann eben damit machen. :shock:

[DeddyH]

Dazu einmal ein Beispiel: angenommen, man deklariert eine Basisklasse TTier. Jedes Tier bewegt sich fort, aber eben nicht auf die gleiche Weise (schwimmen, laufen, kriechen, etc.), so dass eine Implementierung in der Basisklasse keinen Sinn macht. Also deklariert man die Methode Fortbewegen abstrakt, damit die abgeleiteten Klassen diese jede für sich implementieren können bzw. müssen. Wird dies in einer dieser Klassen vergessen, bekommt man eine Fehlermeldung. Implementiert man hingegen leere Methoden in der Basisklasse, kommt keine Fehlermeldung, aber es kann passieren, dass eine abgeleitete Klasse dann die leere Elternmethode aufruft, was ja nicht im Sinne des Erfinders ist.

[cn-tools]

Danke für Eure Mühe...
Löse es jetzt ohne ABSTRACT und mit REINTRODUCE VIRTUAL...

Auch wenn es dann eigentlich nicht so implementiert ist wie ich es gerne hätte...

TROTZDEM DANKE @ ALL

[mkinzler]

Zitat:

Löse es jetzt ohne ABSTRACT und mit REINTRODUCE VIRTUAL...

Dirty is nicer .... :zwinker: