Ein Entwurfsmuster (Design Pattern) stellt eine Lösung für ein wiederkehrendes Problem dar. Die Suche nach dem passenden Entwurfsmuster gestaltet sich jedoch oft ebenfalls als wiederkehrendes Problem. Es sind Dutzende von Entwurfsmustern definiert, so dass man meinen könnte, dass jedes Problem abgedeckt sein müsste. Aber ist das auch so? Nun, um meine Auswahl für das passende Entwurfsmuster zu erleichtern, habe ich sie in drei Gruppen unterteilt:
1. Die erzeugungsabhängigen Entwurfsmuster – wenn ich möchte, dass das Erzeugen und Verwenden von Objekten vom tatsächlichen Prozess getrennt ist, dann greife ich zum „Singleton“, „Factory“, „Abstract Factory“ und „Builder“.
2. Die strukturabhängigen Entwurfsmuster – wenn ich eine Schnittstelle für ein Sub-System erstelle, eine Schnittstelle zum Verbindungsaufbau verwende, die das aktuelle System nicht beinhaltet oder anbietet, oder eine flexible Speicher-Schnittstelle für Hinzufügen und Bearbeiten von Objekten benötige, dann greife ich zum „Adapter“, „Bridge“, „Composite“ und „Facade“.
3. Die verhaltensgesteuerten Entwurfsmuster – wenn ich vorhabe den Zugriff auf die Objekte zu kontrollieren oder beeinflussen oder bestimmte Operationen auf ihnen auszuführen und in irgendeiner Weise mit ihnen zu interagieren, dann greife ich zum „Command“, „Iterator“, „Observer“, „Strategy“ und „Visitor“.
Beim Erstellen einer Software-Lösung darf der Einsatz von Entwurfsmustern aber auch nicht überbewertet werden. Nicht für jede Aufgabenstellung oder Problematik ist bereits ein geeignetes Entwurfsmuster vorhanden. Die Kunst dabei besteht also darin, verschiedene Lösungsmodelle so zu kombinieren, dass diese einen maximalen Nutzen für das Applikationsdesign bedeuten. Dabei kann es auch notwendig sein, verschiedene Entwurfsmuster in einer Weise zu kombinieren, dass die Nachteile des einen durch die Vorteile des anderen aufgewogen werden.
Ist man aber an einem Punkt angekommen, wo man gar nicht genau weiß, für welches Entwurfsmuster man sich entscheiden soll oder einfach keins der zahlreichen Entwurfsmuster zu der Aufgabenstellung zupassen scheint, dann liegt eben kein wiederkehrendes Problem, sondern ein seltenes oder ein einmaliges Problem vor. In so einem Fall ist es ratsam, sich mit einem oder zwei Arbeitskollegen aus dem Team zusammenzusetzen (was man ohnehin öfter machen sollte) um eine passende und individuelle Lösung austüfteln.
Die oben vorgeschlagene Gruppierung der Entwurfsmuster soll nur eine Hilfestellung bei der Entscheidung zum passenden gängigen Entwurfsmuster dienen. Wenn ihr andere Ansätze habt oder meine Aufstellung ergänzen möchtet, dann fühlt euch frei, mir zu schreiben. Ich würde mich sehr über andere Erkenntnisse freuen!
Ein Glück das uns die ganzen Pattern-Sammlungen alles schon schön vorsortieren ;-)
hmmm…vielleicht könnte mal einer eine art „pattern-finder-tool“ dafür erstellen…also, man gibt an was man an kriterien hat und der „pattern-finder“ schläg einen mögliche patterns vor…cool wa?
Hallo.
Ich mochte mit Ihrer Website krsteski.de Links tauschen
Hmm, „Deine“ Aufteilung erinnert mich stark an die von Wikipedia. Wobei 1) dort _erzeugende Muster_ genannt ist, was auch viel sinnvoller ist. Sie sind nicht abhängig von ihrer Erzeugung, sie bestimmen den Instanziierungsprozess von Objekten.
Genau betrachtet gilt das auch für 2) und 3)
2) ist nicht abhängig von er Struktur, sondern bestimmt diese.
3) ist nicht verhaltensgesteuert, sondern -steuernd. Das ist ein Unterschied.
Eigentlich kommt Patterns immer eine aktive Rolle zu.
Es geht ja bei Entwurfsmustern nicht darum, jede Aufgabe in bestimmte Muster zu pressen, sondern immer wieder verwendete Muster zu benennen und kombinieren zu können. ;-)