Im Folgenden möchte ich gerne einige der Refactoring-Funktionalitäten von Eclipse demonstrieren. Für das Refactoring wird ein JUnit-Test, so wie es Ziel der eXtreme-Programming-Methodik ist, benutzt, um zu prüfen, ob die originale Funktionalität noch vorhanden ist. Die Anleitung demonstriert die Fähigkeiten der Eclipse-Entwicklungsumgebung das Rafactoring mit JUnit zu unterstützen, zeigt jedoch im letzten Schritt auch Grenzen auf, so wieder ein händisches Vorgehen vonnöten ist.

Vielfach wurden die Sourcen der Anleitung erwünscht. Das Projekt zu Beginn befindet sich in vorRefactoring.zip, das Projekt nach allen Refactoringschritten befindet sich in nachRefactoring.zip.

An der Beispielklasse fallen uns folgende Bad-Smells sofort auf:

  • Der Code für die Ausgabe ist in mehrfacher Ausführung vorhanden.

  • Anscheindend wurde darauf verzichtet in eine extra Datenklasse zu kapseln. Alles ist in einer Klasse geschrieben. Man sollte auf jeden Fall trennen.

  • Felder können von außen gelesen und geschrieben werden. Es gibt keine Getter- und Setter-Methoden.

Der Code verfügt über einen JUnit-Test, wie folgender Screenshot zeigt:

Wir führen nun folgende Refactorings nacheinander durch. Nach den einzelenen Schritten führen wir jedesmal einen Test mit JUnit durch. Ds Refactoring kann nur fortgeführt werden, wenn der Balken grün bleibt. Ansonsten haben wir einen Fehler gemacht. Hier der grüne Balken:

1. Extract Method:

Nun entsteht eine neue Methode im Code:

Wir sehen, dass diese Methode als „private“ deklariert ist und den output-String sowohl bekommt als auch wieder ausgibt. Nach dem Extrahieren der Methode können wir die JUnit-Tests ausführen, um zu prüfen, ob die Programmfunktionalität zerstört worden ist.

2. Ändern des Methoden-Aufrufs

Wir wollen den String, welcher übergeben wird, in die Ausgabe statt „name“ einbauen. Gleichzeitig wollen wir den Originalstring nicht mehr übergeben:

Nun gibt es einige Fehlermeldungen:

Wir ignorieren diese und ändern den Code per Hand um:

Ebenso ändern wir den Methodenaufruf per Hand um in

Nun können wir per Hand die hinzugefügte Methode ändern und elimieren so den dupplizierten Code:

Nachdem wir dies durchgeführt haben, müssen wir wiederum die JUnit-Tests ausführen und erhalten als Ergebnis, dass der Code immernoch lauffähig ist.

3. Neue Klasse erzeugen und Methoden bewegen

Nun möchten wir gerne eine Datenklasse erzeugen, um die Daten von der Hauptklasse abzutrennen:

Wir bewegen zunächst die Methode printPart, nachdem wir deren Methoden Signatur etwas geändert haben:

Unser Code ändert sich automatisch mit

Leider können wir die restlichen Methoden mit Eclipse nicht automatisch verschieben, weshalb wir sie per Hand verschieben, so dass die neue Klasse wie folgt aussieht:

Hier hinkt nun unser JUnit-Test. Der Grund hierfür ist, dass sich der Klassenname der zu prüfenden Klasse geändert hat, da die Funktionalität per Hand verschoben worden ist. In diesem Fall dürfen wir jedoch unseren JUnit-Test anpassen, indem wir dort den Klassennamen ändern.

Wir setzen die Methode printPart wieder privat.

Noch immer sind die Felder „public“ Wir wenden Encapsulate Field an.

Wir führen die JUnit-Tests nochmals durch. Wir sehen, dass der Balken weiter grün ist. Das Refactoring war erfolgreich und wir haben viel schöneren Code erhalten.

5 Kommentare zu „Refactoring mit Eclipse Step4Step“

  • Procrash:

    < kommt im Quelltext vor, dass ist sicher so nicht gewollt. Wäre auch gut wenn der JUnit Test sowie der ursprüngliche Quelltext als Eclipse Projekt downloadfähig wären um’s selber auszuprobieren

  • Christoph Tornau:

    Vielen Dank für die Info. Hier ist mir ein Fehler unterlaufen. Dieser ist mittlerweile korrigiert.

  • Christoph Tornau:

    Ein Download des kompletten Codes dieser kleinen Anleitung ist nun möglich. Siehe dazu die beiden ZIP-Dateien zu Beginn des Artikels.

  • Ark:

    Moin,
    warum habe ich im Schritt 2 keine Fehlermeldung? Es wird einfach überall output durch stringToPrint ersetzt.

  • Christoph Tornau:

    Das output mit stringToPrint ersetzt wird, darf in diesem Falle nicht sein, weil die vorhandene Funktionalität des Programmes des Tutorials damit nicht mehr gegeben ist. Es sollte entsprechende Fehlermeldung erscheinen. Evtl. arbeitest Du nicht auf dem Programm auf welchem das Tutorial arbeitet? Sonst kann ich das Problem leider nicht nachvollziehen.

Kommentieren