Olaf Hecht, [email protected] 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut

Olaf Hecht, [email protected] 1

Seminar „Software aus Komponenten“

Entwurf von wiederverwendbaren Klassen

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


Gliederung

1. Einleitung / Motivation2. Objektorientierte Programmiersprachen und

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


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


1. Bereiche von Wiederverwendung

• eine Auswahl von Software-Artefakten, die wiederverwendet werden können:

Anforderungsanalysen Spezifikationen Architektur Design Quellcode GUI Testfälle Daten


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


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


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;

}


2.1. Polymorphie

• Problem des Beispiels schlechte Erweiterbarkeit schlecht wiederzuverwenden

• Lösung Objektorientierte Programmierung mit

• Vererbung + Polymorphie• dynamischer Bindung


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


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


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


Gliederung


Wiederverwendung2.1 Polymorphie2.2 Schnittstellen und Methodennamen2.3 Vererbung2.4 Abstrakte Klassen

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


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


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


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


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


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


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


Gliederung



3. Rahmenwerke

4.Regeln für das Erstellen von wiederverwendbarem Code

5. Fazit


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



• 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



• Regel: Halte die Anzahl der Codezeilen pro Methode gering.

• Grund: Höhere Wartbarkeit

• Abhilfe: Methode in mehrere kleinere Methoden unterteilen



• 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



• 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



• 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


Gliederung



3. Rahmenwerke4. Regeln für das Erstellen von wiederverwendbarem Code

5.Fazit


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.)


Danke!

Documents

Olaf Hecht, [email protected] 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut