Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Olaf Hecht, 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut.

Ähnliche Präsentationen


Präsentation zum Thema: "Olaf Hecht, 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut."—  Präsentation transkript:

1 Olaf Hecht, 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut für Informatik

2 Olaf Hecht, 2 Gliederung 1. Einleitung / Motivation 2. Objektorientierte Programmiersprachen und Wiederverwendung 3. Rahmenwerke 4. Regeln für das Erstellen von wiederverwendbarem Code 5. Fazit

3 Olaf Hecht, 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

4 Olaf Hecht, 4 1. Bereiche von Wiederverwendung eine Auswahl von Software-Artefakten, die wiederverwendet werden können: Anforderungsanalysen Spezifikationen Architektur Design Quellcode GUI Testfälle Daten

5 Olaf Hecht, 5 Gliederung 1. Einleitung / Motivation 2. Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen 3. Rahmenwerke 4. Regeln für das Erstellen von wiederverwendbarem Code 5. Fazit

6 Olaf Hecht, 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

7 Olaf Hecht, 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; }

8 Olaf Hecht, Polymorphie Problem des Beispiels schlechte Erweiterbarkeit schlecht wiederzuverwenden Lösung Objektorientierte Programmierung mit Vererbung + Polymorphie dynamischer Bindung

9 Olaf Hecht, 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

10 Olaf Hecht, 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

11 Olaf Hecht, 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

12 Olaf Hecht, 12 Gliederung 1. Einleitung / Motivation 2. Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen 3. Rahmenwerke 4. Regeln für das Erstellen von wiederverwendbarem Code 5. Fazit

13 Olaf Hecht, 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

14 Olaf Hecht, 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

15 Olaf Hecht, 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: Dont 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

16 Olaf Hecht, 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

17 Olaf Hecht, 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

18 Olaf Hecht, 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 Rahmenwerkes Applikation White-Box-Rahmenwerk Black-Box-Rahmenwerk

19 Olaf Hecht, 19 Gliederung 1. Einleitung / Motivation 2. Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen 3. Rahmenwerke 4. Regeln für das Erstellen von wiederverwendbarem Code 5. Fazit

20 Olaf Hecht, 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

21 Olaf Hecht, 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

22 Olaf Hecht, Wiederverwendbare Regeln (3) Regel: Halte die Anzahl der Codezeilen pro Methode gering. Grund: Höhere Wartbarkeit Abhilfe: Methode in mehrere kleinere Methoden unterteilen

23 Olaf Hecht, 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

24 Olaf Hecht, 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

25 Olaf Hecht, 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

26 Olaf Hecht, 26 Gliederung 1. Einleitung / Motivation 2. Objektorientierte Programmiersprachen und Wiederverwendung 2.1 Polymorphie 2.2 Schnittstellen und Methodennamen 2.3 Vererbung 2.4 Abstrakte Klassen 3. Rahmenwerke 4. Regeln für das Erstellen von wiederverwendbarem Code 5. Fazit

27 Olaf Hecht, 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.)

28 Olaf Hecht, 28 Danke!


Herunterladen ppt "Olaf Hecht, 1 Seminar Software aus Komponenten Entwurf von wiederverwendbaren Klassen Olaf Hecht Freie Universität Berlin, Institut."

Ähnliche Präsentationen


Google-Anzeigen