Software Engineering. 9. Refactoring und Entwurfsmuster. Franz-Josef Elmer, Universität Basel, HS 2011

Transkript

1 Software Engineering 9. Refactoring und Entwurfsmuster Franz-Josef Elmer, Universität Basel, HS 2011

2 Software Engineering: 9. Refactoring und Entwurfsmuster 2 Refactoring Definition: Verbesserung des Codes ohne Änderung des Verhaltens. Allgemeine Erfahrung: rotten design Code Qualität Code Qualität Zahl der Features Zeit Zahl der Features Refactoring Phasen Zeit

3 Software Engineering: 9. Refactoring und Entwurfsmuster 3 Refactoring Refactoring ist riskant, deshalb Risiko mindern durch gute Unit Test Abdeckung Immer in kleinen Schritten: Ein Refactoring Schritt Testen Nächster Refactoring Schritt Testen usw. Häufiger Wechsel zwischen Implementation eines neuen Features und Refactoring Neue Features Refactoring Zeit

4 Software Engineering: 9. Refactoring und Entwurfsmuster 4 Ziele des Refactoring Lesbarkeit des Codes erhöhen. Refactoring kann parallel zu einem Code Review erfolgen. Design verbessern (sogenannte Bad Smells beseitigen). Code so umbauen, dass es möglich ist, Unit Tests zu schreiben. Code so vorbereiten, dass neue Features implementiert werden können.

5 Software Engineering: 9. Refactoring und Entwurfsmuster 5 Reengineering Bestehende (Alt)Software (engl. legacy software) fit machen für Erweiterungen neue Umgebung Performance Optimierungen etc. Zwei Strategien: Viele kleine Schritte: Refactoring im Grossen. Zwei grosse Schritte: 1.Reverse Engineering: Von der Implementierung zurück zur Abstraktion und dem Design 2.Forward Engineering: Redesign und neue Implementierung

6 Software Engineering: 9. Refactoring und Entwurfsmuster 6 Bad Smell Bad Smells sind Stellen im Code die stinken, d.h. es gibt Probleme wegen Verstoss gegen Design Prinzipien schlecht lesbarem Code. Die wichtigsten Bad Smells: Duplizierter Code Hoher Wartungsaufwand da Änderungen überall nachgeführt werden müssen. Lange Methode Schwierig zu verstehen Schlechte Wiederverwendbarkeit Ursache von Code Duplikationen Grosse Klasse Oft schlechte Wiederverwendbarkeit da die Klasse viele verschiedene Dinge machte Ursache von Code Duplikationen Lange Parameter Liste Schwierig zu lesen Gefahr des Vertauschens bei Parametern des gleichen Typs. Switch Statements bzw. if-else-if Ketten Möglicherweise unflexibel für Erweiterungen Gleichartige Switch Statements: Code Duplikationen

7 Software Engineering: 9. Refactoring und Entwurfsmuster 7 Refactoring Katalog Katalog der verschiedenen möglichen Refactorings. Wichtigster Katalog für objekt-orientiertes Refactoring: Format: Martin Fowler et al.: Refactoring Improving the Design of Existing Code. Addison-Wesley (2000) Name Zusammenfassung: Kurze Problembeschreibung Kurze Lösungsbeschreibung Einfaches Vorher-Nachher Beispiel Motivation: Beschreibung warum und warum nicht. Mechanik: Schritt-für-Schritt Anleitung. Beispiele: Grössere(s) Beispiel(e).

8 Software Engineering: 9. Refactoring und Entwurfsmuster 8 Methode extrahieren (Extract Method) Ein Codefragment kann zusammengefasst werden. Setze das Fragment in eine Methode, deren Name den Zweck bezeichnet. void printowing(double amount) { printbanner(); //print details System.out.println ("name: System.out.println ("amount } " + _name); " + amount); void printowing(double amount) { printbanner(); printdetails(amount); } void printdetails(double amount) { System.out.println ("name: " + _name); System.out.println ("amount " + amount); }

9 Software Engineering: 9. Refactoring und Entwurfsmuster 9 Methode extrahieren (Extract Method) Motivation: Verbesserung der Lesbarkeit. Indiz: Kommentarzeile vor dem Fragment das extrahiert werden kann. Codeduplikation: Verschiedene Codefragmente tun (fast) dasselbe. Name der neuen Methode sollte selbstsprechend sein. Nicht möglich wenn mehr als eine lokale Variable im Fragment geändert wird aber danach noch benötigt wird. Mechanik: 1.Neue Methode erzeugen. 2.Zu extrahierendes Codefragment dort hin kopieren. 3.All lokalen Variablen, die gelesen werden, werden Methodenparameter. 4.Die lokale Variable, die geändert wird, wird der Rückgabewert. 5.Compiler laufen lassen und Fehler beheben. 6.Zu extrahierenden Code entfernen und durch Aufruf der neuen Methode ersetzen. 7.Compiler laufen lassen und Fehler beheben. 8.Unit Test der Klasse (besser alle Unit Tests) ausführen.

10 Software Engineering: 9. Refactoring und Entwurfsmuster 10 Methode extrahieren (Extract Method) Beispiel: void handlearguments(string[] args) { try { _width = Integer.parseInt(args[0]); } catch (Exception e) { _width = DEFAULT_WIDTH; } try { _height = Integer.parseInt(args[1]); } catch (Exception e) { _height = DEFAULT_HEIGHT; } } Refactored: void handlearguments(string[] args) { _width = getintegerargument(args, 0, DEFAULT_WIDTH); _height = getintegerargument(args, 1, DEFAULT_HEIGHT); } int getintegerargument(string[] args, int index, int defaultvalue) { try { return Integer.parseInt(args[index]); } catch (Exception e) { return defaultvalue; } }

11 Software Engineering: 9. Refactoring und Entwurfsmuster 11 Beschreibende Variable einführen (Introduce Explaining Variable) Es gibt einen komplizierten Ausdruck. Setze den Ausdruck (oder Teile) in eine lokale Variable deren Name den Zweck erklärt. if ( (platform.touppercase().indexof("mac") > -1) && (browser.touppercase().indexof("ie") > -1) && wasinitialized() && resize > 0 ) { // do something } final boolean ismacos = platform.touppercase().indexof("mac") > -1; final boolean isiebrowser = browser.touppercase().indexof("ie") > -1; final boolean wasresized = resize > 0; if (ismacos && isiebrowser && wasinitialized() && wasresized) { // do something }

12 Software Engineering: 9. Refactoring und Entwurfsmuster 12 Methode umbenennen (Rename Method) Der Name einer Methode macht ihre Absicht nicht deutlich. Ändere den Name der Methode. Customer +getinvcdlimit() Customer +getinvoicablecreditlimit()

13 Software Engineering: 9. Refactoring und Entwurfsmuster 13 Methode hochziehen (Pull Up Method) Es gibt Methoden mit identischen Ergebnissen in den Unterklassen. Verschiebe die Methoden in die Oberklasse. Superclass Superclass +method() SubclassA +method() SubclassB +method() SubclassA SubclassB

14 Software Engineering: 9. Refactoring und Entwurfsmuster 14 Refactoring in IDEs Viele integerierte Entwicklungsumgebungen (IDEs) unterstützen automatisches Refactoring. Vorteile: Einfach und schnell Zuverlässig High-level source code editing Nachteile: Unzuverlässig Unerwartete Seiteneffekte

15 Software Engineering: 9. Refactoring und Entwurfsmuster 15 Entwurfsmuster (engl. Design Patterns) Gute Lösungen (auf der Basis von Designprinzipien) für immer wieder auftretende Entwurfsprobleme. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. Christopher Alexander 1977 Bilden ein Vokabular, das Entwickler benutzen, um über Design zu diskutieren (pattern language). Es gibt verschiedene Kataloge von Entwurfsmuster: Allgemeine für objektorientierte Programmierung. Spezielle für bestimmte Fachdomänen. Für Architekturmuster. Für Idiome, die spezifisch für eine Programmiersprache sind. Was Entwurfsmuster nicht sind: Algorithmen Code Kochrezepte um Code zu generieren. Achtung: Falsch eingesetzte Entwurfsmuster schaden!

16 Software Engineering: 9. Refactoring und Entwurfsmuster 16 Gang of Four and POSA Der einflussreichste Musterkatalog ist das Buch der sogenannten Gang of Four (GoF): E. Gamma, R. Helm, R. Johnson, und J. Vlissides: Design Patterns - Elements of Reusable Object-Oriented Software, (Addison-Wesley, 1995) Die GoF Entwurfsmuster sind das Grundvokabular für objektorientiertes Design. Ebenfalls einflussreich ist POSA: F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture A System of Patterns, (Addison-Wesley, 1996) Der Schwerpunkt bei POSA sind Architekturmuster.

17 Software Engineering: 9. Refactoring und Entwurfsmuster 17 Beschreibungsschema Die Beschreibung eines Entwurfsmuster folgt einem bestimmten Schema. Es gibt verschiedene Varianten dieses Schema. Das GoF Schema: Name des Musters Zweck Alternative Namen Motivation Anwendbarkeit Struktur Beteiligte Klassen Zusammenarbeit Konsequenzen Implementierung Beispielcode Bekannte Beispiele Verwandte Muster

18 Software Engineering: 9. Refactoring und Entwurfsmuster 18 Architekturmuster Layers Pipes and Filters Model-View-Controller

19 Software Engineering: 9. Refactoring und Entwurfsmuster 19 Architekturmuster: Layers The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction. POSA(31) Layer 4 Layer 3 Layer 2 Layer 1 höchste Abstraktion niedrigste Abstraktion

20 Software Engineering: 9. Refactoring und Entwurfsmuster 20 Layers: Beispiele OSI / ISO Schichtenmodell für Kommunikation: Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical Layer Java Applikation: Java Programm Java Virtuelle Maschine Betriebssystem

21 Software Engineering: 9. Refactoring und Entwurfsmuster 21 Layers: Regeln 1. Jede Schicht ist unabhängig von den darüber liegenden Schichten. 2. Jede Schicht ist ein Service für die darüberliegende Schicht. 3. Der Zugriffe auf die darunterliegende Schicht erfolgt über eine Schnittstelle. 4. Strict Layering: Eine Schicht darf nur auf die unmittelbar darunterliegende Schicht zugreifen. 5. Layer Bridging: Eine Schicht darf auf alle niederen Schichten zugreifen. Layer 3 Layer 2 Layer Bridging Layer 1

22 Software Engineering: 9. Refactoring und Entwurfsmuster 22 Dreischichtenarchitektur Grundarchitektur für viele Anwendungen: Präsentationsschicht Fachschicht Datenschicht Präsentationsschicht (Benutzeroberfläche) behandelt Benutzereingaben und präsentiert Daten. Aus- und Eingabe via Konsole oder Graphical User Interface (GUI) als fat client (z.b. mit Java Swing) oder als thin client mit HTML Fachschicht (Business Logic) behandelt fachliche Aspekte. Semantische Validierungen Berechnungen Datenschicht (Infrastrukturschicht, Data Access Layer) behandelt das Laden und Speichern der Daten. Integration Nachrichtensystem Sicherheit

23 Software Engineering: 9. Refactoring und Entwurfsmuster 23 Architekturmuster: Pipes and Filters The Pipes and Filters architectural pattern provides a structure for systems that process a stream of data. Each processing step is encapsulated in a filter component. Data is passed through pipes between adjacent filters. Recombining filters allows you to build families of related systems. POSA(53) Filter 1 Filter 2 Filter 3 Input Pipes Output

24 Software Engineering: 9. Refactoring und Entwurfsmuster 24 Pipes and Filters: Beispiel Unix: Verkettung einfacher Programme (Filter) über die textuelle Ein- und Ausgabe mittels dem Pipe-Symbol ' '. Compiler: Beispiel: Liste alle Java Source Code Dateien eines Verzeichnisses nach der Zahl der Codezeile. wc *.java sort -n awk '/.+java/ {print $1 "\t" $4}' Parser Optimizer Code Generator Source Code Abstract Syntax Tree Binärer Code

25 Software Engineering: 9. Refactoring und Entwurfsmuster 25 Pipes and Filters Jeder Filter ist eine Black-Box mit einer definierten Schnittstelle der Datenübertragung und des Datenformats. Filter sind beliebig kombinierbar und austauschbar, sofern die Schnittstellen und Datenformate zusammenpassen. Einfache Filter sind besser kombinierbar. Filter kann Daten filtern anreichern umwandeln Filter können die Daten am Stück verarbeiten oder häppchenweise (Streaming). Pull Prinzip: Filter holen die Daten aktiv aus der Pipe. Push Prinzip: Pipe schiebt aktiv die Daten in den Filter. Pipes können synchron oder asynchron arbeiten. Im letzteren Fall sind sie oft Warteschlangen.

26 Software Engineering: 9. Refactoring und Entwurfsmuster 26 Pipes and Filters Sequenzdiagramm mit zwei Filter im Pull-Prinzip: Datenquelle Filter1 Pipe Filter2 Datensenke read() read() Daten write() read() Daten Daten write() write() read()

27 Software Engineering: 9. Refactoring und Entwurfsmuster 27 Architekturmuster: MVC The Model-View-Controller architectural pattern (MVC) divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model. POSA(125) View 1 View 2 Presentation Layer Controller View Model blau = 15 rot = 7 grün = 18 Model

28 Software Engineering: 9. Refactoring und Entwurfsmuster 28 Model View Controller Model: Daten und Business Logik Wichtig: Model ist unabhängig von Controller und View Definiert Schnittstelle für Daten lesen Daten manipulieren und Datenverarbeitung initiieren (synchron oder asynchron) Data Changed Listener an- bzw. abmelden View: Präsentation der Daten (oder eines Teiles davon) als Grafik und/oder Text Datenausgabe Abhängig vom Model: Registriert sich als Data Changed Listener beim Model Liest Daten aus dem Model Spezifisch für ein bestimmtes Model Controller: Steuerung von Model und View durch Benutzerinteraktionen Dateneingabe Abhängig vom Model: Datenmanipulation und -verarbeitung Beeinflusst Zustand der View Oft starke Kopplung zwischen View und Controller

29 Software Engineering: 9. Refactoring und Entwurfsmuster 29 Model View Controller: Beispiel Java Swing Library, z.b. JTree: Model(s): TreeModel, SelectionModel View(s): TreeCellRenderer, TreeCellEditor Controller: TreeUI

30 Software Engineering: 9. Refactoring und Entwurfsmuster 30 Model View Controller: Klassendiagramm Generisches Klassendiagramm: Controller * * View +datachanged() 1 Model -data: Data +getdata():data +manipulate(d:somedata) 1 * «Interface» DataChangedListener +datachanged()

31 Software Engineering: 9. Refactoring und Entwurfsmuster 31 Model View Controller: Push Prinzip :Controller :Model v1:view v2:view user input analyse input manipulate() do some data processing datachanged() DataChangedListener getdata() repaint datachanged() DataChangedListener repaint data getdata() data

32 Software Engineering: 9. Refactoring und Entwurfsmuster 32 Model View Controller: Variationen Keine Trennung zwischen View und Controller. View kennt Controller nicht, aber umgekehrt. View und Controller sind beide voneinander unabhängig. Client-Server System: Fat Client Thin Client Client Controller View ControllerClient ViewClient Server Model ControllerServer Model ViewServer DataChangedListener: Hat meist einen anderen Namen Übermittelt welche Daten geändert wurden Fehlt bei Web Applikationen, da dort Datenübermittlung nach dem Pullund nicht nach dem Push-Prinzip erfolgt.

33 Software Engineering: 9. Refactoring und Entwurfsmuster 33 Links Refactoring Home Page Joel Spolsky: Rub a dub dub (2002) Eine Geschichte von erfolgreichem Refactoring (nicht in Java) James W. Cooper: The Design Patterns Java Companion Portland Pattern Repository Linda Rising - Patterns Almanac Buchtipp: GoF Patterns lernen mit grossem Unterhaltungswert Eric Freeman, Elisabeth Freemna, Kathy Sierra: Head First Design Patterns (2004)