Design Patterns. OO-GetTogether. Volker Michels

Transkript

1 1 Design Patterns OO-GetTogether Volker Michels

2 2 Muster (engl. Pattern) Züllighoven: Ein Muster ist eine Abstraktion von einer konkreten Form, die wiederholt in bestimmten nicht willkürlichen Kontexten auftritt Christopher Alexander: Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing the same way twice.

3 3 Klassifikation von Mustern Konzeptionsmuster Beschreibung mit Begriffen und Konzepten eines Anwendungsbereichs Entwurfsmuster Beschreibung mit Elementen des Softwareentwurfs Programmiermuster Beschreibung durch programmiersprachliche Konstrukte

4 4 Entwurfsmuster helfen, existierende Softwareentwürfe zu analysieren und reorganisieren erleichtern Einarbeitung in Softwarearchitekturen sind Elemente einer Sprache für Softwarearchitekten A pattern is a solution to a problem in a context Kontext: Wiederkehrende Situation, in der das Muster angewendet wird Problem: berücksichtigt auch Rahmenbedingungen ( Forces ) Lösung: allgemeines Design, das jeder anwenden kann und Ziel und Rahmenbedingungen berücksichtigt

5 5 Beschreibung von Entwurfsmustern Name des Entwurfsmusters Problem, das gelöst werden soll Kontext, in dem sich das Problem stellt Lösung: Klassenhierarchie und Gestaltung ihrer Interaktion Konsequenzen (positive und negative) der Musteranwendung

6 6 Klassifikation von Entwurfsmustern Erzeugung (Creational): Objekterzeugung Struktur (Structure): Komposition von Klassen oder Objekten Verhalten (Behavior): Charakterisieren, wie Objekte und Klassen interagieren und verteilt sind

7 7 Katalog von Entwurfsmustern Gang of Four : Gamma, Helm, Johnson, Vlissides: Standardwerk: 23 fundamentale Patterns

8 8 Schablonenmethode (Template Method) Zweck: Definiere das Grundgerüst eines Algorithmus, verschiebe einige Schritte in Unterklassen. Subklassen können einige Schritte des Algorithmus neu definieren, ohne die Struktur des Algorithmus zu ändern Anwendbarkeit: Implementiere die invarianten Teile eines Algorithmus ein einziges mal, der veränderliche Teil wird von Subklassen implementiert Identifiziere gemeinsames Verhalten von Subklassen und lokalisiere es in einer gemeinsamen Klasse ( refactoring to generalize ) Kontrolliere die Erweiterung von Subklassen, lasse Erweiterungen nur an bestimmten Stellen zu durch Aufruf von Einschubmethoden an bestimmten Stellen

9 Beispiel für Template Method 9

10 Struktur für Template Method 10

11 11 Diskussion Template Method Fundamentale Technik für Wiederverwendung, wichtig für Rahmenwerke Invertierung der Kontrollstruktur ( Hollywood Prinzip : Don t call us, we call you ): Oberklasse ruft Funktionen der Unterklasse auf Einschubmethoden ( hook operations ) liefern Standardverhalten, werden erweitert oder implementiert von Subklassen

12 Strategiemuster 12 Trennung von Spezifikation und Implementation Zweck: Definiere eine Familie von Algorithmen, kapsele jeden einzelnen und mache sie austauschbar. Das Strategiemuster ermöglicht es, den Algorithmus unabhängig von nutzenden Klienten zu variieren. Anwendbarkeit: Viele verwandte Klassen unterscheiden sich nur in ihrem Verhalten. Unterschiedliche Varianten von Algorithmen werden benötigt Ein Algorithmus soll Daten verwenden, die Klienten nicht bekannt sein sollen. Eine Klasse definiert unterschiedliche Verhaltensweisen, die als mehrfache Bedingungsanweisungen in ihren Operationen erscheinen.

13 Struktur für Strategie 13 Ein Kontextobjekt hält eine Referenz auf ein Objekt einer konkreten Strategie. Sobald eine Strategie ausgeführt werden soll, stößt das Kontextobjekt den Algorithmus des Strategieobjekts an und versorgt es mit den benötigten Daten und Objekten.

14 Beispiel: Zinsstrategie für Konto 14

15 15 Diskussion des Strategiemusters Alternative zur Unterklassenbildung ->Vermischung der Implementierung von Algorithmus und Kontext wird vermieden, Algorithmus ist zur Laufzeit austauschbar Bedingungsanweisungen werden überflüssig gemacht Kommunikationsaufwand zwischen Strategie und Kontext Strategieobjekte sind zusätzliche Objektstrukturen, die Speicher benötigen

16 Viele weitere Patterns 16 Structural Behavioral Adapter Bridge Command Composite Proxy Facade Decorator Creational Iterator State Observer Abstract Factory Factory Method Prototype Singleton

17 17 OO-Principles, OO-Basics Encapsulate what varies Favor composition over inheritance Program to interface, not implementations Strive for loosely coupled designs between objects that interact Classes should be open for extension but closed for modification Depend on abstractions. Do not depend on concrete classes. Only talk to your friends. Don t call us, we ll call you A class should have only one reason to change Abstraction Encapsulation Polymorphism Inheritance

18 Denken in Patterns 18 Keep it simple: Verwende Patterns, wenn es eine natürliche Anwendung gibt, falls es eine einfachere Lösung gibt, benutze diese Patterns sind allgemeine Lösungen für wiederkehrende Probleme, getestet von vielen Entwicklern und deshalb sicher. Es bringt aber u.u. zusätzliche Probleme, es müssen die Konsequenzen für das restliche Design bedacht werden Die Entscheidung, ob ein Pattern anwendbar ist, benötigt viel Wissen und Erfahrung Patterns sind einfacheren Lösungen vorzuziehen, falls Änderung am System erwartet werden Anwendung von Patterns sollte nicht nur zur Design-Zeit, sondern auch beim Rafactoring in Betracht gezogen werden

19 Take home messages 19 Gute OO-Designs sind wiederverwendbar, erweiterbar, wartbar Patterns zeigen, wie Systeme mit guten OO-Design- Qualitäten erstellt werden können Patterns sind bewährte OO-Erfahrung Patterns liefern keinen Code, sondern generelle Lösungen zu Design-Problemen Patterns werden nicht erfunden, sondern entdeckt Die meisten Patterns beziehen sich auf Änderungen in Software Die meisten Patterns erlauben Änderungen eines Teil des Systems unabhängigen von den anderen Teilen Patterns liefern eine gemeinsames Vokabular zur Kommunikation mit anderen Entwicklern