Patterns in der Softwareentwicklung: nicht isoliert, sondern in Beziehung

Inhaltsverzeichnis

In der modernen Softwareentwicklung spielen Patterns als wichtige Abstraktion eine zentrale Rolle bei der Architektur von Anwendungen. Standardwerke zu diesem Thema wie "Design Patterns: Elements of Reusable Object-Oriented Software" und "Pattern-Oriented Software Architecture, Volume 5 (POSA 5) geben Entwicklerinnen und Entwicklern Hilfestellung beim Einsatz der Patterns und wichtige Hinweise zu deren Beziehungen untereinander.

Modernes C++ – Rainer Grimm

Rainer Grimm ist seit vielen Jahren als Softwarearchitekt, Team- und Schulungsleiter tätig. Er schreibt gerne Artikel zu den Programmiersprachen C++, Python und Haskell, spricht aber auch gerne und häufig auf Fachkonferenzen. Auf seinem Blog Modernes C++ beschäftigt er sich intensiv mit seiner Leidenschaft C++.

Muster leben nicht in Isolation, sondern stehen zueinander in Beziehung. Sie können entweder im Gegensatz zueinander stehen oder sich ergänzen. Die Beziehung kann aber auch der Gestalt sein, dass die Muster eine typische Abfolge bilden. Darüber hinaus gibt es Repositories von Mustern oder sogar Mustersprachen. Es lohnt sich, einen genaueren Blick auf die Beziehungen von Mustern zu werfen.

Die Begriffe Entwurfsmuster, Algorithmus und Framework haben einiges gemeinsam. Was genau, möchte ich näher beleuchten.

Entwurfsmuster, Algorithmen und Frameworks

Bevor ich auf die Unterschiede und Gemeinsamkeiten der drei Begriffe eingehe, möchte ich sie in den folgenden Zeilen kurz und bündig definieren:

• Entwurfsmuster: "Each pattern is a three part rule, which expresses a relation between a certain context, a problem, and a solution." (Christopher Alexander)

• Algorithmus: "In mathematics and computer science, an algorithm is a finite sequence of rigorous instructions, typically used to solve a class of specific problems or to perform computation." (Algorithm)

• Framework: "In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software." (Software-Framework)

Nun lohnt sich ein tieferer Blick in die Zusammenhänge.

Entwurfsmuster versus Algorithmen

Basierend auf der Definition ist ein Algorithmus eine endliche Abfolge von Schritten, um ein bestimmtes Problem zu lösen. Hingegen ist ein Entwurfsmuster eine allgemeine Lösung für ein Problem in einem bestimmten Kontext.

Design Patterns versus Frameworks

Zunächst basiert ein Framework auf dem Hollywood-Prinzip ("Rufen Sie nicht uns an, wir rufen Sie an"). Das Hollywood-Prinzip bedeutet, dass der Kontrollfluss vom Framework diktiert wird, aber nicht vom Aufrufer. Damit unterscheidet sich ein Framework von einer Bibliothek. Das Framework stellt eine Minimalanwendung bereit, die vom Nutzer nur durch das Überschreiben bestimmter Methoden erweitert werden kann.

Zum Abschluss noch die Unterscheidung von Entwurfsmuster und Frameworks aus dem Buch "Design Patterns: Elements of Reusable Object-Oriented Software" (Design Patterns):

Because patterns and frameworks have some similarities, people often wonder how or even if they differ. They are different in three major ways:

1. Design patterns are more abstract than frameworks. Frameworks can be embodied in code, but only examples of patterns can be embodied in code. A strength of frameworks is that they can be written down in programming languages and not only studied but executed and reused directly. In contrast, the design patterns in this book have to be implemented each time they're used. Design patterns also explain the intent, trade-offs, and consequences of a design.
2. Design patterns are smaller architectural elements than frameworks. A typical framework contains several design patterns, but the reverse is never true.
3. Design patterns are less specialized than frameworks. Frameworks always have a particular application domain. A graphical editor framework might be used in a factory simulation, but it won't be mistaken for a simulation framework. In contrast, the design patterns in this catalog can be used in nearly any kind of application. While more specialized design patterns than ours are certainly possible (say, design patterns for distributed systems or concurrent programming), even these wouldn't dictate an application architecture like a framework would.

Die folgenden eher theoretischen Überlegungen zu den Beziehungen von Mustern basieren auf dem Buch "Pattern-Oriented Software Architecture, Volume 5 (POSA 5). Die Autoren des Buches sind Frank Buschmann, Kevlin Henny und Douglas C. Schmidt.

Pattern-Beziehungen

Patterns sind keine Inseln. Sie stehen oft in Beziehung zueinander und es gibt verschiedene Möglichkeiten, ihre Beziehungen zu beschreiben.

Pattern Complements

Muster ergänzen sich gerne. Ein Muster vervollständigt den Entwurfsprozess, der mit einem anderen Muster begonnen wurde. Zu Pattern Complements gehören auch Muster, die eine ähnliche Designaufgabe lösen.

Das Strategy Pattern und die Template Method sind Pattern Complements. Beide Pattern sind Verhaltensmuster aus dem klassischen Buch Design Patterns. Sie dienen einem ähnlichen Zweck: Variationen von Algorithmen sollen auf einheitliche Weise behandelt werden. Der Hauptunterschied besteht darin, dass das Strategiemuster seine Implementierung auf der Objektebene bereitstellt und Objektkomposition und Delegation verwendet; die Template-Methode stellt ihre Implementierung hingegen auf der Klassenebene bereit und basiert auf Virtualität.

Pattern Compounds

Oft bilden zusammengesetzte Muster ein neues Muster.

Ein typisches Beispiel für ein zusammengesetztes Muster ist das Architekturmuster Model View Controller (MVC). Das MVC in POSA 1 unterteilt die Programmlogik einer Benutzeroberfläche in die einzelnen Komponenten Model, View und Controller. Das Model verwaltet die Daten und Regeln der Anwendung. Die View stellt die Daten dar, und der Controller interagiert mit den Benutzerinnen und Benutzern.

Hier sind ein paar Muster aus dem Buch "Design Patterns", die im MVC verwendet werden:

• Die View beobachtet (Observer Pattern) das Modell auf Änderungen.
• Der Controller ist eine Strategie zur Bearbeitung von Benutzereingaben (Strategy Pattern).
• Views können Unteransichten haben und sind daher Bestandteile des Composite Pattern.

Pattern Sequences

Eine Mustersequenz ist eine typische Abfolge von Mustern, die bei einer anderen Designaufgabe angewendet werden kann. Beispielsweise wenn man über einen Baum iterieren und verschiedene Operationen wie show und count auf diesem ausführen möchte.

Dazu ist ein Iterator nötig, um den Baum zu traversieren (Iterator Pattern). Dabei gilt es zu unterscheiden, ob die Knoten Kinder haben oder nicht. Knoten, die Kinder haben, delegieren die Operationen an ihre Kinder. Knoten, die keine Kinder haben, führen sie selbst aus (Composite Pattern). Das Visitor Pattern kommt ins Spiel, um verschiedene Operationen im Baum zu unterstützen. Alle drei Muster werden gerne in Sequenz verwendet.

Pattern Collections

Eine Pattern Collection ist eine organisierte Verwaltung von Mustern.

Denn es gibt Tausende von Mustern und es ist notwendig, sie zu organisieren und letztlich zu finden.

Es gibt verschiedene Möglichkeiten, Muster zu organisieren. Sie lassen sich zum Beispiel nach ihrem Abstraktionslevel (Architekturmuster, Entwurfsmuster, Idiome), nach ihrer Domäne (Luftfahrt, Finanzwesen, Gesundheitswesen, ...) oder nach ihrer Intention gruppieren: Im Buch Design Patterns und den POSA-Büchern sind die Patterns nach ihrer Intention geordnet. Der folgende Absatz über Pattern Languages zeigt etwa die Gruppierung von POSA 4.

Pattern Language

Eine Pattern Language beschreibt einen vollständigen Satz von Mustern für einen bestimmten Bereich. Ihr Ziel ist es, jede Designherausforderung in diesem speziellen Bereich zu lösen. Das Buch Pattern-Oriented Software Architecture, Volume 4: A Pattern Language for Distributed Programming von Frank Buschmann, Kevlin Henney und Douglas C. Schmidt stellt eine solche Pattern Language vor. Das Buch präsentiert mehr als 120 Muster, die wie folgt gruppiert sind:

• From Mud to Structure
• Distributed Infrastructure
• Event Demultiplexing and Dispatching
• Interface Partitioning
• Component Partitioning
• Application Control
• Concurrency
• Synchronization
• Object Interaction
• Adaption and ExtensionModal Behavior
• Resource Management
• Database Access

Auf viele dieser Pattern werde ich in meinen nächsten Artikeln noch im Detail eingehen.

Wie geht's weiter?

Ein Anti-Pattern ist eine bewährte Methode, um sich sprichwörtlich selbst "in den Fuß zu schießen". Der Begriff Anti-Pattern wurde von Andrew Koenig geprägt und wird das Thema meines nächsten Beitrags über Patterns sein. (map)