Ja, war C+P Fehler.
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 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.
