Design Patterns – schneller und sicherer programmieren
IONOS Redaktion6 mins
Jedes Design hat sein Pattern, alles eine Vorlage: Sei es eine Tasse, ein Wohnhaus oder ein Kleid. Niemand würde auf die Idee kommen, die Henkel einer Tasse innen anzubringen – mal abgesehen von Scherzartikel-Herstellern. Es hat sich für die praktische Nutzung einfach bewährt, dass diese Bestandteile außen angebracht sind. Wenn Sie einen Töpferkurs besuchen und einen Henkeltopf töpfern möchten, ist Ihnen die grundsätzliche Form schon bekannt, sie ist sozusagen als Entwurfsmuster in Ihrem Kopf hinterlegt.
Ähnlich verhält es sich mit Computerprogrammen. Bestimmte Abläufe wiederholen sich immer wieder, sodass es nur ein kleiner Schritt zu der Idee war, auch hier so etwas wie Schnittmusterbögen anzulegen. Wie diese Design Patterns genannten Entwurfsmuster die Programmierarbeit erleichtern können, erfahren Sie in unserem Ratgeber.
Was sind Design Patterns?
Der Begriff „Design Pattern“ geht ursprünglich auf den US-amerikanischen Architekten Christopher Alexander zurück, der wiederverwendbare Vorlagen als eine Sammlung erstellt hatte. Seine Absicht bestand darin, künftige Nutzer von Bauten in den Entwurfsprozess einzubinden. Diesen Gedanken griffen dann verschiedene Informatiker auf. Die sogenannte Gang of Four (GoF) – Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides – verhalf den Software Patterns mit ihrem Buch „Design Patterns – Elements of Reusable Object-Oriented Software“ im Jahr 1994 zum Durchbruch.
Worum ging es also? Um das eingangs zitierte Beispiel aufzugreifen: Für jede Tasse werden immer wieder die gleichen Grundelemente benötigt: Boden, Wand und Henkel – egal ob es eine Kaffee-, Espresso- oder Teetasse werden soll. Ganz ähnlich verhält es sich beim Programmieren: Zu durchlaufende Schleifen sind immer an Start- und Endvorgaben geknüpft; eine Bedingung erfordert immer eine Entscheidung, was bei Übereinstimmung und was bei Nichtübereinstimmung passiert; eine Berechnung gibt stets das Ergebnis der Kombination von Variablen aus usw. Aus vielen einzelnen Programmierschritten entsteht ein Programmablauf, der für bestimmte Aufgaben immer die gleichen Züge trägt. Entwurfsmuster sind eine Beschreibung, wie ein Problem zu lösen ist.
Im Folgenden ein ganz einfaches Beispiel für ein Software Pattern, hier ein Factory Pattern:
class Tassen
{
private $tasseMake;
private $tasseModel;
public function __construct($make, $model)
{
$this->tasseMake = $make;
$this->tasseModel = $model;
}
public function getMakeAndModel()
{
return $this->tasseMake . ' ' . $this->tasseModel;
}
}
class TassenFabrik
{
public static function create($make, $model)
{
return new Tasse($make, $model);
}
}
$espresso = TassenFabrik::create('Tasse', 'Espresso'); // Objekt ist hergestellt
print_r($espresso->getMakeAndModel()); // Ausgabe "Tasse Espresso"Gleiches gilt für größere Zusammenhänge und Abläufe, die immer wieder eingesetzt werden, um bestimmte Aufgaben in Programmabläufen zu lösen. Das Code-Beispiel lässt sich beliebig erweitern, auch auf andere Branchen, völlig andere Produkte und andere Abläufe. Und es ist natürlich nur ein Baustein in einer umfangreicheren Software. Somit sind Entwurfsmuster als Schemata zu verstehen, die sich bereits in der Praxis bewährt haben.
Welche Arten von Design Patterns gibt es?
Die Arten der Entwurfsmuster repräsentieren die grundsätzlichen Einsatzgebiete der darin jeweils versammelten Software Patterns.
Strukturmuster
Die Structural Patterns sind vorgefertigte Schablonen für Beziehungen zwischen Klassen. Dabei wird eine Abstraktion angestrebt, die auch mit anderen Lösungsansätzen kommunizieren kann – Stichwort Schnittstellen-Programmierung.
Verhaltensmuster
Mit den Behavioral Patterns wird das Verhalten der Software modelliert. Diese Patterns vereinfachen komplexe Prozesse zur Steuerung und Kontrolle. Dazu kann zwischen Algorithmen und den Verantwortlichkeiten der Objekte gewählt werden.
Erzeugungsmuster
Mit den Creational Patterns werden Objekte erzeugt, durch die eine vereinfachte Prozessdarstellung für bestimmte Instanzen möglich wird. Dies funktioniert unabhängig davon, auf welche Weise einzelne Objekte in einer Software erstellt und dargestellt werden.
Im Lauf der Zeit kamen noch weitere Entwurfsmuster-Arten dazu, die in keine der drei eben genannten Kategorien passen. Dazu gehören Muster für die objektrelationale Abbildung, um Objekte und deren Beziehungen in einer relationalen Datenbank abzulegen.
Licht und Schatten bei der Nutzung von Design Patterns
Vorteile
Die Möglichkeit, auf bewährte Lösungsansätze zurückzugreifen, geht mit einer Zeit- und Kostenersparnis einher. Entwicklerteams müssen nicht ständig das Rad neu erfinden, um eine bereits vielfach gelöste Teilaufgabe in einem neuen Programmablauf zu lösen. Die einzelnen Muster tragen in der Regel Namen aus einem gemeinsamen Entwurfsvokabular, und das vereinfacht sowohl die Diskussion der Entwickler untereinander als auch die Kommunikation mit dem Nutzer der künftigen Lösung. Auch die Dokumentation einer Software wird vereinfacht, wenn bereits dokumentierte Bausteine verwendet werden. Diese Vorteile greifen dann auch bei der Wartung und Weiterentwicklung eines Programms.
Nachteile
Der Umgang mit Entwurfsmustern setzt sehr umfangreiches Wissen voraus. Die Verfügbarkeit von Design Patterns kann auch zu der Auffassung verführen, dass mit vorliegenden Entwurfsmustern scheinbar alle Probleme gelöst werden können. Kurz gesagt: die Kreativität kann eingeschränkt werden, die Neugier darauf, neue (bessere) Lösungsansätze zu finden.
Welche bekannten Design Patterns gibt es?
Es existieren mehr als siebzig Entwurfsmuster, die den verschiedenen Kategorien zugeordnet sind. Wichtige Software Patterns sind beispielsweise (Fettdruck in der Erklärung = deutsche Entsprechung):
Erzeugungsmuster
- Builder Pattern: Der Erbauer aus der Kategorie der Erzeugungsmuster trennt die Entwicklung von (komplexen) Objekten von deren Repräsentationen.
- Factory Pattern: Die Fabrikmethode erzeugt als Erzeugungsmuster ein Objekt durch den Aufruf einer Methode und statt durch den eines Konstruktors.
- Singleton Pattern: Das Einzelstück sorgt als Erzeugungsmuster dafür, dass von einer Klasse nur genau ein Objekt existiert. Darüber hinaus ist ein Singleton global verfügbar.
Strukturmuster
- Composite Pattern: Ein zusammengesetztes Strukturmuster, auf Deutsch Kompositum, das speziell auf den Umgang mit dynamischen Strukturen ausgerichtet ist, z. B. zur Dateiorganisation oder Datenkompression.
- Decorator Pattern: Der sogenannte Dekorierer integriert in bestehende Klassen weitere Funktionalitäten oder Zuständigkeiten.
- Facade Pattern: Die Fassade stellt eine Schnittstelle zu anderen (Unter- bzw. Sub-)Systemen dar.
Verhaltensmuster
- Observer Pattern: Der Beobachter reicht Änderungen an einem Objekt an Strukturen weiter, die vom Ursprungsobjekt abhängen.
- Strategy Pattern: Die Strategie definiert eine Familie von austauschbaren Algorithmen.
- Visitor Pattern: Der Besucher kapselt ausführbare Operationen so ab, dass neue Operationen ohne Veränderung der betroffenen Klassen vorgenommen werden.
Mit Design Patterns stehen vorgefertigte Muster zur Verfügung, mit denen ein explizites Problem gelöst wird, indem man auf ein bewährtes Konzept zurückgreift. Das Muster baut dabei auf real existierenden Software-Designs auf und bindet den Nutzer einer künftigen Lösung in den Entwurfsprozess mit ein. Dabei sind Entwurfsmuster erst einmal nicht an eine Programmiersprache gebunden. Das macht sie universell einsetzbar.
