Design Pattern: Welche benutzt Ihr?

Hallo,

ich beginne damit mich mit Desing-Pattern zu beschäftigen und sie anzuwenden.
Bisher habe ich schon das Fabrik-Muster angewendet.

Mich würde mal interessieren, welche Design-Pattern Ihr in der Praxis schon verwendet habt? Mit welchen Pattern sollte man sich als Einsteiger zuerst intensiv beschäftigen?

Viele Grüße

Hallo,

Design-Patterns sollte und kann man am besten dann einsetzen wenn man sie braucht. Am Anfang ist es sicherlich schwer zu sehen, wann man gewisse Softwareteile mit Design-Patterns flexibler und eleganter lösen kann.
Es gibt dafür die klassischen Gang of Four Muster, wie zum Beispiel Singleton, Factory, State, usw...

Dann gibt es gerade im .NET Bereich Pattern, wo es Sinn macht sie immer anzuwenden. Also zum Beispiel das MVVM Muster bei einer WPF Applikation.

Wenn du Softwareeprojekte entwickelst, solltest du zuerst einfach OOP Prinzipien anwenden. Wenn deine Software einmal so weit ist, dass Sie funktioniert wie Sie soll, kannst du deinen Code reflektieren und sehen, wo du mit Design-Patterns besser bedient bist und deine Software flexibler und offener für Änderungen zu machen.

Lg

Der Trick dabei ist, dass man dazu die Patterns erst mal kennen muss. Ich würd mir eine Liste gängiger Patterns anschauen und verstehen wozu sie gut sind. Irgendwann kommt dir dann beim Entwickeln mal die Idee dass du jetzt eines verwenden könntest.
Aber ich kenne auch kaum welche muss ich zugeben.

Erstmal muss man alle Design Patterns kennen. Welche du dann anwenden kannst, kommt eigentlich mehr oder weniger von alleine, zumindest wenn du schon gewisse Erfahrung hast. Was ich häufiger mal anwende ist Singleton, Factory, Iterator, Interpreter, Proxy, Composition, Memento, Strategy, Interceptor...
Sowas wie MVVM würd ich eher zu den Architekturpattern zählen.

Hallo,

wichtig ist dass diese Muster nicht als 1:1 Vorlage verstanden werden, sondern wichtiger ist die Idee die hinter dem Muster steckt zu erkennen. Insofern ist es auch nicht notwendig jedes Muster auswendig zu können - es reicht zu verstehen wann ich mich für welchen Einsatzzweck von welchem Muster(n) am meisten inspieren lassen kann. D.h. sieh die Muster als Inspiratin für eigene Lösungen an.

mfG Gü

Hallo Klein-Dummy,

am häufigsten nutze ich wohl das Factory- sowie Repository-Pattern, hauptsächlich in Kombination mit ASP.NET MVC und dem Entity Framework.

m0rius

Hallo Klein-Dummy,

es ist natürlich eine gute Idee sich mit Patterns zu beschäftigen. Über das Thema findest du zahlreiche Bücher mit vielen guten Beispielen. Was du nicht machen darfst, ist ein Pattern auszunutzen. Verwende nur Patterns, wenn du sie brauchst! Du darfst nicht überall ein Pattern "reinzwängen".

Am besten ist es, wenn du das Pattern nicht kennst, ein Problem vor die hast und das Problem löst, ohne das Pattern zu kennen und im nachhinein feststellst, dass der Lösungsweg das Pattern ist!

Siehe auch O´Reilly: Entwurfsmuster von Kopf bis Fuß.

zero_x

Hallo zero_x,

dem kann ich nicht ganz zustimmen... Natürlich darf man design patterns nicht irgendwo reinzwängen und sollte sie nur verwenden, wo sie auch passen. Aber trotzdem sind es elegante Lösungen für häufige Probleme, auf die man nicht unbedingt von alleine kommt. Deswegen wird man denke ich eher selten "feststellen", dass die selbstgeschriebene Lösung ein Design Pattern ist.
Deswegen denk ich schon, dass man alle (oder die wichtigsten) Muster zumindest grob kennen sollte. Man kann sie dann auch häufiger einsetzen, als man so vielleicht denkt...

Hallo Coder007,

zero_x sagt ja nicht, dass man keine Patterns kennen sollte. Eigentlich unterstreicht er nur die These "Keine Patterns als Selbstzweck" (um der Patterns Willen). Wenn man im Nachhinein feststellt, dass man ohne bewusste Anwendung ein Pattern implementiert hat, hat man die entsprechende Architektur nicht gewählt, um ein Pattern integriert zu haben.

Der Buchempfehlung O´Reilly: Entwurfsmuster von Kopf bis Fuß kann ich mich nur vollstens anschließen.

m0rius

Hallo,

meine Aussage bezog sich ja auch nur darauf, dass ich nicht glaube, dass man ohne die Patterns zu kennen, selber etwas hinschreibt und im Nachhinein feststellt, dass es einem Pattern entspricht. Meine Erfahrung ist eher, dass sehr viele Entwickler grauenhaften und wirren Code schreiben, wo die Probleme geradezu Musterbeispiele für Design Patterns wären.
Das Buch Entwurfsmuster von Kopf bis Fuß finde ich übrigens auch sehr gut. Angefangen habe ich zwar seinerzeit mit dem "Originalbuch" von der Gang of Four, aber etwas später habe ich auch das O´Reilly Buch gelesen und es hat mir geholfen, die weniger geläufigen Muster besser nachvollziehen zu können.

Hallo Coder007,

dass ich nicht glaube, dass man ohne die Patterns zu kennen, selber etwas hinschreibt und im Nachhinein feststellt, dass es einem Pattern entspricht

genau das wurde aber schon mehrfach im Forum berichtet.

Ansonsten denke ich wie m0rius, dass du zero_x, in dem, was er mit dem zweiten Absatz ausdrücken wollte, falsch verstanden hast, denn sein erster Satz lautet ja: "es ist natürlich eine gute Idee sich mit Patterns zu beschäftigen". Ich glaube, das hat sich jetzt auch geklärt.

herbivore

Hallo,

es sein noch angemerkt dass einige Muster so häufig verwendet werden dass sie sogar Einzug in die C#-Sprache erhalten haben. ZB das Observer-Muster in Form von Ereignisse (siehe [FAQ] Eigenen Event definieren / Information zu Events) und die Iteratoren/Enumeratoren mit dem yield-Schlüsselwort und foreach-Schleifen.

mfG Gü

Ich persönlich verwende das Strategy Pattern eigentlich ständig. Wobei man unter dem Begriff natürlich auch quasi alles verstehen kann....

Rein akademisch betrachtet ist selbst folgender Code irgendwie ein Strategy-Pattern....

listOfIntegers.first(x => x>=0);

Im Grunde genommen wird vermutlich am häufigsten das Observerpattern verwendet ohne das so manch einer es weiß. Stichwort Events ...

Ansonsten verwendet ich solche Pattern häufiger in Librarys wo man so gut es geht zusammenzufassen. Besonders häufig halt Strategy, Factory, State eher in GUI Sachen

Ich habe mir sehr schwer getan beim Lernen der Patterns (hab natürlich noch nicht alle drauf)
Aber ich denke der beste Weg könnte sein, einfach mal im Internet nach Patterns suchen und alles lesen was man findet, hier im Forum wurde natürlich auch schon viel darüber gesprochen und wenn man den vorhanden Links folgt ist man schon mal ein paar Wochen beschäftigt.
Verstehen der Patterns ist imho nur durchs lesen nicht möglich, denn sie lösen Probleme die man nicht hat.
Wenn man ein schönes Stück Zeit investiert hat, dann sollte man anfangen zu programmieren ohne sonderlich auf die Patterns zu achten. Wenn man ein Modul fertig hat, damit meine ich nicht eine einzelne Klasse sondern eher was in Richtung einem Framework, also wenn man ein Modul fertig hat, nochmal über den ganzen Code reflektieren.
Das kann (soll) ruhig solange dauern wie das Schreiben selbst, da wirst Du selbst an gewissen Stellen denken, "Moment, dass könnte man besser machen" dann das Pattern suchen und mit besten wissen und Gewissen den bestehenden Code umbauen.
Das kann (soll) ruhig solange dauern wie das Schreiben selbst, aber beim nächsten Modul sitzt das Pattern schon fest in Deinem Hirn und Du machst es von Anfang an richtig.
Das eine Pattern oder zwei.
Ich selbst halte es für unmöglich, nach dem Lesen von einem Buch alle Patterns richtig anwenden zu können. Also immer schön Step by Step aber dafür sitzt das was man gelernt hat. Wichtig ist hierbei das man sich beim reflektieren genug Zeit lässt und diese Zeit auch nur fürs reflektieren vornimmt.

Soweit die Lesung aus meinem Kopf

Verstehen der Patterns ist imho nur durchs lesen nicht möglich, denn sie lösen Probleme die man nicht hat.

Das kommt denke ich auf die Projekte an. Bei irgendwelchen Lernprojekten vielleicht nicht, aber in Real Life Projekten seh ich ununterbrochen irgendwelche kleinen Teilprobleme, auf die man Design Patterns anwenden kann.

wenn Du die Patterns schon kennst, bin ich ganz Deiner Meinung
Wenn Du gerade mit Patterns anfängst wirst Du noch nicht das Auge dafür haben.
so wollte ich es ausdrücken

Hallo

Muster die ich gerne verwende:

-Abstract Factory & Repository: Häufig in der Datenschicht.

-Strategy, State und Bridge: Sehr nützlich und eng verwandt. Eigentlich lässt sich die Idee dahinter ständig einsetzen um Verhalten wegzukapseln. Meine Meinung: Strategy ist das wichtigste aller Muster.

-Observer, Iterator, Mediator: events und IEnumerables, ist klar. Und jede Form ist Mediator ihrer Controls. Verwendet man also unbewusst ständig.

-Template Method: Kürzlich in einer Bildverarbeitungsbibliothek verwendet mit sehr sauberem Ergebnis.

-Visitor: Double-Dispatching ist eine faszinierende Idee um if-else-Kaskaden bei der Bestimmung eines konkreten Subtyps zu vermeiden.

-Facade: Einen Satz von Low-Level Schnittstellen hinter einer sauberen, kleinen Facade zu verstecken ist praktisch.

-Interpreter: Ein Rekursiv-Absteigender Parser eben. Sehr nützlich aber warum es ein Muster ist, ist mir rätselhaft.

-Builder: Bei einem Lexergenerator kürzlich verwendet: Regulärer Ausdruck -> NFA -> DFA. Der schrittweise Konstruktionsprozess von RA -> NFA kann damit schön weggekapselt werden.

-Command: Bei einem minimalistischen 3D-Modeller. Aus einer Mausaktion wird entsprechend irgendwelchen gesetzten Häckchen ein Command erstellt, das später ausgeführt wird. Sehr saubere Sache.

Muster die mich Interessieren aber noch nie in Produktivcode verwendet habe:

-Memento: Mangels friend-Schlüsselwort etwas schwierig zu verwenden in C# aber es geht trotzdem.

-Fliegengewicht: Schwierig zu verwenden weil man schnell den Überblick beim extrinsischen Zustand verliert und Anwendungsgebiete sind rar.

Muster die ich als unsauber oder wenig nützlich empfinde:

-Dekorator: Bei Streams z.B. sehe ich den Nutzen aber insgesamt sind Dekorierer gefährlich und hässlich. Wenn sich der Client-Code darauf verlässt, es mit dem "echten" Objekt zu tun zu haben, knallts.

-Proxy: Siehe Dekorator. Nützlich um auf Remote-Objekte transparent zuzugreifen aber selbst ist mir noch nie eine saubere Proxy-Implementierung gelungen.

-Adapter: Die Idee ist großartig aber in der Praxis ergeben sich mir zu selten Möglichkeiten einen Adapter zu verwenden. Zum Beispiel wenn eine Kamera gegen eine andere ausgetauscht werden soll und man für das neue Gerät einen Adapter entwickeln möchte. Oft hat Hardware solch individuelle Eigenschaften im zeitlichen Verhalten oder der Reihenfolge verschiedener Befehle, dass getrickst werden muss.

-Composite: Die Idee der Teil-Ganzes-Hierarchie ist toll aber in der Praxis habe ich sowas noch nie benötigt. Normale Baumstrukturen brauche ich dagegen oft. Edit: Ich bin gerade am überlegen. Ich habe mal einen Renderer für 3D-Levels (Quake3 und so) geschrieben und die Geometrie in einen Octree gepackt. Hier kommt das Teil-Ganzes-Prinzip schon zum Einsatz gegenüber einem einfachen Baum... Naja.

-Singleton: Ohne Worte.

Ich habe mir sehr schwer getan beim Lernen der Patterns (hab natürlich noch nicht alle drauf)

Patterns sind ja auch ein bockschweres Thema.

Eine große Hürde für mich waren die praxisfernen, konstruierten und teilweise hanebüchenen Beispiele in manchen Büchern. Der Transfer auf reale Probleme fällt damit schwer. Deswegen habe ich mir zu allen schwierigeren Mustern immer mehrere Quellen herangezogen und das Web durchforstet.

Das "Head First - Design Patterns" - Buch hat mir die Augen ein Stück weit geöffnet. Danach ist das GoF-Buch ein idealer Katalog.
Dringend abraten muss ich von "C# - Design Patterns". Das Buch erfasst die Kerngedanken hinter den Mustern nicht und die Beispiele sind fehlerhaft und schlecht implementiert.

Edit: Eine Million Tippfehler beseitigen 😄

-Dekorator: Bei Streams z.B. sehe ich den Nutzen aber insgesamt sind Dekorierer gefährlich und hässlich. Wenn sich der Client-Code darauf verlässt, es mit dem "echten" Objekt zu tun zu haben, knallts.

-Proxy: Siehe Dekorator. Nützlich um auf Remote-Objekte transparent zuzugreifen aber selbst ist mir noch nie eine saubere Proxy-Implementierung gelungen.

Decorator, Proxy, Wrapper oder wie auch immer man das Konzept bezeichnen mag, find ich oft eigentlich sehr nützlich... Es geht darum, das Verhalten zu modifizieren oder weitere Eigenschaften transparent an ein Objekt anzuhängen. Wenn sich der Client darauf verlässt, dass er ein bestimmtes Objekt hat und nicht sauber gegen eine Schnittstelle programmiert, dann hast du ganz andere Probleme. Mit Decoratorn/Proxys kann man hingegen ganz leicht sowas wie Caching, Filter, Logging und ähnliche Geschichten implementieren, was ja eigentlich auch in jedem Real Life Projekt zu genüge vorkommt.