Refactoring Andreas Martens Der Weg zum lesbaren Code.

Präsentation zum Thema: "Refactoring Andreas Martens Der Weg zum lesbaren Code."—  Präsentation transkript:

1 Refactoring Andreas Martens Der Weg zum lesbaren Code

2 2/35 Übersicht I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings

3 3/35 ● Code wird erweitert ● Neue Klassen und Funktionalitäten werden implementiert ● Alte Funktionalitäten werden nicht mehr benutzt ● Mit der Zeit zerfällt das Codedesign ● Der Code wird immer schwerer zu verstehen Was ist Refactoring Software Leben

4 4/35 Was ist Refactoring Aktivitäten in der Software- Wartung 50% verstehen des Codes 25% Änderungen testen 10% Änderungen planen 10% Änderungen durchführen 5% Änderungen dokumentieren

5 5/35 Was ist Refactoring Refactorin g Refactoring (Definition): „A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior“ (Martin Fowler)

6 6/35 Was ist Refactoring Ziele: – Verbesserung und Pflege des Designs – Verständlichkeit – Finden von Fehlern – Hilfe, um schneller zu Programmieren

7 7/35 Was ist Refactoring Die Hut Metapher (nach Kent Beck) Refactoring und Programmieren sind verscheide Dinge - Funktionalität hinzufügen (Programmierer Hut) - Refactoring (Refactoring Hut) Man kann nur einen Hut tragen!

8 8/35 Was ist Refactoring Bedeutung von Test Warum Testen? ● Die Programmfunktionen müssen erhalten bleiben Wie Testen? ● Die Tests müssen vollständig automatisch ablaufen ● Der Test muss seine Ergebnisse selbst überprüfen ● nach jedem Refactoring muss der Test ausgeführt werden ● Klassentests / Modultests

9 9/35 Was ist Refactoring Refaktoriere n Voraussetzungen: ● Tests existieren und der Code funktioniert ● Keiner arbeitet gerade an dem Code ● Der Auftraggeber/Kunde/Chef ist einverstanden das der Code den Zeit und Geldaufwand wert ist

10 10/35 Was ist Refactoring Wann Refaktorieren? ● Immer ● „Rule of three“ ● Wenn der Code „Stinkt“ ● Wenn man etwas neues über den Code lernt ● Wen man einen Bug beseitigt ● Nachdem man eine neue Funktionalität hinzugefügt hat

11 11/35 Was ist Refactoring Wann nicht Refaktorieren? ● Wenn ein Test nicht erfolgreich war (Der Code fehlerhaft ist) ● Wenn man kurze Deadlines hat ● Vorsicht beim Ändern einer veröffentlichten Schnittstelle

12 12/35 I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings

13 13/35 Moving Features Between Objects ● Eine grundlegende Entscheidung ist es wo man Funktionalität implementiert ● Es wird nicht immer die richtige Entscheidung getroffen ● Dank Refactoring, können Fehler korrigiert werden

14 14/35 ● Move Method ● Move Field ● Extract Class ● Inline Class ● Hide Delegate ●...... Moving Features Between Objects Einige Beispiele

15 15/35 Moving Features Between Objects Wann anwenden? ● Wenn eine Methode von einer anderen Klasse öfter verwendet wird als von ihrer eigenen. ● Wenn Methode besser in die andere Klasse passt Beispiel: Move Method _type _tageÜberzogen Account überziehungsKost en kostenBerechnen AccountTyp isPremium 1 _type _tageÜberzogen Account kostenBerechnen AccountTyp überziehungsKost en isPremium 1

16 16/35 Moving Features Between Objects Move Method: Beispiel class Account{ private AccountTyp _type; private int _tageÜberzogen; double überziehungsKosten() { if(_type.isPremium()) { double ergebniss = 10; if(_tageÜberzogen > 7) ergebniss+=(_tageÜberzogen)*0.85; return ergebniss; } else return _tageÜberzogen *1.75; } double kostenBerechnen() { double ergebniss = 4.5; if(_tageÜberzogen > 0) ergebniss += überziehungsKosten(); return ergebniss; }

17 17/35 Moving Features Between Objects ● Es sollen weitere Accouttypen angelegt werden ● jeder Accounttyp hat andere Regeln die Überziehungskosten zu berechnen ● deswegen soll überziehungsKosten() verschoben werden Move Method: Beispiel

18 18/35 Moving Features Between Objects Move Method: Beispiel public class AccountTyp { double überziehungsKosten(int tageÜberzogen) { if(isPremium()) { double ergebniss = 10; if(tageÜberzogen > 7) ergebniss+=(tageÜberzogen)*0.85; return ergebniss; } else return tageÜberzogen *1.75; }.... class Account{..... double überziehungsKosten() { return _type.überziehungsKosten(tageÜberzogen); }.....

19 19/35 Moving Features Between Objects ● Kompilieren und Testen ● Man kann es so lassen, oder überziehungsKosten() aus der Accountklasse entfernen – Dafür muss man alle Aufrufe der Methode finden und ersetzen Move Method: Beispiel class Account{ double kostenBerechnen() { double ergebniss = 4.5; if(_tageÜberzogen > 0) ergebniss += _type.überziehungsKosten(_tageÜberzogen); return ergebniss; }

20 20/35 Moving Features Between Objects ● Nun kann die Methode überziehungsKosten() entfernt werden ● Wieder Kompilieren und Testen ● Sollte die Methode nicht private sein, müssen die anderen Aufrufe auch korrigiert werden Move Method: Beispiel

21 21/35 Moving Features Between Objects ● Wenn andere Methoden genutzt werden, muss eine Referenz übergeben werden Move Method: Beispiel public class AccountTyp { double überziehungsKosten(Account account) { if(isPremium()) { double ergebniss = 10; if(account.tageÜberzogen() > 7) ergebniss+=account.tageÜberzogen()*0.85; return ergebniss; } else return account.tageÜberzogen() *1.75; }

22 22/35 Moving Features Between Objects Wenn Methode zu Komplex ist ● Methode zerlegen ● Einige Teile in der Ursprungsklasse lassen Move Method: Probleme

23 23/35 I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings

24 24/35 Dealing with Generalization ● Die Unterklassen haben semantisch gleiche Methoden – > Methode in eine Oberklasse hochziehen – > Sonderfall Konstruktor (möglichst den Konstruktor der Oberklasse verwenden) ● Teile der Oberklasse nicht nicht für alle Unterklassen relevant – > Methode / Feld in die Unterklassen drücken ● Klassen haben ähnliche Rollen – > Bei großen Ähnlichkeiten Extract Superclass verwenden – > sonst Extract Interface Grundlagen

25 25/35 ● Pull Up/Down Field ● Pull Up/Down Method ● Replace Consructor with Factory Method ● Extract Superclass ● Extract Subclass ●...... Dealing with Generalization Einige Beispiele

26 26/35 Dealing with Generalization ● Diagnose: – Unterklassen enthalten die gleichen Felder ● Lösung: – Pull Up Field ● Vorgehen: – Prüfen Nutzung der Felder – Wenn Namen ähnlich Umbenennen – Erzeuge Feld in Oberklasse – Lösche Unterklassen Feld – Überlegen ob man Self Encapsulate Field anwendet Pull Up Field

27 27/35 Dealing with Generalization Extract Superclass ● Diagnose: – Bei der Entwicklung der Software entwickeln sich ähnliche Klassen an verscheiden Stellen ● Redundante Codeteile ● Bei Änderungen ist die Konsistenz in Gefahr ● Lösung: – Nachträgliches einführen einer gemeinsamen Oberklasse – Gemeinsamkeiten zusammenfassen ● Vorgehen: – Neue Klasse definieren und alte davon Erben lassen – Nutze Pull Up Field/Method/Constructor Body um Teile in die Oberklasse zu verschieben – Prüfen der über gebliebenen Teile ob man dort nicht Extract Method anwenden kann – Wenn eine Klasse nur Oberklassen Features nutzt – Ersetze sie durch die Oberklasse

28 28/35 I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings

29 29/35 Big Refactorings Besonderheiten ● Brauchen viel Zeit (Tage-Monate) ● Ganze Team muss daran arbeiten ● Vier Big Refactorings – Hierarchische Vererbung – Trenne GUI von der Logik – Extrahiere Hierarchie – Verfahrens basiertes Modell zu Objekten konvertieren

30 30/35 Big Refactorings Hierarchische Vererbung Eine Vorhandene Hierarchie ist für 2 Aufgaben zuständig ➔ Spagetti Code ➔ Schwer verständlich ➔ Duplizierter Code

31 31/35 Big Refactorings Hierarchische Vererbung: Vorgehen ● Erzeuge eine 2D, 3D oder 4D Raster um die verschiedenen Aufgaben zu differenzieren ● Entscheide welche davon die wichtigste ist ● Extract Class anwenden ● Erzeugen von Unterklassen für jede vorhandene Unterklasse ● Nutze Move Method um den Code in die neue Klasse zu transportieren ● Wenn die alten Unterklassen leer sind, entfernen ● Mit Pull Up Method/Field die neue Klassen verfeinern

32 32/35 Big Refactorings Trenne GUI von der Logik ● Es sind GUI Klassen vorhanden die Programmlogik enthalten

33 33/35 Big Refactorings Trenne GUI von der Logik: Vorgehen ● Erzeugen einer Klasse für jedes Fenster ● Wenn Tabellen vorkommen, erzeuge eine Klasse für die Zeilen ● Benutze Move Method und Dublicate Observerd Data um die Klassen zu teilen ● Nutze Extract Method um Logik von der Präsentation zu lösen

34 34/35 Übersicht I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings V.Ende

35 35/35 Fragen ? Andreas Martens