Artikel-Schlagworte: „Eclipse“

Das Projekt befindet sich innerhalb des Workspaces (beispielsweise hier das Projekt AufgabeAP3):

Mit einem rechten Mausklick auf das Projekt öffnen Sie das Kontextmenü und wählen „Export“:

Export

In dem sich nun öffnenden Fenster wählen Sie „Archive-File“:

Export Eclipse Archive File

In dem sich nun öffnenden Fenster ist das Projekt schon vorselektiert. Bitte stellen Sie sicher, dass hier das komplette Projekt selektiert ist:

Export to ZIP Final Screen

Wählen Sie nun unter Optionen „Save in zip format“ und „Create directory structure for files“ sowie „Compress the contents of the file”. Dies sollte normalerweise schon voreingestellt sein.

Vergessen Sie nicht unter „To archive file“ die ZIP-Datei anzugeben, in welche das Projekt gespeichert werden soll.

Nach dem Klick auf „Finish“ befindet sich das gepackte Projekt im entsprechenden Verzeichnis.

Durch Rechts-Klick auf den leeren Workspace öffnet sich wieder das Kontekt-Menü. Wählen Sie „Import“ -> „Import…

Import Import Eclipse

Im folgenden Fenster wählen Sie „General“ -> „Existing Projects into Workspace

Existing Projects into Workspace

Wählen Sie in dem folgenden Fenster „Select Archive File“ und wählen Sie über den Browse-Button rechts daneben das entsprechende ZIP-File aus. Unter „Projects“ werden Ihnen die enthaltenen Projekte in diesem ZIP-File angezeigt:

Select Archive

Mit einem Klick auf „Finish“ werden die Projekte importiert.

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.

/**
 * AdressAusgabe.java
 * Klasse zur Ausgabe eines Adressbucheintrages
 * @author Christoph Tornau
 *
 */
public class AdressAusgabe {
 
	public String name;
	public String vorname;
	public String strasse;
	public String plz;
	public String ort;
 
	public AdressAusgabe(String name, String vorname, String strasse, String plz, String ort  ) {
		this.name = name;
		this.vorname = vorname;
		this.strasse = strasse;
		this.ort = ort;
		this.plz = plz;
	}
 
	public String toString()
	{
		String output = "";
 
		output += ("***");
		output += (name);
		for (int i= name.length() + 3; i<30; i++)
			output += ("*");
		output += ("\n");
 
		output += ("***");
		output += (vorname);
		for (int i= vorname.length() + 3; i<30; i++)
			output +=("*");
		output += ("\n");
 
		output += ("***");
		output += (strasse);
		for (int i= strasse.length() + 3; i<30; i++)
			output += ("*");
		output += ("\n");
 
		output += ("***");
		output += (plz);
		for (int i= plz.length() + 3; i<30; i++)
			output +=("*");
		output += ("\n");
 
		output += ("***");
		output += (ort);
		for (int i= ort.length() + 3; i<30; i++)
			output +=("*");
		output += ("\n");
 
		output += ("***");
		output += ("");
		for (int i= "".length() + 3; i<30; i++)
			output +=("*");
		output += ("\n");
 
		return output;
	}
 
	/**
	 * Main method
	 * @param args
	 */
	public static void main(String[] args) {
 
		AdressAusgabe myAdresse1 = new AdressAusgabe ("Maier","Hans",
				"Musterstrasse 1","11111","Musterstadt");
		System.out.println(myAdresse1);
 
		AdressAusgabe myAdresse2 = new AdressAusgabe ("Gustav","Morgan",
				"Pappelallee 15","53122","Bonn");
		System.out.println(myAdresse2);
 
	}
}

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:

private String printPart(String output) {
		output += ("***");
		output += (name);
		for (int i= name.length() + 3; i<30; i++)
			output += ("*");
		output += ("\n");
		return output;
	}

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:

	private String printPart(String stringToPrint) {
 
		String output = "";
		output += ("***");
		output += (stringToPrint);
		for (int i= stringToPrint.length() + 3; i<30; i++)
			output += ("*");
		output += ("\n");
		return output;
	}

Ebenso ändern wir den Methodenaufruf per Hand um in

output = printPart(name);

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

public String toString()
	{
		String output = "";
 
		output += printPart(name);
		output += printPart(vorname);
		output += printPart(strasse);
		output += printPart(plz);
		output += printPart(ort);
		output += printPart("");
 
		return output;
	}

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

	public String toString()
	{
		String output = "";
 
		output += Adresse.printPart(name);
		output += Adresse.printPart(vorname);
		output += Adresse.printPart(strasse);
		output += Adresse.printPart(plz);
		output += Adresse.printPart(ort);
		output += Adresse.printPart("");
 
		return output;
	}

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:

public class Adresse {
 
	public String name;
	public String vorname;
	public String strasse;
	public String plz;
	public String ort;
 
	public Adresse(String name, String vorname, String strasse, String plz, String ort  ) {
		this.name = name;
		this.vorname = vorname;
		this.strasse = strasse;
		this.ort = ort;
		this.plz = plz;
	}
 
	public String toString()
	{
		String output = "";
 
		output += Adresse.printPart(name);
		output += Adresse.printPart(vorname);
		output += Adresse.printPart(strasse);
		output += Adresse.printPart(plz);
		output += Adresse.printPart(ort);
		output += Adresse.printPart("");
 
		return output;
	}
 
	public static String printPart(String stringToPrint) {
 
		String output = "";
		output += ("***");
		output += (stringToPrint);
		for (int i= stringToPrint.length() + 3; i<30; i++)
			output += ("*");
		output += ("\n");
		return output;
	}
 
}

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.