olaf hecht, [email protected] 1 seminar software aus komponenten entwurf von wiederverwendbaren...
TRANSCRIPT
Olaf Hecht, [email protected] 1
Seminar „Software aus Komponenten“
Entwurf von wiederverwendbaren Klassen
Olaf HechtFreie Universität Berlin, Institut für Informatik
Olaf Hecht, [email protected] 2
Gliederung
1. Einleitung / Motivation2. Objektorientierte Programmiersprachen und
Wiederverwendung3. Rahmenwerke4. Regeln für das Erstellen von wiederverwendbarem Code5. Fazit
Olaf Hecht, [email protected] 3
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, [email protected] 4
1. Bereiche von Wiederverwendung
• eine Auswahl von Software-Artefakten, die wiederverwendet werden können:
Anforderungsanalysen Spezifikationen Architektur Design Quellcode GUI Testfälle Daten
Olaf Hecht, [email protected] 5
Gliederung
1. Einleitung / Motivation
2.Objektorientierte Programmiersprachen und Wiederverwendung2.1 Polymorphie2.2 Schnittstellen und Methodennamen2.3 Vererbung2.4 Abstrakte Klassen
3. Rahmenwerke4. Regeln für das Erstellen von wiederverwendbarem Code5. Fazit
Olaf Hecht, [email protected] 6
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, [email protected] 7
2.1. Polymorphie
• 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, [email protected] 8
2.1. Polymorphie
• Problem des Beispiels schlechte Erweiterbarkeit schlecht wiederzuverwenden
• Lösung Objektorientierte Programmierung mit
• Vererbung + Polymorphie• dynamischer Bindung
Olaf Hecht, [email protected] 9
2.2. Schnittstellen und Methodennamen
• Schnittstellen 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, [email protected] 10
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, [email protected] 11
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, [email protected] 12
Gliederung
1. Einleitung / Motivation2. Objektorientierte Programmiersprachen und
Wiederverwendung2.1 Polymorphie2.2 Schnittstellen und Methodennamen2.3 Vererbung2.4 Abstrakte Klassen
3. Rahmenwerke4. Regeln für das Erstellen von wiederverwendbarem Code5. Fazit
Olaf Hecht, [email protected] 13
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, [email protected] 14
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, [email protected] 15
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, [email protected] 16
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, [email protected] 17
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, [email protected] 18
3.3. White-Box- vs. Black-Box-Rahmenwerke
• 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 RahmenwerkesApplikation
White-Box-Rahmenwerk
Black-Box-Rahmenwerk
Olaf Hecht, [email protected] 19
Gliederung
1. Einleitung / Motivation2. Objektorientierte Programmiersprachen und
Wiederverwendung2.1 Polymorphie2.2 Schnittstellen und Methodennamen2.3 Vererbung2.4 Abstrakte Klassen
3. Rahmenwerke
4.Regeln für das Erstellen von wiederverwendbarem Code
5. Fazit
Olaf Hecht, [email protected] 20
4. Wiederverwendbare Regeln (1)
• 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, [email protected] 21
4. Wiederverwendbare Regeln (2)
• 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, [email protected] 22
4. Wiederverwendbare Regeln (3)
• Regel: Halte die Anzahl der Codezeilen pro Methode gering.
• Grund: Höhere Wartbarkeit
• Abhilfe: Methode in mehrere kleinere Methoden unterteilen
Olaf Hecht, [email protected] 23
4. Wiederverwendbare Regeln (4)
• 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, [email protected] 24
4. Wiederverwendbare Regeln (5)
• 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, [email protected] 25
4. Wiederverwendbare Regeln (6)
• 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, [email protected] 26
Gliederung
1. Einleitung / Motivation2. Objektorientierte Programmiersprachen und
Wiederverwendung2.1 Polymorphie2.2 Schnittstellen und Methodennamen2.3 Vererbung2.4 Abstrakte Klassen
3. Rahmenwerke4. Regeln für das Erstellen von wiederverwendbarem Code
5.Fazit
Olaf Hecht, [email protected] 27
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, [email protected] 28
Danke!