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 an­zu­brin­gen – mal abgesehen von Scherz­ar­ti­kel-Her­stel­lern. Es hat sich für die prak­ti­sche Nutzung einfach bewährt, dass diese Be­stand­tei­le außen an­ge­bracht sind. Wenn Sie einen Töp­fer­kurs besuchen und einen Hen­kel­topf töpfern möchten, ist Ihnen die grund­sätz­li­che Form schon bekannt, sie ist sozusagen als Ent­wurfs­mus­ter in Ihrem Kopf hin­ter­legt.

Ähnlich verhält es sich mit Com­pu­ter­pro­gram­men. Bestimmte Abläufe wie­der­ho­len sich immer wieder, sodass es nur ein kleiner Schritt zu der Idee war, auch hier so etwas wie Schnitt­mus­ter­bö­gen anzulegen. Wie diese Design Patterns genannten Ent­wurfs­mus­ter die Pro­gram­mier­ar­beit er­leich­tern können, erfahren Sie in unserem Ratgeber.

Was sind Design Patterns?

Der Begriff „Design Pattern“ geht ur­sprüng­lich auf den US-ame­ri­ka­ni­schen Ar­chi­tek­ten Chris­to­pher Alexander zurück, der wie­der­ver­wend­ba­re Vorlagen als eine Sammlung erstellt hatte. Seine Absicht bestand darin, künftige Nutzer von Bauten in den Ent­wurfs­pro­zess ein­zu­bin­den. Diesen Gedanken griffen dann ver­schie­de­ne In­for­ma­ti­ker auf. Die so­ge­nann­te 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 Durch­bruch.

Worum ging es also? Um das eingangs zitierte Beispiel auf­zu­grei­fen: Für jede Tasse werden immer wieder die gleichen Grund­ele­men­te benötigt: Boden, Wand und Henkel – egal ob es eine Kaffee-, Espresso- oder Teetasse werden soll. Ganz ähnlich verhält es sich beim Pro­gram­mie­ren: Zu durch­lau­fen­de Schleifen sind immer an Start- und End­vor­ga­ben geknüpft; eine Bedingung erfordert immer eine Ent­schei­dung, was bei Über­ein­stim­mung und was bei Nicht­über­ein­stim­mung passiert; eine Be­rech­nung gibt stets das Ergebnis der Kom­bi­na­ti­on von Variablen aus usw. Aus vielen einzelnen Pro­gram­mier­schrit­ten entsteht ein Pro­gramm­ab­lauf, der für bestimmte Aufgaben immer die gleichen Züge trägt. Ent­wurfs­mus­ter sind eine Be­schrei­bung, 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 Zu­sam­men­hän­ge und Abläufe, die immer wieder ein­ge­setzt werden, um bestimmte Aufgaben in Pro­gramm­ab­läu­fen 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 um­fang­rei­che­ren Software. Somit sind Ent­wurfs­mus­ter als Schemata zu verstehen, die sich bereits in der Praxis bewährt haben.

Welche Arten von Design Patterns gibt es?

Die Arten der Ent­wurfs­mus­ter re­prä­sen­tie­ren die grund­sätz­li­chen Ein­satz­ge­bie­te der darin jeweils ver­sam­mel­ten Software Patterns.

Struk­tur­mus­ter

Die Struc­tu­ral Patterns sind vor­ge­fer­tig­te Scha­blo­nen für Be­zie­hun­gen zwischen Klassen. Dabei wird eine Abs­trak­ti­on an­ge­strebt, die auch mit anderen Lö­sungs­an­sät­zen kom­mu­ni­zie­ren kann – Stichwort Schnitt­stel­len-Pro­gram­mie­rung.

Ver­hal­tens­mus­ter

Mit den Be­ha­vi­oral Patterns wird das Verhalten der Software mo­del­liert. Diese Patterns ver­ein­fa­chen komplexe Prozesse zur Steuerung und Kontrolle. Dazu kann zwischen Al­go­rith­men und den Ver­ant­wort­lich­kei­ten der Objekte gewählt werden.

Er­zeu­gungs­mus­ter

Mit den Crea­tio­nal Patterns werden Objekte erzeugt, durch die eine ver­ein­fach­te Pro­zess­dar­stel­lung für bestimmte Instanzen möglich wird. Dies funk­tio­niert un­ab­hän­gig davon, auf welche Weise einzelne Objekte in einer Software erstellt und dar­ge­stellt werden.

Im Lauf der Zeit kamen noch weitere Ent­wurfs­mus­ter-Arten dazu, die in keine der drei eben genannten Ka­te­go­rien passen. Dazu gehören Muster für die ob­jekt­re­la­tio­na­le Abbildung, um Objekte und deren Be­zie­hun­gen in einer re­la­tio­na­len Datenbank abzulegen.

Licht und Schatten bei der Nutzung von Design Patterns

Vorteile

Die Mög­lich­keit, auf bewährte Lö­sungs­an­sät­ze zu­rück­zu­grei­fen, geht mit einer Zeit- und Kos­ten­er­spar­nis einher. Ent­wick­ler­teams müssen nicht ständig das Rad neu erfinden, um eine bereits vielfach gelöste Teil­auf­ga­be in einem neuen Pro­gramm­ab­lauf zu lösen. Die einzelnen Muster tragen in der Regel Namen aus einem ge­mein­sa­men Ent­wurfs­vo­ka­bu­lar, und das ver­ein­facht sowohl die Dis­kus­si­on der Ent­wick­ler un­ter­ein­an­der als auch die Kom­mu­ni­ka­ti­on mit dem Nutzer der künftigen Lösung. Auch die Do­ku­men­ta­ti­on einer Software wird ver­ein­facht, wenn bereits do­ku­men­tier­te Bausteine verwendet werden. Diese Vorteile greifen dann auch bei der Wartung und Wei­ter­ent­wick­lung eines Programms.

Nachteile

Der Umgang mit Ent­wurfs­mus­tern setzt sehr um­fang­rei­ches Wissen voraus. Die Ver­füg­bar­keit von Design Patterns kann auch zu der Auf­fas­sung verführen, dass mit vor­lie­gen­den Ent­wurfs­mus­tern scheinbar alle Probleme gelöst werden können. Kurz gesagt: die Krea­ti­vi­tät kann ein­ge­schränkt werden, die Neugier darauf, neue (bessere) Lö­sungs­an­sät­ze zu finden.

Welche bekannten Design Patterns gibt es?

Es exis­tie­ren mehr als siebzig Ent­wurfs­mus­ter, die den ver­schie­de­nen Ka­te­go­rien zu­ge­ord­net sind. Wichtige Software Patterns sind bei­spiels­wei­se (Fettdruck in der Erklärung = deutsche Ent­spre­chung):

Er­zeu­gungs­mus­ter

  • Builder Pattern: Der Erbauer aus der Kategorie der Er­zeu­gungs­mus­ter trennt die Ent­wick­lung von (komplexen) Objekten von deren Re­prä­sen­ta­tio­nen.
  • Factory Pattern: Die Fa­brik­me­tho­de erzeugt als Er­zeu­gungs­mus­ter ein Objekt durch den Aufruf einer Methode und statt durch den eines Kon­struk­tors.
  • Singleton Pattern: Das Ein­zel­stück sorgt als Er­zeu­gungs­mus­ter dafür, dass von einer Klasse nur genau ein Objekt existiert. Darüber hinaus ist ein Singleton global verfügbar.

Struk­tur­mus­ter

  • Composite Pattern: Ein zu­sam­men­ge­setz­tes Struk­tur­mus­ter, auf Deutsch Kom­po­si­tum, das speziell auf den Umgang mit dy­na­mi­schen Struk­tu­ren aus­ge­rich­tet ist, z. B. zur Da­tei­or­ga­ni­sa­ti­on oder Da­ten­kom­pres­si­on.
  • Decorator Pattern: Der so­ge­nann­te De­ko­rie­rer in­te­griert in be­stehen­de Klassen weitere Funk­tio­na­li­tä­ten oder Zu­stän­dig­kei­ten.
  • Facade Pattern: Die Fassade stellt eine Schnitt­stel­le zu anderen (Unter- bzw. Sub-)Systemen dar.

Ver­hal­tens­mus­ter

  • Observer Pattern: Der Be­ob­ach­ter reicht Än­de­run­gen an einem Objekt an Struk­tu­ren weiter, die vom Ur­sprungs­ob­jekt abhängen.
  • Strategy Pattern: Die Strategie definiert eine Familie von aus­tausch­ba­ren Al­go­rith­men.
  • Visitor Pattern: Der Besucher kapselt aus­führ­ba­re Ope­ra­tio­nen so ab, dass neue Ope­ra­tio­nen ohne Ver­än­de­rung der be­trof­fe­nen Klassen vor­ge­nom­men werden.
Fazit

Mit Design Patterns stehen vor­ge­fer­tig­te Muster zur Verfügung, mit denen ein ex­pli­zi­tes Problem gelöst wird, indem man auf ein bewährtes Konzept zu­rück­greift. Das Muster baut dabei auf real exis­tie­ren­den Software-Designs auf und bindet den Nutzer einer künftigen Lösung in den Ent­wurfs­pro­zess mit ein. Dabei sind Ent­wurfs­mus­ter erst einmal nicht an eine Pro­gram­mier­spra­che gebunden. Das macht sie uni­ver­sell ein­setz­bar.

Zum Hauptmenü