Freie Universität Berlin Institut für Informatik 26 August 2003 Seminar „Software aus Komponenten“ Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut für Informatik Olaf Hecht, hecht@inf.fu-berlin.de 1 prechelt@inf.fu-berlin.de

Gliederung Einleitung / Motivation Objektorientierte Programmiersprachen und Wiederverwendung Rahmenwerke Regeln für das Erstellen von wiederverwendbarem Code Fazit Olaf Hecht, hecht@inf.fu-berlin.de 2

1. Motivation Vorteile von Software-Wiederverwendung geringere Entwicklungszeit, da auf bereits bestehende Lösungen zurückgegriffen wird geringere Entwicklungskosten erhöhte Zuverlässigkeit, da Software bereits eingesetzt und getestet erhöhte Produktqualität geringere Wartungskosten Olaf Hecht, hecht@inf.fu-berlin.de 3

1. Bereiche von Wiederverwendung Freie Universität Berlin Institut für Informatik 1. Bereiche von Wiederverwendung 26 August 2003 eine Auswahl von Software-Artefakten, die wiederverwendet werden können: Anforderungsanalysen Spezifikationen Architektur Design Quellcode GUI Testfälle Daten Olaf Hecht, hecht@inf.fu-berlin.de 4 prechelt@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik Gliederung 26 August 2003 Einleitung / Motivation Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen Rahmenwerke Regeln für das Erstellen von wiederverwendbarem Code Fazit Olaf Hecht, hecht@inf.fu-berlin.de 5 prechelt@inf.fu-berlin.de

2.1. Polymorphie Griechisches Wort für Vielgestaltigkeit Inklusions-Polymorphie Objekte von verwandten Klassen können auf die gleiche Nachricht/Methode unterschiedlich reagieren lässt sich unterteilen in: Laufzeit-Polymorphie dynamische Bindung Bestimmung der aufzurufenden Methode erst zur Laufzeit des Programms Kompilationszeit-Polymorphie statische Bindung Festlegung der Funktionsausführung bei der Übersetzung des Codes Laufzeit-Polymorphie ist ein großer Vorteil von objektorientierten Sprachen Olaf Hecht, hecht@inf.fu-berlin.de 6

Freie Universität Berlin Institut für Informatik 2.1. Polymorphie 26 August 2003 Bsp: Funktion in einem Universitätsverwaltungsprogramm string getName(int memberTyp, int index) { switch (memberTyp){ case STUDENT: return StudentData[index].name; case TEACHER: return TeacherData[index].name; } return ERROR; Olaf Hecht, hecht@inf.fu-berlin.de 7 prechelt@inf.fu-berlin.de

Freie Universität Berlin Institut für Informatik 2.1. Polymorphie 26 August 2003 Problem des Beispiels schlechte Erweiterbarkeit schlecht wiederzuverwenden Lösung Objektorientierte Programmierung mit Vererbung + Polymorphie dynamischer Bindung Olaf Hecht, hecht@inf.fu-berlin.de 8 prechelt@inf.fu-berlin.de

2.2. Schnittstellen und Methodennamen bieten Datenabstraktion Programmierer muss nur das Protokoll verstehen, um Klasse wiederzuverwenden Methodennamen sollten auch wiederverwendet werden Bedeutung der Methode kann schneller erfasst werden, wenn der Name bereits bekannt ist sollten die implementierte Funktionalität wiederspiegeln dadurch Benutzung der Klasse schneller erlernbar Olaf Hecht, hecht@inf.fu-berlin.de 9

2.3. Vererbung Vererbung = Code-Wiederverwendung anstelle von Code-Duplizierung neue Basisklasse einführen dadurch wird der Code auch pflegeleichter erhöhte Wartbarkeit „neuer“ Programmierstil Programmierung durch Differenzierung ableiten von einer Klasse, die ein ähnliches Problem löst neuer Code behandelt lediglich die Unterschiede Olaf Hecht, hecht@inf.fu-berlin.de 10

2.4. Abstrakte Klassen keine Objekterzeugung möglich unterstützen Wiederverwendbarkeit durch Vererbung leichter wiederzuverwenden, da Abstraktion von der Datenrepräsentation keine Festlegung auf konkretes Verhalten Klassen sollten wenn möglich als abstrakt deklariert werden Abstraktion in der Design-Phase ist schwer, braucht Erfahrung Umwandlung der Klassen von konkret nach abstrakt in einer Konsolidierungsphase Olaf Hecht, hecht@inf.fu-berlin.de 11

Freie Universität Berlin Institut für Informatik Gliederung 26 August 2003 Einleitung / Motivation Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen Rahmenwerke Regeln für das Erstellen von wiederverwendbarem Code Fazit Wiederverwendung von Design Olaf Hecht, hecht@inf.fu-berlin.de 12 prechelt@inf.fu-berlin.de

3. Rahmenwerke englisch: Frameworks objektorientiertes abstraktes Design für die generische Lösung einer Problemfamilie besteht aus einer Menge von zusammenarbeitenden Klassen bildet ein nahezu vollständiges Programm wichtige Technik für den Bau von wiederverwendbarer Software nicht nur Code-Wiederverwendung, sondern auch Wiederverwendung des Designs Olaf Hecht, hecht@inf.fu-berlin.de 13

3. Ausprägungen von Rahmenwerken Applikationsrahmenwerke bieten Grundfunktionalität und Struktur für die Entwicklung von Applikationen wie z.B. GUI-Funktionalitäten Bsp: Java Swing Domänenspezifische Rahmenwerke bieten Grundfunktionalität und Struktur für die Entwicklung von Software einer spezifischen Anwendungsdomäne Bsp: Rahmenwerk für Buchhaltungsprogramme Olaf Hecht, hecht@inf.fu-berlin.de 14

3. Rahmenwerke Verwendung Softwareentwickler fügt den anwendungsfallspezifischen Code hinzu ruft die zur Verfügung gestellte Funktionalität nicht selber auf, sondern läßt sich aufrufen Kontrollflußumkehrung im Gegensatz zum Aufruf einer Funktion aus einer Bibliothek Hollywood-Prinzip: „Don‘t call us, we will call you“ Unterteilung in White-Box- und Black-Box-Rahmenwerke nach der Sichtbarkeit der inneren Strukturen und der Art, wie sie vom Softwareentwickler zu benutzen sind Olaf Hecht, hecht@inf.fu-berlin.de 15

3.1. White-Box-Rahmenwerke Wiederverwendung durch Unterklassenbildung Softwareentwickler muss Unterklassen von abstrakten oder konkreten Klassen bilden Interne Struktur der Basisklasse ist für den Softwareentwickler sichtbar Softwareentwickler braucht Kenntnis über Struktur und Implementierung des Rahmenwerkes Hoher Lernaufwand Olaf Hecht, hecht@inf.fu-berlin.de 16

3.2. Black-Box-Rahmenwerke Wiederverwendung durch Komposition Softwareentwickler baut sich sein Programm aus bereitgestellten Komponenten zusammen Schreibt anwendungsspezifische Komponenten und bindet sie ein Interne Struktur des Rahmenwerkes ist nicht sichtbar Programmierer muß lediglich die Schnittstellen der Komponenten und des Rahmenwerkes bedienen können Leichter erlernbar Olaf Hecht, hecht@inf.fu-berlin.de 17

3.3. White-Box- vs. Black-Box-Rahmenwerke Freie Universität Berlin Institut für Informatik 3.3. White-Box- vs. Black-Box-Rahmenwerke 26 August 2003 Black-Box schneller erlernbar Entwicklung mit White-Box wird schnell unübersichtlich durch hohe Anzahl von Unterklassen => Black-Box ist vorzuziehen Black-Box-Systeme sind aber schwierig auf Anhieb zu entwickeln da ein hoher Grad an Abstraktion erforderlich ist Lebenszyklus eines Rahmenwerkes Applikation White-Box-Rahmenwerk Black-Box-Rahmenwerk Olaf Hecht, hecht@inf.fu-berlin.de 18 prechelt@inf.fu-berlin.de

Regeln für das Erstellen von wiederverwendbarem Code Gliederung Einleitung / Motivation Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen Rahmenwerke Regeln für das Erstellen von wiederverwendbarem Code Fazit Olaf Hecht, hecht@inf.fu-berlin.de 19

4. Wiederverwendbare Regeln (1) Freie Universität Berlin Institut für Informatik 4. Wiederverwendbare Regeln (1) 26 August 2003 Regel: Entferne Fallunterscheidungen, die Objekte auf ihre Klassenzugehörigkeit überprüfen. Grund: Schlechte Erweiterungsmöglichkeit Negatives Bsp: … BaseClass obj; if (obj instanceof ClassX) doSomethingX(); else if (obj instanceof ClassY) doSomethingY(); … Abhilfe: neue Methode doSomething in BaseClass Fallspezifischen Code jeweils in doSomething Methode der Unterklassen behandeln Olaf Hecht, hecht@inf.fu-berlin.de 20 prechelt@inf.fu-berlin.de

4. Wiederverwendbare Regeln (2) Freie Universität Berlin Institut für Informatik 4. Wiederverwendbare Regeln (2) 26 August 2003 Regel: Halte die Anzahl der Eingabeparameter von Methoden gering. Grund: Leichter (wieder-)zuverwenden Lesbarerer Code Abhilfe: Entweder: Methode in Bezug auf die Verwendung der Parameter in mehrere Methoden unterteilen Oder: Mehrere Parameter zu einer Klasse zusammenfassen, und Objekt dieser Klasse der Methode übergeben Olaf Hecht, hecht@inf.fu-berlin.de 21 prechelt@inf.fu-berlin.de

4. Wiederverwendbare Regeln (3) Freie Universität Berlin Institut für Informatik 4. Wiederverwendbare Regeln (3) 26 August 2003 Regel: Halte die Anzahl der Codezeilen pro Methode gering. Grund: Höhere Wartbarkeit Abhilfe: Methode in mehrere kleinere Methoden unterteilen Olaf Hecht, hecht@inf.fu-berlin.de 22 prechelt@inf.fu-berlin.de

4. Wiederverwendbare Regeln (4) Freie Universität Berlin Institut für Informatik 4. Wiederverwendbare Regeln (4) 26 August 2003 Regel: Baue tiefe, schmale Klassenhierarchien. Grund: Zu weitläufige Klassenhierarchien sind ein Anzeichen dafür, dass eine Konsolidierung notwendig ist. Abhilfe: Einführen neuer abstrakter Basisklassen Olaf Hecht, hecht@inf.fu-berlin.de 23 prechelt@inf.fu-berlin.de

4. Wiederverwendbare Regeln (5) Freie Universität Berlin Institut für Informatik 4. Wiederverwendbare Regeln (5) 26 August 2003 Regel: Abstrahiere in den Klassen von der Datenrepräsentation. Grund: Klassen werden leichter als abstrakt deklarierbar Abhilfe: Definieren von Getter- und Setter-Methoden für den Zugriff auf Klassenvariablen Olaf Hecht, hecht@inf.fu-berlin.de 24 prechelt@inf.fu-berlin.de

4. Wiederverwendbare Regeln (6) Freie Universität Berlin Institut für Informatik 4. Wiederverwendbare Regeln (6) 26 August 2003 Regel: Halte die Anzahl von Methoden pro Klassen gering. Grund: Kleine Klassen sind besser erlernbar Abhilfe: Aufspalten der Klassen in Bezug auf die Verwendung von Klassenvariablen und Methoden Olaf Hecht, hecht@inf.fu-berlin.de 25 prechelt@inf.fu-berlin.de

Gliederung Fazit Einleitung / Motivation Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen Rahmenwerke Regeln für das Erstellen von wiederverwendbarem Code Fazit Olaf Hecht, hecht@inf.fu-berlin.de 26

5. Fazit Wiederverwendung bietet viele Vorteile Die Erstellung von wiederverwendbaren Klassen ist aber nicht einfach, braucht Erfahrung und höhere Entwicklungszeit Wiederverwendung hat aber nicht nur Vorteile Softwareentwicklern fehlt häufig die Motivation dazu, die Klassen für bessere Wiederverwendbarkeit zu konsolidieren Performanzprobleme Weiterer wichtiger Aspekt für den Bau von wiederverwendbaren Klassen ist eine gute Dokumentation der Methoden und Klassen Artikel diente als Grundlage für Arbeiten auf dem Gebiet des Refactoring (Martin Fowler et al.) Olaf Hecht, hecht@inf.fu-berlin.de 27

Danke! Olaf Hecht, hecht@inf.fu-berlin.de 28