Refactoring Andreas Martens Der Weg zum lesbaren Code.

Slides:



Advertisements
Ähnliche Präsentationen
mit Entwicklungsumgebungen (Eclipse) Software verbessern
Advertisements

DVG Einfache Klassen Einfache Klassen. DVG Einfache Klassen 2 Strukturen Beispiel: Personendaten bestehen aus –String name –String vorname.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
es gibt (fast) nichts, was nicht anders gemacht werden könnte
Java: Objektorientierte Programmierung
Java: Grundlagen der Objektorientierung
Polymorphie (Vielgestaltigkeit)
Polymorphie (Vielgestaltigkeit)
PKJ 2005/1 Stefan Dissmann Rückblick auf 2005 Was zuletzt in 2005 vorgestellt wurde: Klassen mit Attributen, Methoden und Konstruktoren Referenzen auf.
PKJ 2005/1 Stefan Dissmann Klassenhierarchie Person Kunde Goldkunde Lieferant Object.
Die Skriptsprache Perl (8) Wolfgang Friebel DESY Zeuthen.
Software Design Patterns Extreme Programming (XP).
DVG Kommentare1 Kommentare. DVG Kommentare 2 Kommentare Es gibt zwei Arten von Kommentaren: einzeilige Kommentare // der Kommentar geht.
DVG Klassen und Objekte
DVG Einfache Klassen 1 Einfache Klassen. 2DVG Einfache KlassenStrukturen Beispiel: Personendaten bestehen aus String name String name.
Einführung in die Programmierung Vererbung
Seite 1 Interface - Konzept Ein Interface führt einen neuen Datentyp ein: interface Frau {... } Das Interface enthält Deklarationen ( keine Definitionen.
Refactoring To Patterns Generalization Patterns. Einführung Ziel spezifisches Code -> allgemeingültigeres Code Motivation Beseitigung von mehrfach vorhandenes.
Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 Objektmodellierung Objekte und Klassen Ein Objekt ist ein Exemplar.
Javakurs FSS 2012 Lehrstuhl Stuckenschmidt
Einführung in die Programmierung Wintersemester 2009/10 Prof. Dr. Günter Rudolph Lehrstuhl für Algorithm Engineering Fakultät für Informatik TU Dortmund.
Javakurs FSS 2012 Lehrstuhl Stuckenschmidt
OOP-Begriffe Abstraktion Modellieren Klasse Objekt Attribute Methoden
Aufgaben Version 1: Es soll eine Wetterstation mit folgenden zwei Anzeigen implementiert werden: Aktuelle Wetterbedingungen mit Temperatur und.
Ruby Refactoring Plug-In für Eclipse
Testtechniken-Praktikum WS 2005/06 1 Testgetriebene Entwicklung Andreas Höfer Dr. Matthias Müller mit Beiträgen von Johannes Link.
EPROG Tutorium #4 Philipp Effenberger
Programmiervorkurs WS 2014/15 Instanzmethoden
OOP-Begriffe Abstraktion Modellieren Klasse Objekt Attribute Methoden
Test-Driven Development
Abstrakte Klassen und das Interface-Konzept
Vererbung. Klassen - Vererbung  Eine Klasse kann von einer Basisklasse abgeleitet werden  Die abgeleitete Klasse erbt die Eigenschaften und Methoden.
Einführung. Ziel der Veranstaltung  Vermittlung von Grundkenntnissen in C++  Solide Basis für anschließende Weiterentwicklung  Fähigkeit, kleine Programme.
Tutorium Software-Engineering SS14 Florian Manghofer.
SE Virtualisierung von Universitäten Zwischenbericht Liebe KollegInnen, Anbei finden Sie eine PowerPoint-Vorlage zur Erarbeitung eines kurzen Zwischenberichts.
1 freedroidz – spielend Programmieren lernen. 2 Was ist freedroidz?
Verwalten von Daten mit Hilfe von NTFS
Anforderungen an die neue Datenstruktur
Konstruktoren.
Schnittstellen.
Präsentationen im alten Design
Hello World! Javakurs 2013 Arne Kappen
OOP II.
Der Abschluss einer Schlange
Java-Kurs Übung Klassen und Objekte: Vererbung (Fortsetzung)
Willkommen bei PowerPoint
Referenzen In c kennen wir gewöhnliche Variablen und Pointer.
Allgemeine Befehle für die allgemeine Liste
Create Table, Rechte und Rollen
Anleitung für Administratoren
Grundkurs Informatik 11-13
Ruby Refactoring Plug-In für Eclipse
Raphael Fischer Informatik II - Übung 06 Raphael Fischer
Sich drehende Zahnräder
Ausgewählte Folien für Lehreinheit C3
Polymorphie Überladen
2. Vererbung und Kapselung
«Delegierter» Methoden Schablone Funktionszeiger
Definition Felder Konstruktor Methoden Beispiel
1. Die rekursive Datenstruktur Liste 1
Datenstrukturen und Softwareentwicklung
Übersicht und Benutzung von Sphinx
9. Vererbung und Polymorphie
Implementieren von Klassen
Statische und Nichtstatische Methoden Properties / Eigenschaften
Wissenschaftliches Projekt
Practical Exercises and Theory
1. Die rekursive Datenstruktur Liste 1.6 Die Datenstruktur Stapel
Informatik Softwareentwicklung – 4.3 Entwurfsmuster
Schmock Mutter nicht ausreichend versorgt  fast verhungert Mutter bei Geburt verstorben Schmock mit Flasche aufgezogen.
 Präsentation transkript:

Refactoring Andreas Martens Der Weg zum lesbaren Code

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

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/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/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/35 Was ist Refactoring Ziele: – Verbesserung und Pflege des Designs – Verständlichkeit – Finden von Fehlern – Hilfe, um schneller zu Programmieren

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/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/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/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/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/35 I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings

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/35 ● Move Method ● Move Field ● Extract Class ● Inline Class ● Hide Delegate ● Moving Features Between Objects Einige Beispiele

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/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/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/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/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/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/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/35 Moving Features Between Objects Wenn Methode zu Komplex ist ● Methode zerlegen ● Einige Teile in der Ursprungsklasse lassen Move Method: Probleme

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

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/35 ● Pull Up/Down Field ● Pull Up/Down Method ● Replace Consructor with Factory Method ● Extract Superclass ● Extract Subclass ● Dealing with Generalization Einige Beispiele

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/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/35 I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings

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/35 Big Refactorings Hierarchische Vererbung Eine Vorhandene Hierarchie ist für 2 Aufgaben zuständig ➔ Spagetti Code ➔ Schwer verständlich ➔ Duplizierter Code

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/35 Big Refactorings Trenne GUI von der Logik ● Es sind GUI Klassen vorhanden die Programmlogik enthalten

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/35 Übersicht I.Was ist Refactoring II.Moving Features Between Objects III.Dealing with Generalization IV.Big Refactorings V.Ende

35/35 Fragen ? Andreas Martens