Pattern Driven Development ist keine Lösung

Veröffentlicht: 30. Dezember 2010 von Christian Raschka in Uncategorized

„A pattern addresses a recurring design problem that arises in specific design
situations, and presents a solution to it.“ (Aus Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M. (1996) A
System of Patterns. John Wiley & Sons.)

Hm… ein Pattern soll uns helfen ein Problem zu lösen. Die Frage ist nur welches? Und woran erkenne ich, wenn ich denn eins habe, welches Pattern mir dabei hilft es zu lösen? Diese Fragen sind scheinbar nicht einfach zu beantworten, anders kann ich es mir nicht erklären, warum es so viel Literatur über Antipatterns gibt. Viele vermeintlich gute Muster werden sehr schnell zu Problemstellen ganzer Softwarebausteine. Denn leider gibt es in den seltensten Fällen eine optimale Lösung. Alle Lösungen (und auch die meisten Patterns) beinhalten „Kosten“. Diese werden zwar bei sinnvoller Anwendung der Muster meist durch die Vorteile aufgehoben. Doch ob und wann dieser Zustand eintritt ist nicht bekannt.

Was also passiert ist folgendes: Man nimmt sich eine Liste von „Best-Practices„, nennen wir diese in diesem Fall „Pattern-Katalog“. Wenn ich nun nach diesen Mustern entwickle kann mir doch eigentlich nichts passieren, oder doch? Leider eben schon. Und ich meine dabei nicht einmal nur das Singleton-Pattern. Viele der Lösungen sind möglicherweise zu kompliziert oder führen Abhängigkeiten ein, die es ohne Anwendung des Pattern gar nicht gegeben hätte.

Um dies zu untersuchen, hatten wir folgende Idee: Wir machen „Brain-Driven-Development“. Anstatt irgendwelche Probleme zu suchen, die dann mittels Pattern gelöst werden können, verwenden wir unseren Verstand. Zugegebenermaßen klingt dies etwas provozierend aber ich möchte erläutern, was ich damit meine.

Wir wollen eine Software erstellen, die ein bestimmtes Problem löst und dazu eine grafische Benutzeroberfläche bereitstellt. Die meisten würden an dieser Stelle wohl sehr schnell in den Raum schreien, wir brauchen dazu MVC (oder MVP, MVVM …). Aber wie kann ich das an dieser Stelle schon wissen? Die Anforderung war noch gar nicht so weit, um zu wissen, dass dies notwendig ist.

Wie wäre denn mein folgender Vorschlag: Wir lassen mal außen vor, was wir über (GUI-) Patterns wissen. Nur kurz. Und dann fangen wir an. Wir erstellen uns Schnittstellen der Aufgaben, die die GUI später anzeigen soll. Wie diese zu implementieren sind, ist uns an dieser Stelle egal. Und dann entwerfen wir die GUI. Möglicherweise brauchen wir Dummyimplementierungen der Schnittstellen damit wir vernünftig arbeiten können, aber das sollte ja kein Problem sein. Und wenn wir fertig sind, fangen wir an die Implementierung dieser Schnittstellen zu modellieren…

Was haben wir damit erreicht? Eine Trennung von Anzeigelogik und Geschäftslogik? Jawohl. Also ja doch MVC? Nein, denn es wird wahrscheinlich keine Klasse geben, die Controller heißt. Aber vielleicht ja doch. Und eventuell stellt sich hinterher heraus, dass eine Klasse die Aufgabe eines Presenters erfüllt, dann nenne ich diese um, damit andere dies auch erkennen. Und dann kommt auch der volle Nutzen von Patterns zum Tragen.

Wer also gut Software erstellen möchte, sollte nicht auf Teufel komm raus versuchen Patterns anzuwenden. Lieber sollte man versuchen, seinen Verstand einzusetzen und dann möglicherweise auch Patterns.

Advertisements
Kommentare
  1. „Pattern happy“ ist ein typisches Antimuster 🙂 Wobei es schon Sinn macht zwischen Entwurfsmustern (Singelton) u. Architekturmustern (MVP/MVC) zu trennen. Einen overuse von Architekturmustern habe ich eigentlich noch nicht gesehen. „Pattern happy“ scheint mir eher eine typische „jemand hat sich ein Pattern Buch gekauft“ Sache zu sein. Im Gegensatz zu Entwurfsmustern lassen sich Architekturmuster auch kaum eins zu eins irgendwoher übernehmen, sie müssen immer irgendwie immer an eine Technologie oder eine Architektur angepasst werden.

    • craschka sagt:

      Ich sehe (diesbezüglich) keinen Unterschied zwischen Entwurfsmustern und Architekturmustern. Gerade wenn ich mir zum Beispiel Schichtenarchitektur oder Domain-Driven-Design anschaue. Auch hier habe ich das Gefühl, dass „Pattern happy“ wie Du es beschreibst als „jemand hat sich ein […] Buch gekauft“ sehr oft vorkommt. Es wird versucht DDD (oder Teile davon) zu betreiben, ohne dass der Mehraufwand gerechtfertigt ist (d.h. genug Vorteile bringt.)

      Schichten zum Beispiel ergeben sich möglicherweise ganz von selbst („Brain-Driven“) oder eben nicht.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s