Wir setzen den Abschnitt 4-3 Refactoring Ford,
indem wir ein Beispiel diesen Katalog darstellen, die letzte,
der letzte Block, die letzte Aufzeichnung,
beendete damit, dass wir sagen,
es gibt hier einen Katalog von Refactorens von typischen Mängels,
Refactoring als typischen Mängeln, zusammen mit Refactoring,
sondern ich möchte das illustrieren, indem ich Ihnen das an einem Beispiel zeige,
und zwar wäre das hier das Refactoring.
Und nein, das war falsch, das Refactoring gehört auf diese Seite
Auf diese Seite gehört, dass Betsmerl. Und zwar wäre hier
das Bad Smilman Beispiel ein sehr einfaches, long mess it.
Long mess it ist deswegen ein schlechter, ein Mangel bezüglich Verständlichkeit,
weil es sehr wahrscheinlich ist, dass man in einer langen Methode,
die also viele Bildschirmseiten umfasst, dass man da den Überblick verliert,
dass man Sachen irgendwie doppelt macht, dass man Bezüge falsch hat oder so etwas.
Und es ist auch sehr zu vermuten,
dass eine Methode deswegen so lang ist,
weil man dann verschiedene Sachen miteinander vermischt hat,
die nicht unbedingt in eine Methode gehören
Deswegen versucht man diese lange Methode zu zerlegen.
Und das wären die Zerlegungsvorschläge. Das sind insgesamt vier Stück
. Zunächst gibt es das Refactoring Extract Method. Schreibt mal
richtig. Die Namen sind jeweils Namen aus dem Faulerbuch.
Ich kann Ihnen hier gleich die Seitenzahl mit annehmen.
Das wäre Seite 110. Im Faulerbuch. Und ich möchte Sie
ermutigen, da einfach gleich mal nachzuschauen. Als zweites,
das betrifft für 99 Prozent der Fälle zu Moment,
das nicht zutrifft, dann haben wir noch weitere Alternativen.
Biplay ist 10, bald with Query.
Wir haben hier noch ein viertes.
Das dritte lautet Griplays
Messert With. Messert Object. Und die Compos Conditional. So,
diese vier, und das ist das,
was ich jetzt meinte, wie eine Art Tabelle, ja,
also wir haben hier diese Zuordnung von Bad Smell zu Refactorings.
Und das ist das, was wir hier, was ich als Katalog von Erfahrungswissen nennen möchte.
Und das trägt natürlich dazu bei, dass man strukturiert vorgehen kann,
dass man sich, dass man Wissen auch ökumulieren kann.
Das heißt, wenn sie selbst so nach und nach einige
Betts mehr als kennenlernen, wird das dazu führen. Zum einen,
dass sie diese Fehlerbilder, diese typischen Mangelbilder vermeiden in ihrer Programmierpraxis,
aber zum anderen, dass sie nach und nach,
vielleicht kennen sie zu Anfang nur Extract Method,
das ist nebenbei bemerkt auch etwas, was die Tools super gut unterstützen können.
Bei den anderen ist das nicht immer so weit,
dass ihre Entwicklungsumgebung das gleich per Kontextmenü anbietet,
dass sie das machen können und tatsächlich,
wenn sie nach und nach einen der weniger häufigen Fälle haben,
nannten sie die anderen Reflekte übrigens auch, kennen auf diese Weise,
fühlt sich der Katalog, den sie im Kopf haben,
den sie für ihre tägliche Praxis zu befügen haben,
fühlt sich so langsam.
Ich möchte kurz vorstellen, wie dieses Extract Method funktioniert.
Das mache ich am Beispiel und das schauen wir uns,
das auf einer neuen Seite an. Bevor wir dazu kommen,
ach so, das sollte ich vielleicht ausschreiben,
dass wir jetzt hier Extract method,
dass wir das uns anschauen und das Ziel ist dir ganz klar,
dass wir eine kleine Methode,
eine kürzere Methode haben
Ich könnte natürlich auch sagen, ich mache einen Kommentar daneben und sage,
das Stückchen macht jetzt das und das, das Stückchen macht das.
Aber da wäre es viel besser, das Stückchen zu einer Methode zu machen.
Und ja, was sie wirklich tut, in den Methoden
Namen zu packen, statt das im Kommentar zu haben.
Mein Kommentar ist immer in der Gefahr,
dass er bei einer Veränderung nicht mitverändert wird.
Dann haben wir einen Kommentar, der was Falsches sagt und
das ist noch schlimmer als gar kein Kommentar.
Also hier eine kürzere Methode, hilft uns sehr.
Und was wir auch leichter, was wir auch erreichen können,
leichtere Umsetzung oder auch wenn sie wollen, bessere Nutzung von Objektorientierten Prinzipien.
So wie eben zum Beispiel Entkopplung oder Indirektion,
dass ich ganz klar damit arbeite, wer ruft ihr wen auf.
Das ist,
dass man ganz klar diese Dienstleisterklientenbeziehung haben
Und natürlich gibt es die Möglichkeit, dass deine Methodennahme,
das Aussage, die Aussage trägt. So,
das wollen wir erreichen durch Extract Method und wir könnten,
dass dadurch, wir vergehen gleich mal vor,
ich zeige gleich mal ein Bildchen, was da passiert.
Es könnte passieren, dass die Voraussetzungen dafür sind,
dass wir tatsächlich da keine Kopplung mehr haben,
wenn wir etwas auslagern
Der Ablauf sieht grundsätzlich so aus,
dass wir dieses ständige Testen nach jedem Schritt machen wollen.
Und das möchte ich gleichzeitig machen, parallel Ihnen auf dem nächsten Blatt darstellen,
was für Maßnahmen für das Risiko, auf die Risikominimierung.
Da sind hier zunächst der Ablauf erstmal als Überschrift und dann
fange ich mal gleich auf der nächsten Seite an in Fülle,
dass du nach und nach,
was sind Schritte für das geringe Risiko.
Da braucht man
eine neue Seite
Das ist eine der Zur Verringerung des Risikos bei Reflektoren,
hatten wir schon gehabt,
nämlich,
dass die Funktionalität
nicht geändert wird
Und Tests gütig bleiben. Das ist das Erste, was
wir hier tun wollen. Wenn wir wieder zurückgehen zu dem vorhergehenden Bild,
zu dem vorhergehenden Textstück, wenn wir das Extract Method durchführen,
ist natürlich, dass wir zunächst erst mal ermitteln.
Welcher Kotabschnitt
In eine neue Methode auszulagern ist. So,
das ist, wenn Sie hören, ich mache das,
nummeriere die Dinger mal, das wäre sozusagen der Schritt, null.
Das ist vor dem eigentlichen Refectoring. Dann wollen wir jeden
Schritt so durchführen, dass er das Verhalten nicht ändert,
dass wir das gesamte, den gesamten Ablauf dieser Methode testen können.
Der erste Schritt wäre demzufolge, wir müssen erstmal eine neue Methode anlegen
Und da möchte ich noch mal hier erwähnen, dass wir
das besonders sehr wichtig ist, den Namen zu machen.
Das würde also bedeuten, wir haben in einer neuen Klasse den,
wenn wir also mal hier sagen,
wir haben den Kotabschnitt in einer Klasse, ja,
dann haben wir erst mal bei dem Nötens haben wir das gekennzeichnet,
dass es hier vielleicht um diesen Bereich gehen soll, Dieser Bereich soll ausgelagert werden.
Das war das erste und dann haben wir erstmal nur einen neuen Kotabschnitt angelegt in dieser Methode.
Da ist aber noch nichts drin. Wenn wir danach den Test durchführen,
der Test würde sich natürlich nur auf diese Methode,
die wir vorher schon hatten, die jetzt zu lang war,
das ist die lange Methode, würde sich der Test darauf beziehen,
da werden daran nichts geändert haben,
würde der Test natürlich weiterhin erfolgreich sein.
Das heißt, wir können sicher sein,
der Schritt 1 führt nicht zu einem Fehler
Das zweite wäre, der zweite Schritt wäre,
dass mit dem betreffenden Code rüber kopieren.
Wenn wir den Code hier rüber kopieren,
dann bedeutet das ja,
macht das auch mal grün
So, dann haben wir ihn quasi zweimal. Ja,
das ist, sie werden jetzt sagen, wieso mache ich hier nicht Cut on Paste?
Ich mache Copy-Paste. Und dieses Copy-Paste führt dazu,
dass eigentlich der Original Originalmethode noch erhalten bleibt. Das heißt,
auch nach Schritt zwei wird es so sein,
wir könnten den Test durchführen,
wir können ihn auch tatsächlich durchführen, er würde nicht fehlschlagen,
weil natürlich könnten sie sagen,
niemand ruft die neue Methode auf,
die neue Methode spielt
gar keine Rolle
Zum Zeitpunkt wird es schon etwas auffallen,
zum Beispiel der Name würde hier,
wenn der Name einen Konflikt hat, wenn die Signatur nicht passt,
würde der Compiler vielleicht schon mal meckern.
Der dritte Punkt wäre,
dass wir jetzt hier eine tatsächliche Veränderung am laufigen Code vornehmen,
dass wir also hier drin diesen Code in dem ausgelagerten Bereich
löschen und durch einen Aufruf ersetzen
Das würde also so aussehen,
dass wir hier stattdessen nur einen Methodenaufruf haben und diesen Methodenaufruf,
der würde die neue Methode aufrufen und dann den Fan wir
einen Rückgabewert haben, den Rückgabewert durchführen.
Jetzt könnten wir wieder unseren Test durchführen. Wir könnten jetzt,
wenn wir jetzt den Test durchführen, wird tatsächlich der
neue Code aufgerufen und dann hätten wir schon sicher sein,
ja, das funktioniert.
Wir haben jetzt hier vier Schritte gemacht, also eigentlich sind es nur drei.
Und ganz wichtig, nach jedem dieser Schritte konnten wir
den Test durchführen und jeder dieser Schritte ist ganz klein.
Das möchte ich gern Das war jetzt das Beispiel für dieses Auslagern der Methode.
Und ich möchte gern diese Risikoferinnen und diese Aspekte zur Risikoferinnenverminderung
hier bei Ihnen mit Ihnen vervollständigen.
Und das sind die Antworten auf diese Frage, die wir hier hatten.
Ich suche Sie gerade raus. Das war hier die Frage sechs,
durch welche Maßnahmen wird beim Refactoring das Fehlerrisiko verringert?
Die erste Sache, die wir beim Fehlerrisiko verringern, schon haben,
War jetzt also das wie Funktionalität nicht verändert und testgültig bleiben.
Ja, das ist schon der erste Schritt zur Risikoverringerung.
Der zweite Schritt war, dass wir Folge von,
und ich mache mal ein kleines bisschen anders,
dass wir kleine Schritte haben
Jeder ist überschaubar, jeder ist prüfbar. Ich kann immer ermitteln,
ob wir das Reflectoring korrekt gemacht haben. Das trägt auch dazu bei,
die Folge von kleinen Schritten trägt dazu bei,
dass wir Wähler, wir kennen ihn,
prüfbar und er kann
rückgängig gemacht werden
Und diese größere Veränderung, die wir am Ende mit einem
Reflektor erreichen wollen, ist eine Folge dieser kleinen Schritte.
Jeder der kleinen Schritte kann zurückgängig gemacht werden, hat deswegen
ein geringes Risiko. Also der erste Punkt, geringes Risiko,
die Tests bleiben gültig, der zweite Punkt geringes Risiko,
weil die Schritte für sich selbst sehr klein sind,
als nächsten Punkt möchte ich mal,
möchte ich nennen,
dass diese Reflectorings
ein Erfahrungswissen darstellen
. . . . . Neudeutsch heißt sowas gerne und sowas gerne als Best Practice bezeichnet,
Best Practice ist ein Name für den Effekt, dass ich sage,
ich kenne den Idealweg, ich folge dem Idealweg,
wir reden, in Deutschland würden wir vielleicht sagen,
Erfahrungswissen, diese Refactorings sind erfolgreich und geprüfte, erfolgreiche.
Das war das, was wir eben gesagt haben.
Wir haben die im Katalog. Wir können einfach da uns
einen raussuchen. Wir können uns da bedienen und die funktionieren.
Das sind Punkte, die uns helfen, das Risiko gering
zu halten. Bevor wir mit dem Beispiel,
das Beispiel ganz verlassen, möchte ich Ihnen nicht verschweigen,
dass es hier ein paar Voraussetzungen gibt,
die wir Prüfungen müssen,
die wir prüfen müssen,
Dass wir nicht Abhängigkeiten erzeugen, die wir sozusagen mitnehmen.
Natürlich kann man sagen, okay, wir haben hier,
hier brauchen wir irgendwie eine lokale Variable und die haben wir
hier und hier und da können wir das per Parameteraufruf mitnehmen.
Das kann man natürlich machen, aber es dürfen nicht zu viele sein.
Also es kann sein, dass wir etwas nicht auslagern können,
weil wir da eine lokale Variable haben. Wir können etwas,
kann verschiedene Punkte geben, warum das Auslagern schwerfällt,
weil wir gemeinsam Ressourcen benutzen oder so etwas.
Ja, also deswegen Weiteres, so Sinn soll das heißen?
Das ist hier sowieso nicht erkennbar,
dann machen wir das mal in die nächste Zeile
Das bringt mich zurück zu den anderen Alternativen, die wir hier haben.
Ich hatte schon gesagt, dass in 99 Prozent der Fälle
dieses Extract Method genau das ist, was uns hilft.
Wir lagern eins oder zwei von den Stücken aus.
Und damit machen wir die Originalmethode entsprechend kürzer. Und wir erzeugen
neue Methoden, die einen für sich abgeschlossenes Verhalten repräsentieren.
Das ist das, was wir hier oben gesagt haben,
welcher Kohltabschnitt soll denn das sein? Ja,
ich soll natürlich einen nehmen,
der ganz klar eine Aufgabe hat,
den ich durch allen passenden Namen kennzeichnen kann,
damit ich
diese Vorteile des Refectorings
hier erreiche
Manchmal geht das nicht, weil wir eine variablen Namen,
eine Variable haben, eine lokale Variable in der Methode,
die also an ganz vielen Stellen, also wenn wir hier,
hier, hier, hier, hier, hier,
jeweils eine Methode, eine lokale Variable brauchen,
eine temporäre Variable, dann sollten wir vielleicht das machen,
indem wir stattdessen eine Abfrage machen,
die lokale Variable auslagern.
Und das wäre Replace 10 with Quill Curry.
Das wäre
In den gemeinsamen Zugriff dabei aufzulösen. Ich gebe mal hier auch noch an,
wenn sich das im Faulerbuch mal nachgucken, ist das auf der 120.
Seit 120 dargestellt. Und manchmal haben wir lange Parameterlisten,
die einfach nur zu lang sind und ganz viele Sachen mitgenommen werden.
Dann könnte man das noch auch noch verkürzen durch längere,
durch, ach so, das könnte man noch als zusätzlichen Punkt hier darstellen.
Das hatte ich jetzt natürlich nicht in der Übersicht nicht.
Das wäre Introduce Parameter Object
James. Das hat Momente hinten dran.
Und das war, das war jetzt mal 50.
Und das würde man kombiniert ausführen mit einem weiteren Reflectoring und
Reserve Whole Object
Und das ist 135, nur so zur Vollständigkeit haltbar,
ich möchte sie ermutigen, schauen Sie da mal, ach,
das ist jetzt hier nicht zu sehen, das packen wir deswegen dann alles tiefer.
Das würde ich also nochmal,
warum brauchen wir, wann brauchen wir das,
wenn die Ursache für die lange Methode darin liegt,
dass sie ganz viele Parameter übergeben kriegt,
die dann der eine Parameter wird hier bearbeitet,
der nächste wird hier bearbeitet, der nächste wird hier,
der nächste wird hier, dann ist es manchmal leichter,
das irgendwo um diese lange Parameterliste aufzulösen.
Es gibt ja verschiedene Ursachen,
warum so eine Methode im Laufe der Zeit so aufgebläht ist.
Ja, also dass wir das machen können.
Manchmal ist eine komplizierte Bedingung, ach so,
ihr müsst hier noch
einen Pfeil
Manchmal ist es eine komplizierte Bedingung, die Ursache, ja,
dann würde ich diese komplizierte Bedingung auflösen, in verschiedene Teile.
So ähnlich wie wenn das bei einer Switch-Einweisung machen würden.
Manchmal haben wir eine temporäre Variable, das ist das,
was ich eingangs schon sagte, da ist das der Punkt zum Aussagen.
Ja, und das sind die unteren Dinge hier,
diese unteren jetzt vier, sind tatsächlich schon ein bisschen die schwereren Geschosse.
Ja, die brauche ich nur, wenn das erste nicht passt,
sondern wir härtere Gründe haben, warum das Auflösen nicht funktioniert.
Damit wollte ich ihnen eigentlich nur ein kleines Beispiel geben,
warum wir sowas brauchen
Dass hier nochmal kurz im Ablauf darstellen. Das,
was wir hier gemacht haben, nämlich das Erst-Auslagern,
ja, erst kopieren und quasi da beduplizieren und dann
das zusammenfassen und durch das Sätzen quasi etwas wieder löschen.
Das stellt das folgende Bild dar, was wir hier haben,
nämlich, das ist typisch für ganz viele solche Refactorings.
Hier ist es mal dargestellt für das Zusammenfassen der Gemeinsamkeiten von einer Klasse in eine gemeinsame Oberklasse,
aber typisch ist, dass wir häufig so eine Verdopplung haben,
wo etwas mehr wird, nicht verdoppeln,
wo einfach über etwas mehr wird und dann fassen wir es wieder zusammen.
Also hier bei uns war das so, dass das mehr
erst mal so war, ich dupliziere den Code.
Ich packe das in eine neue Folie aus, wo war das hier?
Ja, das war der Schritt hier. Ich kopiere das
in eine neue Methode und lagere das hier aus.
Und das, was wir hier tun, ist, wäre dieses Expansion gewesen.
Und dann, wenn wir es zusammen kopieren wieder,
also wenn wir die zweite Stuplikat löschen, dann wird es als tatsächlich weniger.
Hier ist das gezeigt auf diesem Bild. Ja,
ich habe zwei Klassen, die ziemlich weit gehen,
Gleiche machen und ich bilde eine gemeinsame Oberklasse,
die es wäre zunächst leere, dass wir ja auch wieder so einen Schritt,
wo ich erstmal einen Test laufen kann, das passiert nichts.
Und dann erstmal fasse ich das, was hier oben in
die andere Klasse gehört, zusammen und aus dann passiert eine Reduzierung. Ja,
und ich habe dann diese expanischen Face und die Contraction Fits,
ja, und die Duplikation, das ist etwas,
was man einfach prüfen kann, wo auch mal keine Fehler passieren,
ja, und dann kriegen wir es leichter hin, das besser zu machen.
Ja, gut, soweit das Beispiel und das wäre jetzt auch die Antwort,
auf die Frage mit den Risiken,
wo ist die nochmal hier, ja, also wir haben,
durch welche Maßnahmen wird das Fehlerrisiko geringer gehalten, das waren die,
das war die Maßnahme für, mit den kleinen Schritten,
es kommt aus dem Katalog und wir testen zuerst.
Ganz abschließend noch, wie Sie das mit den Clones aus,
das ist letztlich ein weiterer,
dass wir gehen werden weiter nochmal auf dieses Bild,
was wir hier gerade hatten, das wäre genauso passieren,
nachdem wir Clones entdeckt haben, wir sagen, okay,
die beiden Dinge, die beiden Clones werden in irgendeiner Form zusammengepasst,
ob das jetzt durch ein ausgelagertes Paket ist oder viel hier im Symbol dargestellt,
durch eine gemeinsame Oberklasse.
Und dann würde das verlagern, das wäre das Entfernen,
Zusammenfassen von Clones, nur die Spezialitäten der beiden einzelnen Punkte wären hier.
Die Methoden können unterschiedlich sein, die Vorgehensweisen, die Technologien,
die wir dabei nutzen, hier ist es eben Spezialisierung,
Generalisierung oder Vergabung, wenn sie wollen.
Man kann es aber auch so machen,
dass man zum Beispiel mit einem Template arbeitet, ja,
und das Template enthält die gemeinsamen Sachen und das Ausfüllen
des Instanzieren des Templates enthält dann die speziellen Sachen.
Soviel zum Thema Effekte