Als Ergebnis erhalte ich folgendes:
Definitiv ist die Methode nun sauberer und besser lesbar und auf der Abstraktionsebene der Methode sogar schneller zu verstehen. Aber was mache ich nun mit der Abhängigkeit zu der Methode BessereLoesung()? Früher hätte mich das nicht weiter gestört, doch jetzt bin ich mir nicht so sicher. Wenn ich Methoden sehe, die Logik enthalten und die andere Methoden aufrufen, beißt das schon fast so in den Augen, wie früher ein "new ...Service()", als ich die Vorzüge von DI kennengelernt habe ;-)
Nur, wie löst man das? Es ist unmöglich die komplette Logik aus der Methode auszulagern und eine reine Integrationsklasse zu erschaffen.
Man könnte die Methode als Parameter reinreichen. Wenn sich herausstellt, dass dies der beste Weg ist, dann müsste man eigentlich das Extract Method Refactoring anpassen und einen zweiten Schritt hinzufügen, nämlich das Auslagern der Integration oder alternativ das Auslagern der gesamten restlichen Logik.
Zuletzt gibt es noch die Möglichkeit diese Abhängigkeit bestehen zu lassen. In dem Beispiel ist das sicher nicht so tragisch, aber es geht hier ja um Prinzipien. Und oftmals findet man in Legacy Code viel tiefer verschachtelte Methodenaufrufe und komplexere Strukturen und dies ist sicher unter anderem ein Resultat davon, dass das ISOP missachtet wurde.
Also, stehen Extract Method im traditionellen Sinne und das ISOP im Konflikt? Falls ja, wie geht man am besten damit um?
--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "Clean Code Developer" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an clean-code-devel...@googlegroups.com.
Wenn Sie in dieser Gruppe einen Beitrag posten möchten, senden Sie eine E-Mail an clean-code...@googlegroups.com.
Gruppe besuchen: http://groups.google.com/group/clean-code-developer
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.