nicht angemeldet
Damit ich die 20 Ableitungen nicht alle anpassen muss, bekommt die erste Ebene meiner Vererbungshierarchie eine "Dummy" Methode
Stell dir mal vor jemand anderes benutzt dein Programm. Da ist nun also eine Methode, die da lautet "Diese Methode macht aus X ein Y". Er ruft sie also auf, aber anstatt das zu machen, was sie verspricht, tut sie etwas völlig anderes. Deine Lösung ist also definitiv nicht gut.
Vererbung heißt auch Overload. Eine Methode, die in der Basisklasse aus einem X ein Y macht, kann und darf in einer Subklasse aus einem X auch ein Z machen.
Ja, syntaktisch darf sie das. Semantisch nur dann, wenn sie sich an den Vertrag hält. In Java darfst du beispielsweise die equals() und hashCode() Methoden nicht unabhängig voneinander überschreiben, wenn das dazu führt, dass deren Ausgaben inkonsistent werden und ein equals() true ergibt, aber hashCode() einen unterschiedlichen Hash liefert.
Du KANNST das natürlich tun und der Compiler wird nicht meckern. Es kann (und wird wahrscheinlich) früher oder später aber zu fehlern führen und ist deswegen zu vermeiden.
Hier kommt es freilich ein bischen darauf an, darauf zu achten, dass eine überladene Methode nicht was "völlig anderes macht", es sollte wenigstens dem Verwendungszweck einer Subklasse entsprechen.
Genau das ist der Punkt, weswegen eine Dummy Methode eben ganz ganz böse ist und man soetwas nicht tun sollte.
Und diesen Verwendungszweck sollten "Mitarbeiter" nicht anhand des vergebenen Methoden-Namen ersehen sondern aus einem übersichtlichen Code lesen und aus der gesamten Klassenhierarchie erkennen können (s. Anm.).
Es ist dennoch schlechter Stil.
Genauso verhält es sich mit "sprechendenden" Variablennamen, wenn eine Hash-Referenz $r_hash heißt
Bei statischer Typisierung hast du das Problem sowieso nicht. Da brauchst du kein "r_" und ähnliches, weil dir der Compiler sagt, was in der Variable drin steckt. Bei dynamischer Typisierung musst du eben "glauben" ;)