{"id":601,"date":"2015-08-19T16:14:44","date_gmt":"2015-08-19T14:14:44","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=601"},"modified":"2015-09-20T10:26:55","modified_gmt":"2015-09-20T08:26:55","slug":"anleitung-zum-gluecklichsein","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/anleitung-zum-gluecklichsein\/","title":{"rendered":"Anleitung zum Gl\u00fccklichsein"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

In unserem Artikel zum Thema Refactoring<\/a> haben erl\u00e4utert, was Refactoring ist und warum es jeder Entwickler machen sollte. Sch\u00f6n, aber wie mache ich das denn jetzt genau? Wie gehe ich dabei vor? Habt ihr auch schon einmal den Versuch gestartet, euren Code refaktorisieren zu wollen und dann vor dem Code gesessen mit der Frage: „Wie fange ich jetzt am Besten an?“? Gibt es da keine Anleitung zu? Nicht die eine gro\u00dfe, aber viele kleine und diese wollen wir in diesem und weiteren Artikeln vorstellen.<\/p>\n

 <\/p>\n

Eine IDEe zur Selbsthilfe<\/h1>\n

Die integrierte Entwicklungsumgebung (IDE) Eclipse bietet f\u00fcr einige wenige Refaktorisierungen Unterst\u00fctzung und f\u00fchrt diese nach Auswahl \u00fcber das Kontextmen\u00fc automatisch durch. Sehr praktisch. Doch ist mir wohler dabei, wenn ich genau wei\u00df, was die IDE da so macht bzw. machen sollte. Das erm\u00f6glicht mir, das Ergebnis zu pr\u00fcfen bzw. im Vorfeld abzuw\u00e4gen, ob genau mein gew\u00fcnschtes Ergebnis am Ende herauskommt. Beginnen wir mit der wohl einfachsten und gleichzeitig wirkungsvollsten Refaktorisierung: Umbenennen (Rename). Welcher Entwickler freut sich nicht \u00fcber Klassen, Methoden und Variablen mit sprechenden Namen<\/a>? Wenn ich direkt am Namen erkennen kann, was hier passiert ohne lange den Code studieren zu m\u00fcssen, ist das auch aus wirtschaftlichen Gr\u00fcnden gut – n\u00e4mlich deutlich schneller. Im folgenden Beispiel eine Methode mit nicht allzu sprechendem Namen.<\/p>\n

public Player things() {\r\n\tPlayer player = new Player();\r\n\t\r\n\tplayer.name = this.name;\r\n\tplayer.symbol = this.symbol;\r\n\tplayer.strategy = this.strategy;\r\n\t\r\n\treturn player;\r\n}<\/pre>\n
Beim Blick in die Methode wird vermutlich schnell klar werden, was der bessere Name der Methode ist.<\/p>\n
public Player clone() {\r\n\tPlayer player = new Player();\r\n\t\r\n\tplayer.name = this.name;\r\n\tplayer.symbol = this.symbol;\r\n\tplayer.strategy = this.strategy;\r\n\t\r\n\treturn player;\r\n}<\/pre>\n
Der Code ist noch \u00fcbersichtlich genug, um schnell zu erfassen, was eigentlich geschieht. Bei l\u00e4ngeren Methoden oder gleichzeitig nicht sprechenden Variablennamen wird es schon schwieriger. Daher kann in Eclipse \u00fcber das Kontextmen\u00fc -> Refactor -> Rename die Methode umbenannt werden. Der Vorteil gegen\u00fcber dem einfachen \u00dcberschreiben des Methodennamens ist, dass Eclipse alle Vorkommen der Methode – also auch alle Aufrufe – ebenfalls direkt anpasst und durch den neuen Namen ersetzt. Das Tastenk\u00fcrzel daf\u00fcr lautet in der Standardeinstellung Alt+Shift+R<\/em>. Wichtig<\/strong>: Eclipse ber\u00fccksichtigt bei der Umbenennen \u00fcblicherweise keine Vorkommen in Textdateien, wie z.B. XML-Dateien. Daher ist in diesem Fall immer noch einmal manuell zu pr\u00fcfen, ob alle Referenzen korrekt ersetzt sind.<\/p>\n
Im Folgenden stellen wir das erste Refactoring-Pattern – also Anleitung – anhand eines Beispiels vor. Dabei zeigen wir auch die Unterst\u00fctzung durch die IDE Eclipse.<\/p>\n
 <\/p>\n
Extract Interface<\/h1>\n
Die Ausgangssituation zeigt einen Auszug aus der Klasse Player<\/em> eines TicTacToe-Spiels. F\u00fcr den n\u00e4chsten Zug wird die Eingabe auf der Konsole abgefragt. Die Implementierung dazu ist bereits in eine separate Klasse HumanStrategy<\/em> ausgelagert.<\/p>\n
public class Player {\r\n\r\n\tprivate String name;\r\n\tprivate HumanStrategy strategy;\r\n\tprivate String symbol;\r\n\t\r\n\tpublic Player(String name, String symbol, HumanStrategy strategy) {\r\n\t\tthis.name = name;\r\n\t\tthis.symbol = symbol;\r\n\t\tthis.strategy = strategy;\r\n\t}\r\n\t\r\n\t[...]\t\r\n\r\n\tpublic int getNextMove(GameState state) {\r\n\t\treturn this.strategy.getNextPosition(state);\r\n\t}\r\n\t\r\n\t[...]\t\r\n}<\/pre>\n
Es besteht eine direkte Abh\u00e4ngigkeit von der Klasse Player<\/em> zur Klasse HumanStrategy<\/em>. M\u00f6chten wir nun die Methode getNextMove(…)<\/em> in der Klasse Player<\/em> testen, so interessiert uns nicht, was genau die Klasse HumanStrategy<\/em> macht – sonst w\u00fcrden wir ja diese Klasse testen. Daher w\u00e4re es super, wenn wir f\u00fcr den Test keine echte Strategie sondern einen Dummy (Fake) verwenden k\u00f6nnten. Dies kann leicht \u00fcber ein Mocking-Framework erreicht werden. Wollen wir dies „zu Fu\u00df“ machen und damit auch unseren Produktionscode entkoppeln sowie f\u00fcr weitere Strategien (z.B. KI) vorbereiten, kann das Muster Extract Interface<\/strong> angewendet werden.<\/p>\n
 <\/p>\n
Anleitung<\/h2>\n
Die kurze Anleitung dazu besteht aus wenigen Schritten:<\/p>\n
    \n
  1. Neue Schnittstelle erstellen (minimale \u00c4nderung)<\/li>\n
  2. Produktions-Implementierung erstellen<\/li>\n
  3. Fake-Implementierung erstellen<\/li>\n
  4. Einfachen Test mit \u00dcbergabe der Fake-Implementierung<\/li>\n
  5. Methode \u00e4ndern, um neuen Parameter zu verwenden<\/li>\n
  6. Methode mit Fake-Implementierung testen<\/li>\n<\/ol>\n
    1.) Als erstes legen wir ein Interface mit der gew\u00fcnschten Signatur an. Das Sch\u00f6ne daran ist, damit kann noch nichts kaputt gehen \ud83d\ude42<\/p>\n
    public interface MoveStrategy {\r\n   public int getNextPosition(GameState state);\r\n}<\/pre>\n
    2.) Unsere Klasse HumanStrategy<\/em> implementiert dann die neue Schnittstelle, wodurch sich sonst noch nichts \u00e4ndert, die entsprechende Methode ist schlie\u00dflich bereits vorhanden.<\/p>\n
    public class HumanStrategy implements MoveStrategy {\r\n\tpublic int getNextPosition(GameState state) {\r\n        [...]\r\n        }\r\n}\r\n<\/pre>\n
    3.) F\u00fcr unseren Test wird nun der Fake erstellt, welcher ebenfalls das neue Interface MoveStrategy<\/em> implementiert. (Wenn ihr gerade nicht mehr so genau wisst, was ein Fake ist, lest es nochmal nach<\/a>.)<\/p>\n
    public class FakeMoveStrategy implements MoveStrategy {\r\n\tpublic int getNextPosition(GameState state) {\r\n\t\treturn 0;\r\n\t}\r\n}<\/pre>\n
    4.) Damit k\u00f6nnen wir jetzt einen Test erstellen, der – wie so \u00fcblich bei test-driven Unit Tests<\/a> – erst einmal fehlt schl\u00e4gt.<\/p>\n
    @Test\r\npublic void testGetNextMoveReturnsValueFromStrategy() {\r\n\tPlayer player = new Player(\"Hugo\", \"X\", new FakeMoveStrategy());\r\n        assertThat(player.getNextMove(null)).isEqualTo(0);\r\n}<\/pre>\n
    5.) Dazu passen wir den Konstruktor der Klasse Player <\/em>an. Die zu testende Methode arbeitet unver\u00e4ndert mit der Klassenvariable strategy<\/em>, hinter der sich nun das zuvor erstellt Interface verbirgt.<\/p>\n
    public class Player {\r\n\r\n\tprivate String name;\r\n\tprivate MoveStrategy strategy;\r\n\tprivate String symbol;\r\n\r\n\tpublic Player(String name, String symbol, MoveStrategy strategy) {\r\n\t\tthis.name = name;\r\n\t\tthis.symbol = symbol;\r\n\t\tthis.strategy = strategy;\r\n\t}\r\n        [...]\r\n}<\/pre>\n
    6.) Nun k\u00f6nnen wir unseren Test ausf\u00fchren und erhalten die Best\u00e4tigung, dass die Methode genau wie erwartet funktioniert.<\/p>\n
     <\/p>\n
    In der IDE<\/h2>\n
    Was macht nun Eclipse, wenn ich das Refactoring durch die IDE ausf\u00fchren lasse (statt es manuell zu machen)? In der Klasse HumanStrategy<\/em> w\u00e4hle ich per Kontextmen\u00fc Refactor -> Extract Interface<\/em> aus.<\/p>\n
    \"ExtractInterfaceEclipseDialog\"<\/a><\/p>\n
    Ich kann im Dialog den Namen des neuen Interfaces angeben und neben wenigen Optionen die Methoden ausw\u00e4hlen, welche das Interface von der Klasse \u00fcbernehmen soll. In der Vorschau werden mit alle zu \u00e4ndernden Klasse angezeigt und bei Best\u00e4tigung des Dialogs werden genau dieselben \u00c4nderungen durchgef\u00fchrt, wie wir sie vorher manuell ausgef\u00fchrt haben:<\/p>\n