Jeder technische Autor hat das Problem zu entscheiden, wann er verửffentlicht. Je frỹher Sie verửffentlichen, um so eher kửnnen Leser Vorteile aus den Ideen zie- hen. Aber Menschen lernen immer weiter dazu. Verửffentlichen Sie halbgare Ideen zu frỹh, so kửnnen die Ideen unvollstọndig sein und zu Problemen fỹr die führen, die versuchen sie anzuwenden.
Die Basistechnik des Refaktorisierens, kleine Schritte zu machen und oft zu testen, hat sich ỹber viele Jahre bewọhrt, besonders in der Smalltalk-Gemeinde. Daher bin ich zuversichtlich, dass die Grundidee des Refaktorisierens sehr stabil ist.
Die Refaktorisierungen in diesem Buch sind meine Notizen über Refaktorisierun- gen, die ich verwende. Ich habe sie alle benutzt. Es ist aber ein Unterschied, eine Refaktorisierung zu benutzen und sie in mechanische Schritte zu zerlegen, die ich hier vorstelle. Insbesondere sehen Sie manchmal Probleme, die nur unter ganz speziellen Umstọnden auftreten. Ich kann nicht behaupten, dass ich viele Leute gesehen họtte, die nach diesen Schritten vorgingen und auf viele solcher Pro- bleme stieòen. Wenn Sie die Refaktorisierungen verwenden, achten Sie genau darauf, was Sie tun. Denken Sie daran, dass es wie das Kochen nach einem Rezept ist; Sie mỹssen die Refaktorisierungen den Umstọnden anpassen. Stoòen Sie auf ein interessantes Problem, schreiben Sie mir eine E-Mail, und ich werde versu- chen, diese Umstọnde an andere weiterzugeben.
Ein anderer Aspekt, an den Sie denken müssen, ist, dass diese Refaktorisierungen für Software geschrieben wurden, die nur einen Prozess verwendet. Mit der Zeit, hoffe ich, wird es auch Refaktorisierungen fỹr die Verwendung in der nebenlọufi- gen und verteilten Programmierung geben. Dies werden andere Refaktorisierun- gen sein. In Software innerhalb eines Prozesses brauchen Sie sich z.B. keine Ge- danken darüber machen, wie oft Sie eine Methode aufrufen; Methodenaufrufe sind billig. Bei verteilter Software müssen Rundreisen aber minimiert werden. Es gibt andere Refaktorisierungen für diese Arten der Programmierung, aber das sind Themen für ein anderes Buch.
Viele der Refaktorisierungen wie Typenschlüssel durch Zustand/Strategie ersetzen (231) und Template-Methode bilden (355) haben mit der Einführung von Entwurfs- mustern in ein System zu tun, wie es schon im grundlegenden Buch der Vierer- bande heiòt: ằEntwurfsmuster … bieten Ziele fỹr Refaktorisierungen.ô Es gibt eine natürliche Beziehung zwischen Entwurfsmustern und Refaktorisierungen. Ent- wurfsmuster sind das, wo Sie hinwollen; Refaktorisierungen sind Wege, um dort hinzukommen. Ich habe nicht für alle bekannten Entwurfsmuster Refaktorisie-
rungen in diesem Buch, nicht einmal für alle aus dem Buch der Viererbande [Gang of Four]. Auch in dieser Hinsicht ist dieser Katalog unvollstọndig. Ich hoffe, dass die Lücken eines Tages geschlossen werden.
Wenn Sie diese Refaktorisierungen verwenden, denken Sie daran, dass dies nur der Anfang ist. Sie werden zweifellos Lỹcken darin entdecken. Ich verửffentliche sie jetzt, nicht weil sie perfekt sind, sondern weil ich meine, dass sie nützlich sind.
Ich glaube, sie geben Ihnen einen Ausgangspunkt, der Ihre Fọhigkeit, effizient zu refaktorisieren, verbessert. Das ist es, was sie für mich leisten.
Wenn Sie mehr Refaktorisierungen verwenden, werden Sie, so hoffe ich, begin- nen, Ihre eigenen zu entwickeln. Ich hoffe, die Beispiele in diesem Buch motivie- ren Sie und geben Ihnen einen Ausgangspunkt, wie Sie dies machen kửnnen. Ich bin mir bewusst, dass es sehr viel mehr Refaktorisierungen gibt, als die, die ich be- schrieben habe. Wenn Sie auf weitere kommen, schicken Sie mir bitte eine E-Mail.
6 Methoden zusammenstellen
Ein groòer Teil meiner Refaktorisierungen stellt Methoden zusammen, um Code ordentlich zu strukturieren. Fast rühren die Probleme daher, dass Methoden zu lang sind. Lange Methoden machen deshalb Ärger, weil sie oft viele Informatio- nen enthalten, die unter der komplexen Logik begraben liegen, die meistens mit hineingezogen wird. Die Schlüsselrefaktorisierung hierfür ist Methode extrahieren (106), die ein Stück Code nimmt und daraus eine eigene Methode macht. Methode integrieren (114) ist im Wesentlichen das Gegenteil davon. Sie nehmen einen Me- thodenaufruf und ersetzen ihn durch den Code der Methode. Ich verwende Me- thode integrieren (114), wenn ich oft extrahiert habe und einige der entstandenen Methoden zu wenig tun oder wenn ich die Zerlegung in Methoden reorganisieren muss.
Das grửòte Problem bei Methode extrahieren (106) ist der Umgang mit lokalen Vari- ablen, und temporọre Variablen die sind họufigste Ursache dieses Problems. Ar- beite ich an einer Methode, so verwende ich gern Temporọre Variable durch Abfrage ersetzen (117), um alle temporọren Variablen loszuwerden, die ich entfernen kann. Wird eine temporọre Variable fỹr viele Dinge verwendet, so setze ich zu- nọchst Temporọre Variable zerlegen (125) ein, um die temporọren Variablen leich- ter ersetzbar zu machen.
Manchmal sind die temporọren Variablen aber einfach zu verheddert, um sie zu ersetzen. Dann brauche ich Methode durch Methodenobjekt ersetzen (132). Dies er- mửglicht es mir, auch die verworrenste Methode zu zerlegen, allerdings auf Kos- ten einer neuen Klasse, um die Arbeit zu machen.
Parameter sind ein kleineres Problem als temporọre Variablen, solange man ihnen keine Werte zuweist. Wenn doch, brauchen Sie Zuweisungen auf Parameter entfer- nen (128).
Nachdem die Methode zerlegt ist, kann ich viel besser verstehen, wie sie arbeitet.
Vielleicht stelle ich auch fest, dass der Algorithmus verbessert werden kann, um ihn klarer zu gestalten. Dann verwende ich Algorithmus ersetzen (136), um einen klareren Algorithmus einzuführen.