Case-Anweisung auf Enumerationstyp. Eines Tages wird der Enumerationstyp erweitert.

[Uwe Raabe]

Das hast du noch nicht ganz richtig verstanden. Da deine Methode eine Eigenschaft des übergebenen Parameters bzw. die Zugehörigkeit zu einer Gruppe prüft, ist erstens die case-Anweisung an sich fraglich und zweitens eine Ableitung wegen einer vergrößerten Testmenge auch nicht gerade pfiffig. Ohne jetzt weiter auf die adäquate Lösung des Musikantenproblems einzugehen, lieber mal ein Beispiel für das was Bernd eigentlich meint.

Wenn das case-Konstrukt allein dafür da ist, unterschiedliche Implementationen aufzurufen, ist es eigentlich ratsamer für jede Implementation eine abgeleitete Klasse zu schreiben und dann je nach gewünschter Implementation die passende Klasse zu instantiieren. Dabei verlagert man dann den case-Konstrukt aus der Implementationsauswahl an die Stelle, wo die richtige Klasse ausgewählt werden muss. Die Idee dahinter ist eigentlich die, daß eine Klasse nur für eine bestimmte Aufgabe bestimmt sein und nicht mehrere Aufgaben zusammenfassen soll. Bei einer neuen Aufgabe erweitert man dann nicht die Funktionalität der einen Klasse sondern schreibt eine eigene.

Würde man das Musikantenproblem so implementieren, dann würde man eine Basis-Klasse schreiben, die eine

function checkIsInBremerStadtMusikanten: Boolean; virtual; abstract;

deklariert, und davon für jedes mögliche Tier eine Ableitung bereitstellt, die diese Funktion entsprechend implementiert. Je nach abzufragendem Tier verwendest du dann die entsprechende Klasse. Das ist natürlich blanker Unsinn und man sieht dabei schön, daß man ein Clean Code Prinzip nicht blind auf alle möglichen Fälle anwenden sollte.

Für diesen konkreten Fall wäre ein set of TAnimal die bessere Wahl.