Zitat von
Muetze1:
Der definitive Vorteil: Du hast als Basisklassenprogrammierer die Sicherheit, das die Methode implementiert wird in der Ableitung - ausser natürlich man schlägt alle Warnungen und Hinweise des Compilers in den Wind...
Exakt!
Oder aus einer anderen Richtung betrachtet:
Ist eine Klassenfamilie erst einmal sinn-, ziel- und funktionsgerecht
fertig programmiert, so ist es dem Programmierer, der sie einsetzt, wurscht, ob abstrakte Methoden darin vorkommen oder nicht. Sie tut, was sie soll, und gut.
Die Verwendung von abstract soll und kann aber dem Klassenprogrammierer bei der
Entwicklung (und Erweiterung) dieser Klassenfamilie helfen,
überhaupt da hin zu kommen, nämlich sie fehlerfrei zu gestalten. Und
wenn sie fehlerfrei ist, so kommt es auch zu keinen Abstract-Fehlern, die man debuggen müsste.
Ich verstehe daher, Hansa, deine Sorgen bzgl. des "Debuggen von abstrakten Methoden" nicht.
a.) Als Programmierer, der eine fertige Klassenfamilie in seinem Projekt einsetzt, sagt dir ein Abstract-Error, dass die Klassen Schrott sind, weil der Klassenprogrammierer wohl geschlafen hat. Sei dann froh, dass es dir gemeldet wurde, nimm es zur Kenntnis, und verzichte auf die Klassen.
b.) Als Klassenprogrammierer sagt dir ein dabei auftauchender Abstract-Error, dass du Mist gebaut hast. Sei dann froh, dass es dir gemeldet wurde, nimm es zur Kenntnis und korrigiere deine Klassen, damit sie anständig funktionieren.
Somit ist doch der Abstract-Error in jedem Fall eine Hilfestellung zur fehlerfreien Programm- und Klassenerstellung.