11. Refactoring Advanced Programming Techniques. Wintersemester 2009/2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik

Transkript

1 11. Refactoring Advanced Programming Techniques Wintersemester 2009/2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

2 Agenda Entwicklungsumgebung Programmierprinzipien Refactoring Literatur

3 Dienste und Werkzeuge für die Phase Programmierung UML- / CASE-Tools (Together, Rational XDE, Enterprise Architect, StarUML, ) Modelltransformation, Code-Generierung (ArcStyler, IQGen, AndroMDA, ) Modelling Transformation Synchronisation, Versionen, Konfigurationen, Releases (Subversion, RCS, Continuus, Endeavour, ) QA / Software Controlling Editor, Compiler, Debugger, Profiler, (Eclipse, NetBeans, IntelliJ, ) Virtual Machine (z.b. JRE,.NET, ), Application Server (z.b. JBoss, ), Datenbank (z.b. Oracle, ) Development Runtime Configuration Management Repository Metriken, Konformität zu Spezifikation, Programmierund Design-Richtlinien (Checkstyle, Findbugs, Sotograph, ) Fehler- und Change Request Management (Bugzilla, ) Testframework, GUI- / Last-Tests, Testüberdeckung, (JUnit, TestRunner, EMMA, ) Test Navigation zwischen Artefakten Issue Tracking Build Management Nightly Build and Test (Maven 2, Ant, ) Legende: Dienst Datenfluss 3 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/10. Kontrollfluss

4 Agenda Entwicklungsumgebung Programmierprinzipien Refactoring Literatur

5 Merkmale guter Programme Ein gutes Programm hat ein sauberes Layout, verwendet sinnvolle Namen, ist ausführlich kommentiert und verwendet Konstrukte der Sprache derart, dass maximale Robustheit und Lesbarkeit des Programms erreicht werden. Die Erstellung eines solchen Programms erfordert vom Programmierer Sorgfalt, Disziplin und ein gutes Stück handwerklichen Stolz. Ian Sommerville, Software Engineering, Addison-Wesley Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

6 Programmiernahe Design Prinzipien (1/2) Separation of Concerns DRY: Don t Repeat Yourself "Once and only once" Speaking Code Principle Open Closed Principle Liskov Substitution Principle Dependency Inversion Interface Segregation Principle Jede Klasse hat genau eine Verantwortlichkeit. Gleicher oder ähnlicher Code sollte nur einmal im System vorhanden sein. Der Code soll für sich "sprechen". Eine Komponente soll offen für Erweiterungen sein. Bei Anpassungen sollen vorhandene Clients nicht ungültig werden. Eine Instanz einer Klasse muss überall an Stelle ihrer Oberklasse verwendbar sein. High-Level-Konzepte sollen nicht von Low-Level-Principle Konzepten oder Implementierungen abhängen. Schnittstellen sollen klein sein. Die Methoden einzelner Schnittstellen sollten eine hohe Kopplung besitzen. Common Reuse Principle Die Klassen einer Komponente werden als Ganzes wiederverwendet. 6 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

7 Programmiernahe Design Prinzipien (2/2) Common Closure Principle Die Klassen einer Komponente sollen gegen denselben Typ von Änderungen geschlossen sein. Wird eine Änderung durchgeführt, soll nur eine Komponente betroffen sein. Acyclic Dependency Principle Die Abhängigkeitsstruktur zwischen Komponenten soll azyklisch sein. Stable Dependency Principle Stable Abstractions Principle Tell, Don t Ask Inversion of Control Law of Demeter Eine Komponente soll nur von Komponenten abhängen, die mindestens so stabil sind wie es selbst. Je stabiler eine Komponente ist, desto abstrakter soll sie sein. Instabile Komponenten sollen konkret sein. Frag' ein Objekt nicht nach einem Objekt, sondern sag ihm, was es tun soll. Ein Objekt ist passiv; es wird von oben mit allen benötigten Informationen versorgt. Jedes Objekt soll nur mit Objekten sprechen, die es als Attribute hält, oder als Parameter übergeben bekommt. 7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

8 Law of Demeter (1/2): Spreche nur mit unmittelbaren Freunden Schlechtes Beispiel: B gibt Zugriff auf C public class A { private B b; public void needit() { b.getc().doit(); } } public class B { private C c; public C getc() { return c; } } public class C { public void doit() {... } } Gutes Beispiel: B delegiert an C public class A { private B b; public void needit() { b.delegate(); } } public class B { private C c; public void delegate() { c.doit(); } } public class C { public void doit() {... } } Alle Attribute sind als private zu deklarieren. 8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

9 Law of Demeter (2/2) Auswirkungen auf das Design von Klassen Angewandt auf Klassen und Methoden bedeutet dies: public class Demeter { private MyClass myobj; private int mymethod() {.. } public void yourmethod(hisclass hisobj) { LocalClass localobj; int i = mymethod(); hisobj.invert(); Eine Methode darf nur aufrufen: Methoden der eigenen Klasse direkt übergebener Parameter } } localobj = new LocalClass(); localobj.setactive(); myobj.print(); selbst erzeugter Objekte selbst gehaltener Objekte 9 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

10 Law of Demeter (3/3) Diskussion Quelltext wird anpassungsfähiger und robuster. Aber: die lose Kopplung gibt es nicht umsonst. Erstellung von kapselnden Methoden zur Delegation an die eigentlichen Empfänger erforderlich. Mehr Code ( Laufzeit, Speicherbedarf). Daher in der Praxis den Einsatz abwägen. Evtl. bei kritischen Modulen engere Kopplung zulassen. 10 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

11 Veränderbare vs. unveränderbare Objekte (1/2) (mutable vs. immutable objects) Unveränderbare Objekte sind sicherer als veränderbare: public class MyClass { private String mystring; // immutable private Map mymap; // mutable public MyClass(String mystring, Map mymap) { this.mystring = mystring; // keine Seiteneffekte this.mymap = mymap.clone(); // Seiteneffekte vermeiden } public String getmystring() { // keine Seiteneffekte return mystring; } } public Map getmymap() { return mymap.clone(); } // Seiteneffekte vermeiden 11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

12 Veränderbare vs. unveränderbare Objekte (2/2) Unveränderbarkeit spielt immer dann eine Rolle, wenn Objekte gemeinsam verwendet werden (Object-Sharing). Unveränderbarkeit ist eine bewusste Entscheidung, die dokumentiert werden sollte. Unveränderliche Typen helfen den Performance-Overhead für das Kopieren von Objekten zu eliminieren Wir unterscheiden zwischen Read-Only-Sichten und echten unveränderbaren Objekten. Duale Klassen bieten die Möglichkeit, sowohl veränderliche als auch unveränderliche Ausprägungen einer Abstraktion zu verwenden. Bei einer als final deklarierten Objektvariablen ändert sich die Referenz nicht. Der Wert kann sich aber sehr wohl ändern. 12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

13 Prinzip der minimalen Annahme Verwende Schnittstellen, wo sie zur Verfügung stehen: List statt ArrayList Map statt HashMap Verwende die allgemeinste Schnittstelle, die den erforderlichen Dienst bereitstellt: Collection statt List Iterator statt ListIterator 13 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

14 Design von Methodensignaturen Wähle sorgfältig einen aussagekräftigen Namen aus. Stelle keine unnötigen Convenience-Methoden bereit. Vermeide lange Parameterlisten. Besonders unschön sind lange gleichartige Parameterlisten. Beim Parametertyp die Schnittstelle einer Implementierung vorziehen. Wäge den Einsatz von funktionaler Programmierung vernünftig ab. 14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

15 Defensives Programmieren Es gibt keine fehlerfreie Software: Irren ist menschlich Wir können nicht alle Eventualitäten absehen Wir müssen sinnvoll mit Fehlern umgehen: Erwarte das Unerwartete! Sei informativ! Handle angemessen! Minimiere den Schaden im Fehlerfall! Folgende Techniken helfen bei der Auffindung und Beseitigung: Design Fehlerbehandlung ( separate Vorlesung) Assertions zum Prüfen von Vor- und Nachbedingungen Debugging, Tracing, Logging ( separate Vorlesung) Frühzeitiges und ausgiebiges Testen ( separate Vorlesung) 15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

16 Programmierrichtlinien Sind verbindliche Vorgaben für alle Entwickler im Team, z.b. zu: Dokumentation Namenskonventionen Regeln für gutes Programmieren Ziele: Zusammenarbeit in einem Projekt erleichtern Integration und Test erleichtern Langjährige Wartung ermöglichen Zuverlässigkeit und Robustheit erhöhen Werden gerne ignoriert: "Schönes Programmieren ruiniert die Performanz" der Unterschied wird von heutigen Compilern weg-optimiert! "Kommentare in halbfertigem Code sind sinnlos" grundlegende Entscheidungen sollen im Modell getroffen werden "Die Anpassungen mache ich, wenn ich fertig bin" das passiert dann nie Die Richtlinien müssen als etwas Positives empfunden werden! Erstellung durch Programmier-Profis unter Beteiligung aller Projektparteien 16 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

17 Agenda Entwicklungsumgebung Programmierprinzipien Refactoring Literatur

18 Jeder Dummkopf kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code, den Menschen verstehen. Martin Fowler: Refactoring 18 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

19 Bad Code Gewinner des "20C7: 20th Chaos Communication Congress Compact C Coding Contest" Was tut dieses Programm? Auflösung siehe 19 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

20 Historie und Definitionen Erstmalige Benutzung des Begriffs in Arbeit von Ralph Johnson und William Opdyke 1990: "Refactoring: An aid in designing application frameworks and evolving object-oriented systems" in: Proceedings of Symposion on Object-Oriented Programming Emphasizing Practical Applications, September 1990 Definitionen Kent Beck in "Extreme Programming Explained" "A change to the system that leaves its behaviour unchanged, but enhances some nonfunctional quality - simplicity, flexibility, understandibility, performance" Martin Fowler "Describes how to alter the design of existing software in a controlled and rapid manner". "A technique to restructure code in a disciplined way" 20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

21 Katalog von Refactoring-Maßnahmen (siehe Refactoring-Muster (ähnlich Entwurfsmuster): Name Ziel Symptom(e) Reihe von Arbeitsanweisungen, die für das Refactoring umgesetzt werden müssen 21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

22 Klassifikation der Maßnahmen Composing Methods Composing Methods Moving Features between Objects Organizing Data Simplifying Conditional Expressions Ein- und Auslagern von Methodenteilen Redesign des Objektmodells Umgang mit Datenstrukturen und Datenkapselung Vereinfachung von Bedingungen und Fallunterscheidungen Making Method Calls Simpler Methoden-Bezeichner und - Signaturen modifizieren Dealing with Generalization Klassenhierarchie und Methoden-/ Attribut-Zuordnung ändern 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

23 "Composing Methods" Ein- und Auslagern von Methodenteilen 1/3 Methode extrahieren (Extract Method) Symptom Aktion Ein Codefragment kann zusammengefasst werden. Setze die Fragmente in eine Methode, deren Namen den Zweck kennzeichnet. 23 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

24 "Composing Methods" Ein- und Auslagern von Methodenteilen 2/3 Ersetze eine Methode durch ein Methoden-Objekt (Replace Method with Method Object) In einer langen Methode werden lokale Variablen so (verstreut) benutzt, dass diese nicht in eine Methode extrahierbar sind. Ersetze die lange Methode durch ein eigenes Objekt. Die lokalen Variablen werden Attribute dieses neuen Objektes. Die lange Methode kann in verschiedene (private) Objekt- Methoden aufgeteilt werden. 24 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

25 "Composing Methods" Ein- und Auslagern von Methodenteilen 3/3 Methode inline setzen (Inline Method) Der Rumpf einer Methode ist so klar wie der Methodenname. Setze den Methodenrumpf für den Aufruf ein. Entferne die Methode. Temporäre Variable entfernen (Inline Temp) Eine temporäre Variable wird nur mit einem einfachen Ausdruck initialisiert. Ersetze Verweise auf die Variable durch den Ausdruck. Entferne Zuweisung an Parametervariable (Remove Assignments to Parameters) Programmcode benutzt Parametervariablen. Nutze eine temporäre Variable statt der Parametervariablen. 25 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

26 Klassifikation der Maßnahmen Composing Methods Moving Features between Objects Moving Features between Objects Organizing Data Simplifying Conditional Expressions Ein- und Auslagern von Methodenteilen Redesign des Objektmodells Umgang mit Datenstrukturen und Datenkapselung Vereinfachung von Bedingungen und Fallunterscheidungen Making Method Calls Simpler Methoden-Bezeichner und - Signaturen modifizieren Dealing with Generalization Klassenhierarchie und Methoden-/ Attribut-Zuordnung ändern 26 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

27 "Moving Features between Objects" Redesign des Objektmodells 1/5 Extrahiere Klasse (Extract Class) Eine Klasse macht Arbeit "für zwei". Erzeuge eine neue Klasse. Verschiebe die relevanten Attribute und Methoden von der alten Klasse in die neue. 27 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

28 "Moving Features between Objects" Redesign des Objektmodells 2/5 Verstecke den Delegate (Hide Delegate) Die Client-Klasse ruft Methoden eines "Delegate". Erzeuge Methode(n) zum Verstecken des Delegate-Objektes. Remove Middle Man Entferne Klasse in der Mitte (Remove Middle Man) Eine Klasse macht zu viele einfache Delegationen. Die Client-Klasse soll selbst die Methoden des Delegates aufrufen. Hide Delegate 28 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

29 "Moving Features between Objects" Redesign des Objektmodells 3/5 Führe fremde Methode ein (Introduce Foreign Method) Eine nicht änderbare Klasse benötigt eine zusätzliche Methode. Erzeuge die Methode in der Client-Klasse mit einem Verweis auf die Klasse als erstes Argument. Introduce Foreign Method 29 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

30 "Moving Features between Objects" Redesign des Objektmodells 4/5 Führe lokale Erweiterung ein (Introduce Local Extension) Eine nicht änderbare Klasse benötigt eine Reihe zusätzlicher Methoden. Erzeuge eine neue Klasse, die diese neuen Methoden enthält. Diese neue Klasse ist eine Erweiterung (Ableitung) oder ein Wrapper um die ursprüngliche Klasse. Introduce Local Extension 30 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

31 "Moving Features between Objects" Redesign des Objektmodells 5/5 Verschiebe Methode (Move Method) Eine Methode wird von einer anderen Klasse mehr verwendet als von der definierenden Klasse. Erzeuge eine Methode mit ähnlichem Rumpf in der Klasse, die die Eigenschaft am meisten nutzt. Delegiere in der alten Methode an die neue Implementierung, oder lösche sie. Verschiebe Attribut (Move Field). Analog zu "Move Method" Setze Klasse inline (Inline Class) Eine Klasse macht nicht viel. Verschiebe alle Eigenschaften in eine andere Klasse und lösche sie. 31 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

32 Klassifikation der Maßnahmen Composing Methods Moving Features between Objects Organizing Data Data Simplifying Conditional Expressions Ein- und Auslagern von Methodenteilen Redesign des Objektmodells Umgang mit Datenstrukturen und Datenkapselung Vereinfachung von Bedingungen und Fallunterscheidungen Making Method Calls Simpler Methoden-Bezeichner und - Signaturen modifizieren Dealing with Generalization Klassenhierarchie und Methoden-/ Attribut-Zuordnung ändern 32 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

33 "Organizing Data" Umgang mit Datenstrukturen und Datenkapselung 1/2 Ersetze Typ-spezifischen Code durch Unterklassen (Replace Type Code with Subclasses) Ein unveränderlicher Programmcode bestimmt das Verhalten einer Klasse. Ersetze den Typ-spezifischen Code durch eine Unterklasse. Replace Type Code with Subclasses Ersetze Typ-spezifischen Code durch Zustand/Strategie-Muster (Replace Type Code with State/Strategy) Eine "Was-bin-ich"-Variable bestimmt das Verhalten, aber Unterklassen für das spezifische Verhalten können nicht gebildet werden. Replace Type Code with State/Strategy Ersetze den Typ-spezifischen Code durch ein Zustands-Objekt. 33 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

34 "Organizing Data" Umgang mit Datenstrukturen und Datenkapselung 2/2 Ersetze Unterklassen durch Attribute (Replace Subclass with Fields) Unterklassen unterscheiden sich nur durch Methoden, die einen konstanten Wert liefern. Führe ein Attribut in der Oberklasse ein, verschiebe die Methoden dorthin und entferne alle Unterklassen. Ersetze magische Zahl durch symbolische Konstante (Replace Magic Number with Symbolic Constant) Ein Zahl-Literal steht für eine bestimmte fachliche ("magic") Bedeutung. Lege eine Konstante an, dessen Name die Fachlichkeit (gut!) erklärt. 34 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

35 Klassifikation der Maßnahmen Composing Methods Moving Features between Objects Organizing Data Simplifying Conditional Expressions Simplifying Conditional Expressions Ein- und Auslagern von Methodenteilen Redesign des Objektmodells Umgang mit Datenstrukturen und Datenkapselung Vereinfachung von Bedingungen und Fallunterscheidungen Making Method Calls Simpler Methoden-Bezeichner und - Signaturen modifizieren Dealing with Generalization Klassenhierarchie und Methoden-/ Attribut-Zuordnung ändern 35 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

36 "Simplifying Conditional Expressions" Vereinfachung von Bedingungen u. Fallunterscheidungen 1/2 Geschachtelte Bedingungen durch Wächter ersetzen (Replace Nested Conditional with Guard Clauses) Die Fallunterscheidung ist kompliziert und der normale Ausführungspfad ist nicht offensichtlich. Ersetze die geschachtelten Bedingungen durch Wächter. 36 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

37 "Simplifying Conditional Expressions" Vereinfachung von Bedingungen u. Fallunterscheidungen 2/2 Ersetze Fallunterscheidungen durch Polymorphie (Replace Conditional with Polymorphism) Eine Fallunterscheidung führt abhängig vom Typ eines Objektes unterschiedliches Verhalten aus. Lege jeden Zweig der Fallunterscheidung in eine Methode einer Unterklasse. Die Methode der Oberklasse wird abstrakt und die neuen Methoden überschreiben die abstrakte Methode. 37 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

38 Klassifikation der Maßnahmen Composing Methods Moving Features between Objects Organizing Data Ein- und Auslagern von Methodenteilen Redesign des Objektmodells Umgang mit Datenstrukturen und Datenkapselung Simplifying Conditional Expressions Making Method Calls Vereinfachung von Bedingungen und Fallunterscheidungen Making Method Calls Simpler Methoden-Bezeichner und - Simpler Signaturen modifizieren Dealing with Generalization Klassenhierarchie und Methoden-/ Attribut-Zuordnung ändern 38 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

39 "Making Method Calls Simpler" Methoden-Bezeichner und -Signaturen modifizieren 1/3 Trenne Anfrage von Veränderung (Separate Query from Modifier) Eine Methode liefert einen Wert zurück und ändert gleichzeitig den Zustand des Objekts. Teile in zwei Methoden auf: Eine für die Anfrage und eine zur Modifikation. Parametrisiere Methode (Parameterize Method) Verschiedene Methoden führen ähnliche Dinge mit verschiedenen Werten im Rumpf aus. Schreibe eine Methode, die einen Parameter für die verschiedenen Werte nutzt. 39 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

40 "Making Method Calls Simpler" Methoden-Bezeichner und -Signaturen modifizieren 2/3 Ersetze Parameter durch explizite Methoden (Replace Parameter with Explicit Methods) Eine Methode führt abhängig von bestimmten übergebenen Argumenten Programmcode aus. Lege für jedes der möglichen Argumente eine Methode an. 40 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

41 "Making Method Calls Simpler" Methoden-Bezeichner und -Signaturen modifizieren 3/3 Parameter-Objekt einführen (Introduce Parameter Object) Eine Gruppe einzelner Parametern wird typischerweise zusammen übergeben und benutzt. Ersetze die einzelnen Parameter durch ein Objekt, dessen Attribute die Parameter sind. Explizite Typanpassung kapseln (Encapsulate Downcast) Eine Methode liefert ein Objekt, welches vom Client mit einer expliziten Typanpassung angepasst werden muss. Die explizite Typanpassung wird bereits in die Methode gesetzt. 41 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

42 Klassifikation der Maßnahmen Composing Methods Moving Features between Objects Organizing Data Simplifying Conditional Expressions Ein- und Auslagern von Methodenteilen Redesign des Objektmodells Umgang mit Datenstrukturen und Datenkapselung Vereinfachung von Bedingungen und Fallunterscheidungen Making Method Calls Simpler Methoden-Bezeichner und - Signaturen modifizieren Dealing with with Generalization Klassenhierarchie und Methoden-/ Attribut-Zuordnung ändern 42 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

43 "Dealing with Generalization" Klassenhierarchie, Methoden-/Attribut-Zuordnung ändern 1/4 Ersetze Vererbung durch Delegation (Replace Inheritance with Delegation) Eine Unterklasse nutzt nur Teile der Schnittstelle der Oberklasse oder will keine Eigenschaften erben. Erzeuge ein Attribut für die Oberklasse und passe die Methoden an, so dass sie auf die Methoden der Oberklasse delegieren. Entferne die Unterklasse. 43 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

44 "Dealing with Generalization" Klassenhierarchie, Methoden-/Attribut-Zuordnung ändern 2/4 Ersetze Delegation durch Vererbung (Replace Delegation with Inheritance) Methoden einer Klasse delegieren fast immer an eine andere Klasse. Der Delegate wird zur Oberklasse. 44 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

45 "Dealing with Generalization" Klassenhierarchie, Methoden-/Attribut-Zuordnung ändern 3/4 Attribut hochziehen (Pull Up Field) Zwei oder mehr Unterklassen besitzen das gleiche Attribut. Verschiebe das Attribut in die gemeinsame Oberklasse. Methode hochziehen (Pull Up Method) Analog für Methoden. Konstruktor-Körper hochziehen (Pull Up Constructor Body) Analog für Konstruktoren. Attribut nach unten verlegen (Push Down Field) Ein Attribut wird nur von einer/einigen Unterklassen verwendet. Verschiebe das Attribut in die Unterklassen. Methode nach unten verlegen (Push Down Method). Analog für Methoden. 45 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

46 "Dealing with Generalization" Klassenhierarchie, Methoden-/Attribut-Zuordnung ändern 4/4 Hierarchien abbauen (Collapse Hierarchy) Eine Unterklasse und Oberklasse unterscheiden sich kaum. Vereinige sie in eine gemeinsame Klasse. Extrahiere Unterklasse (Extract Subclass) Eine Klasse hat Eigenschaften, die nur in einigen Instanzen verwendet wird. Erzeuge für die Untermenge an Eigenschaften (je) eine Unterklasse. Extrahiere Oberklasse (Extract Superclass) Es gibt zwei oder mehr Klassen mit gemeinsamen Eigenschaften. Erzeuge eine neue Oberklasse mit den gemeinsamen Eigenschaften. Extrahiere Schnittstelle (Extract Interface) Unterschiedliche Clients nutzen die gleiche Untermenge einer Schnittstelle der Klasse. Zwei Klassen haben zum Teil gleiche Schnittstellen. Erzeuge aus der Teilmenge eine eigene Schnittstelle. 46 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

47 Refactoring Unterstützung durch die IDE Beispiel: NetBeans IDE Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

48 Agenda Entwicklungsumgebung Programmierprinzipien Refactoring Literatur

49 Literatur (1/2) Martin Fowler: "Refactoring: Improving the Design of Existing Code" William C. Wake: "Refactoring Workbook" Erich Gamma et al: "Design Patterns. Elements of Reusable Object-Oriented Software." William J. Brown et al: "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis" Stefan Roock: "Refactoring in Large Software Projects" 49 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

50 Literatur (2/2) Java 2 Platform, Standard Edition API Specification Effective Java. Programming Language Guide. Joshua Bloch, Addison Wesley Professional, 2001, ISBN Vermeulen, et al; Elements of Java Style; SIGS, 2000 Ambler; Writing Robust Java Code; Hunt, Thomas: The Pragmatic Programmer 50 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/

51 Links Refactoring.com c2.com Artikel William F. Opdyke: Original-Dissertation von 1993 Roedy Green: Wie wird unwartbarer Quelltext geschrieben? ftp://st.cs.uiuc.edu/pub/papers/refactoring/opdyke-thesis.ps.z Fowlers Refactoring-Katalog englisch (schlechte) deutsche Übersetzung Refactoring & Patterns Refactoring Tools SWW: Refactoring-Workshop von Gerd Neugebauer Patterns Anti-Patterns 51 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Advanced Programming Techniques, WS 09/