nicht angemeldet
Rolf bDas switch-statement mit den vielen cases ist ein typischer Fall für Do One Thing Probleme. Wenn in den cases jeweils steht, was zu passieren hat, ist es meistens nicht mehr clean. Dann bietet sich eine Methode für die Fallunterscheidung an und jeder Fall ist eine eigene Methode. Ein Switch ist aber auch oft ein Indiz für verpasste Polymorphie, und wenn sich einer einschleicht, sollte erstmal die Warnglocke läuten.
Es sei denn, jeder Fall tut nichts weiter als einem Wert A einen Wert B zuzuordnen. DANN sollte die Methode aber auch nichts weiter als diesen switch enthalten, danach zugeklappt werden und weggesperrt 😉. Oder vielleicht durch eine Lookup-Hashtabelle ersetzt werden.
Wenn Du viele Parameter übergeben musst, kann das für Methodenkohärenz sprechen. D.h. diese Methoden gehören zusammen in eine gemeinsame Klasse ausgelagert. Das ist der von mir erwähnte Worker.
Für ältere Praktikanten der Programmierkunst sind solche Überlegungen fremd bis schmerzlich. In den 80ern sah Code einfach anders aus. Inlining war eine Disziplin, die Compiler nicht unbedingt beherrschten, und man ersetzte es durch Makros. Funktionsnamen waren kurz und knackig (weil Editoren mit intelligenter Code-Vervollständigung fehlten).
Methodennamen bei Martin sind halbe Romane, du liest den Methodennamen und weißt schon, was die Funktion tut. Nicht WIE sie es tut. Das ist ja auch wurscht, solange Du weißt, WAS es ist. Dann springst Du nämlich nicht hin und her. Du siehst einen Aufruf
var endKapital = berechneEndKapitalNachLaufzeit(grundKapital, zinssatz, laufzeitInJahren);
und musst eigentlich in die berechne-Methode nicht hineinschauen. Es sei denn, du hast Grund zur Annahme, dieser Methode zu misstrauen. Aber DANN guckst Du in die Unit-Tests für diese Methode und schaust, was da getestet wird. Ist der Fall, dem Du misstraust, nicht dabei - okay, schreib einen Test dafür. Lass die Tests laufen. Geht dein neuer Test durch, ist dein Misstrauen unbegründet und du hast eine Lücke im Test geschlossen.
Natürlich gehört zu Clean Code noch viel mehr. Martin empfiehlt, möglichst wenige Parameter zu verwenden, und Seiteneffekte sind des Teufels.
Martin schreibt auch, dass er bei einem neuen System nicht mit Clean Code beginnt. Seine Methoden sind zu lang, zu komplex, die Namen blöd gewählt. Er bringt es erstmal zum Laufen und schreibt Tests, die diese Methoden absichern. Und dann beginnt er, graduell auszulagern, zu zerlegen, zu refaktorieren. Solange die Tests weiter durchgehen, macht er alles richtig. Wenn nicht - na gut. Dann muss man gucken ob der Test ungenau oder die Refaktorierung blöd war.
Clean Code direkt von Anfang an schreiben? Das kann niemand, meint Martin. Erstmal schreiben. Unittests schreiben. VIELE. Und dann refaktorieren, bis es gut ist.
Rolf