Olaf Hecht, hecht@inf.fu-berlin.de 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren...

Olaf Hecht, hecht@inf.fu-berlin.de 1

Seminar „Software aus Komponenten“

Entwurf von wiederverwendbaren Klassen

Olaf HechtFreie Universität Berlin, Institut für Informatik

Olaf Hecht, hecht@inf.fu-berlin.de 2

Gliederung

1. Einleitung / Motivation2. Objektorientierte Programmiersprachen und

Wiederverwendung3. Rahmenwerke4. Regeln für das Erstellen von wiederverwendbarem Code5. Fazit

Olaf Hecht, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 8

2.1. Polymorphie

• Problem des Beispiels schlechte Erweiterbarkeit schlecht wiederzuverwenden

• Lösung Objektorientierte Programmierung mit

• Vererbung + Polymorphie• dynamischer Bindung

Olaf Hecht, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 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, hecht@inf.fu-berlin.de 28

Danke!