Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Ziel: Zuhörer mit hineinnehmen in pattern-basierten Entwurf

Ähnliche Präsentationen


Präsentation zum Thema: "Ziel: Zuhörer mit hineinnehmen in pattern-basierten Entwurf"—  Präsentation transkript:

1 Eine Pattern-Sprache zur Strukturierung großer Software-Systeme mit Java
Ziel: Zuhörer mit hineinnehmen in pattern-basierten Entwurf Praxistauglichkeit von Pattern-Sprachen aufzeigen Die vorgestellte Pattern-Sprache ist Work in Progress. Die Inhalte und die Organisation sind stabil, die Details der Präsentation noch nicht.

2 Übersicht  Patterns und Pattern-Sprachen
Packages als Kapselungs-Einheiten Patterns zur Gestaltung der Package-Schnittstelle Beziehungen zwischen Packages Diskussion

3 Patterns Ein Pattern ist eine wiederverwendbare Lösung für ein Problem in einem Kontext. Nicht nur die Lösung sondern auch eine Beschreibung des Designraums. Kontext: definiert die Designsituation, in der das Problem auftritt. Ein Pattern ist ein Stück Literatur, das eine allgemeine Lösung zu einem Problem in einem bestimmten Kontext beschreibt. Wie bei jeder anderen literarischen Form auch gibt es also natürlich „gute“ und „schlechte“ Patterns. Ein wichtiger Meilenstein war das Buch „Design Patterns“ von Gamma, Helm, Johnsson und Vlissides, aber es gibt inzwischen eine Fülle von veröffentlichten Patterns und ein erhebliches Maß an – zumindest industrieller – Forschung, die in diese Richtung geht. Es gibt einen wichtigen Unterschied zwischen einem Pattern und einfach „gutem Design“, weil ein Pattern die Erfahrung aus vielen erfolgreichen Verwendungen enthält. Besonders wichtig ist deswegen die Beschreibung des Problems, das gelöst wird. Eine gut formulierte Problembeschreibung ist weder zu weit noch zu eng gefaßt und nennt die widerstrebenden sog. Forces, die den Lösungsraum einschränken und zwischen denen ein Gleichgewicht gefunden werden muß. Patterns bilden oft das Vokabular, mit dem Softwareteams über ihr Design reden. Deswegen ist der Name ein weiterer sehr wichtiger Teil des Patterns: Er sollte eingängig, aussagekräftig und leicht in normalen Sätzen verwendbar sein. Dieser Vortrag verfolgt das doppelte Ziel, sowohl den Inhalt als auch die Form darzustellen, und deswegen wird eine sehr knappe Patternform gewählt. Problem: beschreibt die widerstrebenden Kräfte, die eine Lösung beeinflussen. Lösung: beschreibt, wie diese Forces in ein Gleichgewicht gebracht werden.

4 Pattern-Kataloge Ein Pattern-Katalog ist eine Sammlung von Patterns
Nicht notwendigerweise miteinander verbunden Gruppierung ist möglich nach der Problemdomäne (Finanzwirtschaft, Telekommunikation, ...) Lösungsdomäne (Java, C++, RDBMS, ...) Beispiel: „Design Patterns“ (Gamma et al.) Wenn Patterns veröffentlicht werden, geschieht das oft in Form von Sammlungen (ein einzelnes Pattern füllt kein Buch... ) GOF, POSA-Bände Die Patterns sind in solchen Sammlungen oft gar nicht oder nur lose miteinander verbunden; oft ist das einzige, was sie gemeinsam haben, das Oberthema, unter dem sie stehen. Bei „Design Patterns“ ist das in etwa „allgemeine Entwurfsmuster in C++ mit einem leichten Schwerpunkt auf GUI“, bei POSA ist es „allgemeine Architekturmuster“, bei POSA 2 „Muster für verteilte Architekturen“ etc. Solche Pattern-Kataloge haben den Charakter von Nachschlagewerken. Sehr wertvoll ist in diesem Zusammenhang der Pattern-Almanach, den Linda Rising 2000 zusammengestellt hat. Pattern-Kataloge bringen gegenüber einzelnen Patterns einen Mehrwert, weil sie einen konsistenten Detaillierungsgrad und eine Basis für ein gemeinsames Vokabular im Teamkontext liefern.

5 Pattern-Sprachen Pattern-Sprachen beschreiben einen größeren Bereich im Lösungsraum Viele kleine Patterns mit ihren Beziehungen Oft führt ein Pattern ganz natürlich zu einem anderen Die Lösung des einen Patterns gehört zum Kontext des nächsten Das Ganze ist mehr als die Summe seiner Teile Noch hilfreicher ist die Verbindung von Patterns zu Pattern-Sprachen. Eine Pattern-Sprache steht unter einem Oberthema und beschreibt mit einer gewissen Vollständigkeit die Bandbreite an möglichen Lösungen. Sie tut das, indem sie Patterns in Beziehung zueinander setzt, typischerweise „generativ“: Die Lösung eines Patterns gehört zum Kontext des nächsten. So wirft das Einführen einer zusätzlichen Indirektion oft die Frage auf, wie das entsprechende Objekt erzeugt werden soll, und führt damit ganz natürlich zu irgendeiner Form von Factory. Eine Pattern-Sprache besteht typischerweise aus einer ganzen Reihe von relativ kleinen Patterns, und deren Beziehungen werden oft graphisch visualisiert. Sie stellen dadurch ein reiches Vokabular für die Diskussion über den Entwurf zur Verfügung, bieten einen schnellen Überblick und erlauben die selektive Verwendung. Auf diese Weise ist eine Pattern-Sprache sehr viel mehr als die Summe ihrer Teile.

6 Übersicht Patterns und Pattern-Sprachen
 Packages als Kapselungs-Einheiten Patterns zur Gestaltung der Package-Schnittstelle Beziehungen zwischen Packages Diskussion

7 Kapselung Kapselung ist die Trennung von Schnittstelle (inkl. Kontrakt) und Implementierung „Was ich nicht weiß, macht mich nicht heiß“: Kapselung vereinfacht Arbeitsteilung Dokumentiert Systemstruktur „Divide et impera“: Gesamtkomplexität ist reduziert Klassen: Kapselung im Kleinen Kapselung ist ein inzwischen allgemein geläufiges Konzept (obwohl es beiweitem nicht so allgemein angewendet wird, wie man vermuten sollte): Die Schnittstelle wird von der Implementierung getrennt, wobei die Schnittstelle natürlich nicht nur eine Menge von Methodensignaturen ist sondern auch irgendeine Form von Kontrakt darüber enthält, was die jeweilige Methode denn tun soll. Gut geschnittene Kapselung bietet eine ganze Reihe von Vorteilen: Sie vereinfacht die Arbeitsteilung, dokumentiert die Systemstruktur und reduziert die Gesamtkomplexität. Bei der Kapselung wird der Unterschied zwischen dem Einsatz eines Sprachmittels und der idiomatischen Anwendung des Konzepts deutlich: Jeder Java-Entwickler verwendet Klassen, aber nur wenige planen bewußt die Schnittstellen ihrer Klassen, um eine gut geschnittene Kapselung zu erreichen. Das ist der Anspruch, den Patterns haben: Sie wollen sagen, wann und wie die Lösung anzuwenden ist. Die Kapselung großer Java-Systeme ist der allgemeine Kontext, in dem die Pattern-Sprache steht, die im Rest des Vortrags vorgestellt wird. ?

8 Encapsulating Package
Problem: In einem großen System werden die Beziehungen der Klassen unübersichtlich.

9 Encapsulating Package (2)
Lösung: Identifiziere zusammenhängende Gruppen von Klassen und kapsele sie als größere Abstraktionen in Packages.

10 Encapsulating Package (3)
J Die Anzahl der Teile und ihrer Beziehungen wird kleiner J Die Architektur des Systems spiegelt sich im Quelltext J Packagenamen sind Dokumentation L Ungeschickt geschnittene Packages können später hinderlich sein L Refactoring über Packagegrenzen hinweg ist aufwendiger Resultierender Kontext: Vor- und Nachteile sind wichtiger Bestandteil, Grenzen etc. Alternative: innere Klassen (engere Koppelung, kleinerer Scope)

11 Package Local Class Problem: Wenn potentiell jede Klasse eines Encapsulating Package von außen verwendet wird, erhöht das die Komplexität. Lösung: Definiere explizit ein öffentliches Interface und reduziere die Sichtbarkeit aller übrigen Klassen auf Default Visibility. Navigation von Encapsulating Package hierher  Zusammenhang Prinzip der minimalen Sichtbarkeit Zugänglich für Junit-Tests Analogie: Facade

12 Package Local Method Problem: Bei manchen Klassen gehört nur ein Teil der Methoden zum öffentlichen Interface eines Encapsulating Package. Lösung: Setze die übrigen Methoden auf Default Visibility. Pattern > Sprachmittel Idiomatische Verwendung Private: Testbarkeit—

13 Package Local Constructor
Problem: Wie kann ein Encapsulating Package die Erzeugung von Objekten eines Typs kontrollieren? Lösung: Gib dem entsprechenden Konstruktor – bzw. allen – Default Visibility. Auch create-Methoden Mächtiges Konzept Wichtige Ergänzung zu Encapsulating Package

14 Package Handle Problem: Ein Encapsulating Package benötigt als Ganzes (nichtstatischen) Zustand. Lösung: Definiere eine Klasse, die als Handle auf den Zustand dient. Deren Instanzen dienen Clients als Referenz auf Package-Instanzen und typischen Ausgangspunkt der Navigation darin. Ein Objekt als Zugriffspunkt in das Package  Zustand der „Komponente“ Handle kann „extern“ sein (javax.swing.table)  Package Local Method *

15 Verbindung der Patterns zu einer Sprache
Encapsulating Package Package Local Class Package Handle Pattern-Diagramm Notation erklären Vorteil: explizite Namen Einstiegspunkt Pfeile erklären Bisher primär Einschränkung der Sichtbarkeit = „Verbote“ für Clients. Ziel der Patterns: nicht „verbieten“, sondern dokumentieren  mit XP verträglich Package Local Constructor Package Local Method

16 Übersicht Patterns und Pattern-Sprachen
Packages als Kapselungs-Einheiten  Patterns zur Gestaltung der Package-Schnittstelle Beziehungen zwischen Packages Diskussion

17 Value Based Programming
Wertsemantik: Zustand spielt zentrale Rolle, Identität ist unwichtig In Schnittstellen von Packages herrscht oft Bedarf an spezifischen Typen mit Wertsemantik, z.B. Geschlecht und Körpertemperatur in einem medizinischen System. Java unterstützt nicht direkt die Definition eigener Typen mit Wertsemantik; primitive Typen und „Konstanten-Interfaces“ sind schlechter Ersatz

18 Value Class Problem: Wie lassen sich neue Typen mit Wertsemantik definieren? Lösung: Definiere Klassen, in denen die wertbezogenen Methoden von Object überschrieben sind. Mache die Klasse entweder unveränderlich oder implementiere Mechanismen zum einfachen kopieren.  Einstieg in andere Patternsprache

19 Value Class: Beispiel public class Temperatur {
private final float _gradCelsius; public Temperatur (final float gradCelsius) { _gradCelsius = gradCelsius; } public float getGradCelsius () {return _gradCelsius;} public boolean equals (final Object obj) { if (! (obj instanceof Temperatur)) return false; return (((Temperatur)obj)._gradCelsius == _gradCelsius); public int hashCode () {return new Float (_gradCelsius).hashCode();}

20 Homogeneous Exception
Problem: Geworfene Exceptions sind Teil der Schnittstelle eines Encapsulating Package Intern auftretende Exceptions können oft nicht lokal behandelt werden Einfache Propagation offenbart Implementierungsdetails, koppelt Clients an Interna Viele verschiedene Exceptions im Interface erschweren das Fangen und die Behandlung  try {...} catch (A a) {...} catch (B b) {...} catch (C c) {...} ...

21 Homogeneous Exception (2)
Lösung: Definiere eine einzige Exception, in die alle auftretenden Exceptions konvertiert werden. Methoden des öffentlichen Interface deklarieren typischerweise nur diese Exception. Eine Differenzierung kann über Unterklassen oder über Zustand der Exception erfolgen, je nach dem erwarteten Muster der Behandlung Information über die ursprüngliche Exception (insbesondere der Stacktrace) wird durch Logging oder Wrapping bewahrt  Einstieg in andere Pattern-Sprache

22 Zwischenstand Pattern-Sprache
Encapsulating Package Value Class Package Local Class Package Handle Package Local Method Homogeneous Exception Package Local Constructor

23 Übersicht Patterns und Pattern-Sprachen
Packages als Kapselungs-Einheiten Patterns zur Gestaltung der Package-Schnittstelle  Beziehungen zwischen Packages Diskussion

24 Facade Package Problem: Ein Encapsulating Package kann so sehr wachsen, daß sein öffentliches Interface unübersichtlich wird.

25 Facade Package (2) Lösung: Lagere seltener von Clients benötigte Funktionalität in andere Packages aus. Das ursprüngliche Package fungiert dann als Facade für die anderen.

26 Facade Package (3) J Es gibt ein schmaleres Interface, das meist genügt J Wenn ein Client das urprüngliche, breitere Interface braucht, steht es ihm zur Verfügung J Die internen Klassen sind besser organisiert, ihre Beziehungen werden dadurch dokumentiert L Manchmal ist nicht offensichtlich, in welchem Package eine spezielle Klasse ist: Man muß suchen L Es gibt mehr Packages, die Gesamtkomplexität steigt leicht

27 Interface Package Problem: Wie definiert man austauschbare Implementierungen von Encapsulating Packages, die Clients polymorph verwenden können? ?

28 Interface Package (2) Lösung: Definiere ein Interface-Package, das die gemeinsame Schnittstelle enthält. Diese Schnittstelle enthält alle spezifischen Parametertypen und Exceptions. Eine Factory instanziiert die gewünschte Implementierung und liefert einen Package Handle auf sie. Packages nicht hierarchisch: Achtung: die Implementierungen sind public  Downcast ist möglich Factory im Interface Package  leicht zyklische Abhängigkeit der Packages JDBC Oracle: weicht die Kapselung auf <<extend>> <<extend>> * * <<create>> <<create>> Factory

29 Interface Package (3) J Es gibt ein sehr wohldefiniertes Interface
J sehr große Flexibilität J Austauschbarkeit der Implementierungen (sogar zur Laufzeit) J Einzelne Implementierungen können selektiv die Kapselung durchbrechen (z.B. Oracle-JDBC) L Deutlich höhere Komplexität, sowohl für Implementierung als auch für Client L Interface ist sehr aufwendig zu ändern

30 Factories in Java Verschiedene Arten, Objekte zu erzeugen Konstruktor
fest verdrahtete statische create-Methode Factory Factory, die Reflection verwendet ... Work in progress.

31 Die Pattern-Sprache Encapsulating Package Facade Package Interface
Value Class Package Local Class Package Handle Factory Package Local Method Homogeneous Exception Pattern-Diagramm; Notation rekapitulieren Farben erklären Noch einmal durch das Diagramm gehen Package Local Constructor

32 Fazit Kapselung mit Packages
Java-Packages erlauben die Kapselung von Systemteilen mit grober Granularität explizite Trennung von Schnittstelle und Implementierung Instanzen und nichtstatischer Zustand Polymorphie Keine Implementierungsvererbung...

33 Fazit Pattern-Sprache
J Viele kleine Patterns mit Beziehungen Das Diagramm gibt einen schnellen Überblick Die Sprache liefert verschiedene Blickwinkel auf das Gesamtproblem Alternativen und Varianten werden diskutiert Bewährte Design-Lösungen werden dokumentiert Navigation vom Einstiegspunkt her ist natürlich J Verweise auf andere Pattern-Sprachen Die einzelne Sprache ist nicht überfrachtet Man kann jede Sprache unabhängig von anderen nutzen Strukturierte Dokumentation der Entwurfsentscheidungen mit Begründung Abwägungen, Grenzen sind enthalten Pattern-Sprache  jeweils Hilfestellung für Folgeprobleme Gemeinsame Abstraktionen  Diskussion im Team Präzise Terminologie Vorteil: bewußte Designentscheidungen Jedes Pattern für sich ist relativ einfach. Das Ganze ist mehr als die Summe seiner Teile

34 Übersicht Patterns und Pattern-Sprachen
Packages als Kapselungs-Einheiten Patterns zur Gestaltung der Package-Schnittstelle Beziehungen zwischen Packages  Diskussion

35 Wert-basierte Programmierung nach [Henney2000]
Whole Value Value Class Enumeration Values Immutable Value Class Factory Method Cloneable Value Ist Stoff für eine eigene Pattern-Sprache Abgrenzen von Immutable Wrapper etc. (wird hier ausgespart) Mutable Companion


Herunterladen ppt "Ziel: Zuhörer mit hineinnehmen in pattern-basierten Entwurf"

Ähnliche Präsentationen


Google-Anzeigen