Entwurfsmuster – zusätzliche Informationen

Entwurfsmuster und aufstrebende Architektur

Ein Muster ist ein Entwurfsfragment, das dabei hilft, ein häufig auftretendes „Problem“ auf standardisierte Weise zu lösen. Eine gute Musterbeschreibung beginnt mit der „Absicht“: eine kurze Beschreibung des Problems und der Art und Weise, wie das Muster eine Lösung darstellt. Die angesprochenen Probleme hängen oft mit unerwünschten Abhängigkeiten zwischen Code-Modulen zusammen. Daher kann die Anwendung von Entwurfsmustern dazu beitragen, Software modularer zu gestalten und dadurch ihre nicht-funktionalen Eigenschaften zu realisieren. Der Schwerpunkt bei der Anwendung von Mustern liegt auf der Struktur der Software und nicht auf der implementierten Funktionalität. Es gibt ein bekanntes Zitat von Grady Booch, einer Person, die maßgeblich an der Verbreitung objektorientierter Techniken beteiligt war: „Alle gut strukturierten objektorientierten Architekturen sind voller Muster.“ Es drückt die Verbindung zwischen Entwurfsmustern und Softwarearchitektur aus. Genau darum geht es in der 4-tägigen Schulung.

Der Kurs behandelt die Muster, die von der „Gang of Four“, den Vätern des Entwurfsmusteransatzes in der Softwareentwicklung, entwickelt wurden. Es mag überflüssig erscheinen, alle ihre 23 Muster zu besprechen, aber sie bilden einen übersichtlichen Werkzeugkasten, aus dem die richtige Mischung zur Erfüllung der nicht-funktionalen Eigenschaften der Software gewonnen werden kann.

Der Kurs wird den Ansatz anhand von nicht-trivialen Fallstudien und praktischen Übungen veranschaulichen. Zum Beispiel wird das Composite Pattern für Erweiterbarkeit und Wiederverwendung, der Observer für Skalierbarkeit und der Decorator für Erweiterbarkeit und Flexibilität eingesetzt. Schließlich kann die Kombination von Composite und Observer die Cash-Kohärenz mit einem Hintergrund implementieren.

Voraussetzungen

Dieser Kurs ist die natürliche Fortsetzung des Kurses‚Objektorientierte Analyse und Design‚ (OOAD). Er baut auf den dort vorgestellten Ideen auf, und es wird dringend empfohlen, zuerst den OOAD-Kurs zu besuchen. Ein solider Hintergrund in objektorientiertem Softwaredesign durch andere Schulungen oder durch die tägliche Praxis kann ebenfalls ausreichend sein.

Beispiel 1

In einer der Fallstudien erhalten Sie eine wiederverwendbare Komponente, die eine Reihe von Problemen bei der Softwareentwicklung veranschaulicht. Wenn eine Softwarekomponente weiterentwickelt wird, ist es sehr wichtig, dass „alter“ Client-Code, der gegen die Komponente geschrieben wurde, unverändert funktioniert. Eine solche sich entwickelnde Komponente soll abwärtskompatibel bleiben. Viele Leute haben den Eindruck, dass man einer Schnittstelle Funktionen als Haken für spätere Erweiterungen hinzufügen sollte. Dies ist nicht empfehlenswert. Vielmehr sollte man die angebotene Funktionalität auf das erforderliche Minimum beschränken. Die Kompatibilität des Client-Codes zu erhalten ist einfach, wenn die Schnittstelle erweitert wird, aber schier unmöglich, wenn die Schnittstelle verkleinert wird. Andererseits wird die Kompatibilität erheblich verbessert, wenn einige einfache syntaktische Regeln mit Mustern durchgesetzt werden. Durch die Anwendung solcher Regeln kann man die Entwicklung der wiederverwendbaren Komponente vom Client-Code entkoppeln. Dies ist nicht nur für die Bereitstellung von wiederverwendbaren Frameworks wichtig, die an einen großen Kundenstamm ausgeliefert werden, sondern auch für die Erstellung neuer Versionen von Komponenten in einem größeren dedizierten Softwaresystem. In der Praxis sieht man, dass bei der Erweiterung der Funktionalität einer Komponente eine Menge anderer Komponenten umkippen.

Beispiel 2

Das Beobachtermuster kann eine wichtige Rolle in der Softwarearchitektur spielen. Es ist die objektorientierte Variante des „Call-Back“-Mechanismus. Wie der „Rückruf“ kehrt es die Abhängigkeit vom Aufrufenden zum Aufgerufenen um. Wenn wir also zwei Komponenten haben, die sich gegenseitig aufrufen, entfernen wir eine der daraus resultierenden Abhängigkeiten. Die Möglichkeit, die Abhängigkeiten zu gestalten, ist großartig, aber gegenseitige Operationsaufrufe können zu einem weiteren Problem führen: Deadlock. Wenn die Objekte, die die Aufrufe ausführen, sperrbar sind, besteht die Möglichkeit eines zyklischen Wartens und eines Deadlocks. Dieses Problem wird im Zusammenhang mit dem Beobachtermuster ausführlich erörtert. Es werden einige konkret spezifizierte Regeln vorgestellt, die Deadlocks durch Design verhindern können. Für jeden, der nebenläufige OO-Programme entwickelt, ist dies ein Muss.