Extract Method und IOSP

395 views
Skip to first unread message

Leba

unread,
Mar 20, 2014, 5:21:35 PM3/20/14
to clean-code...@googlegroups.com
Extract Method ist ein Refactoring, welches ich (und sicher viele andere auch) sehr oft anwende, um den Code übersichtlicher und besser lesbar zu machen und ggf. um Kommentare zu ersetzen. Wie passt dies jedoch zum Integration Operation Segregation Principle? Bzw. führt das traditionelle Extract Method Refactoring zu einem Verstoß gegen das IOSP.

Ein Beispiel. Die folgende Methode hat erstmal keine Abhängigkeiten (vernachlässigen wir jetzt mal die Abhängigkeit zu der Variablen _best, diese könnte man sehr leicht los werden.. aber mir geht es jetzt erstmal um etwas anderes). Die Methode ist also ein Blatt im Abhängigkeitsgraph und enthält reine Operation. Jetzt möchte ich allerdings gerne die logischen Verknüpfungen am Anfang auslagern.

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?


Stefan Lieser

unread,
Mar 20, 2014, 5:48:26 PM3/20/14
to clean-code...@googlegroups.com
Hallo Leif,

hast dir wieder eine gute Frage ausgedacht :-)

Versuche doch mal, erst das if/else auf der obersten Ebene herauszuziehen. Etwa so:
PrüfenObRestVorhanden(Action onKeinRest, Action onRest)
  if(...) 
    onRest();
  else
    onKeinRest();

Abschliessend kannst du die Bodies im hetzigen if und else Zweigt extrahieren und als Continuation reinreichen. 

Ich schreibe vom iPhone, daher jetzt nicht mehr Code ;-)

Viele Grüße
Stefan Lieser
--
--
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.

Leba

unread,
Mar 20, 2014, 8:20:00 PM3/20/14
to clean-code...@googlegroups.com
Hallo Stefan,

danke für die schnelle Antwort :)
Keine Abhängigkeiten mehr (bis auf die Variablen), perfekt! Ich musste dann auch die Methode BerechneRek selber für den rekursiven Aufruf als Continuation hereinreichen.

Ich hatte erst gedacht, dass man wegen der Rekursion die Logik nicht komplett auslagern kann. Deswegen hatte ich extra dieses Beispiel gewählt. Aber es ja geht anscheinend doch. 

Meine Frage steht jedoch immer noch im Raum. Was ist mit dem herkömmlichen Extract Method Refactoring?
Ich würde sagen 1. Wahl ist, wie in diesem Beispiel die gesamte Klasse aufzuräumen.
Wenn das zu schwierig ist, dann ist ja sowieso was faul.

Angenommen dies geht jedoch nicht, warum auch immer, sollte man dann die entsprechende Methode immer als Continuation hereinreichen?

Stefan Lieser

unread,
Mar 21, 2014, 1:38:33 AM3/21/14
to clean-code...@googlegroups.com
Hallo Leif,

> Meine Frage steht jedoch immer noch im Raum. Was ist mit dem herkömmlichen Extract Method Refactoring?
> Ich würde sagen 1. Wahl ist, wie in diesem Beispiel die gesamte Klasse aufzuräumen.
> Wenn das zu schwierig ist, dann ist ja sowieso was faul.
>
> Angenommen dies geht jedoch nicht, warum auch immer, sollte man dann die entsprechende Methode immer als Continuation hereinreichen?

Würde ich nicht zwingend tun. Das IOSP ist ja kein Selbstzweck. Wenn man nicht entworfen hat und der Code dann so aussieht wie er aussieht, muss man sich eben erst mal mit weniger zufrieden geben. Extract Method macht die Sache schon besser im Sinne der Lesbarkeit und Testbarkeit. Wenn eine Continuation die Testbarkeit noch erhöht, fein, dann nehme ich die. Aber das Wurzelproblem bleibt ja der fehlende Entwurf.

Viele Grüße
Stefan lieser
--

Reply all
Reply to author
Forward
0 new messages