Welche Design Patterns nutzt ihr in der Praxis regelmäßig?
-
Obwohl ich der Meinung bin, dass mein Code übersichtlich, modular, gut verständlich und in Summe auch gut testbar und wiederverwendbar ist, greife ich kaum auf die zig existierenden Design Patterns zurück. Regelmäßig sehe ich Code von Kollegen, wo ein in meinen Augen simpler Sachverhalt mit dicken Design Patterns erschlagen wird.
Ein Beispiel ist die Factory:
Wenn ich aus dem Projektwissen heraus weiß, es soll z.B. nur eine Kamera als Ressource (Objekt) erzeugt werden, dann erzeuge ich die nicht über eine Factory. Sollten sich tatsächlich wider Erwarten die Anforderungen später doch noch ändern, und man möchte auch Barcode-Scanner-Objekte erzeugen können, dann pflege ich eben eine Factory nachträglich ein, kein Problem.Ein weiteres Beispiel:
Das viel gelobte MVC. Im Prinzip ja korrekt, aber wenn ich dann sehe, wie Leute irgendwelche "Model" "View" oder "Controller"-Klassen erzeugen, hört es bei mir schon wieder auf. In den meisten Fällen reicht es doch, wenn die GUI entsprechende Funktionalitäten direkt aufruft. Das jede anständige (Nicht-GUI-)Bibliothek im Umkehrschluss in keinster Weise auf GUI-Elemente zugreift, versteht sich doch von selbst. Eine Bibliothek hat immer so weit es geht komplett unabhängig zu sein, damit sie wiederverwendbar ist.In Summe benutzen ich eigentlich (bewusst) nur diese Patterns:
- singleton pattern
- factory method pattern
- adapter pattern
- facade pattern
- Data Access Object (Bei Datenbankeinsatz)
Und da hört es eigentlich auch schon auf. Eventuell habe ich einfach zu wenig Ahnung, da es ja viele mehr gibt (https://de.wikipedia.org/wiki/Entwurfsmuster). Oder ich verwende viele unbewusst und kenne sie nicht
Welche Design Patterns verwendet ihr regelmäßig? Falls ja, wären Beispiele nett. Welche Design Patterns sind evtl. Unfug?
Z.B. das builder-pattern C++ Beispiel: https://de.wikipedia.org/wiki/Erbauer_(Entwurfsmuster)
Ich weiß nicht, was ich davon halten soll
-
GangOfFive schrieb:
Welche Design Patterns verwendet ihr regelmäßig?
Keine. Vielleicht baue ich unbewusst immer mal wieder ein Adapter-Pattern im Code ein, aber dann heisst die Klasse nicht Adapter und ich mache das nur, weil das die natürliche Lösung für das Problem ist.
Ich halte es für schädlich, wenn Programmierer nur in Design Pattern denken. (Btw, Singleton ist in jeder Sprache fast sicher Unfug und in C++ erst recht (Meyers Singleton).)
-
ab und zu Observer Pattern.
Vielleicht auch sonst ab und zu den einen oder anderen wie z.B. Factory.Ansonsten kann ich dir aber zustimmen. Oft wird zwanghaft versucht irgendeinen Pattern zu verwenden, obwohl letztlich eh nur 1+1 berechnet werden soll (überspitzt formuliert).
-
Ich nutze schon das ein oder andere, aber nur selten bewusst.
-
Composite und Observer. Beide unbewusst schon Jahre benutzt ohne zu wissen wie sie heissen.
-
GangOfFive schrieb:
Regelmäßig sehe ich Code von Kollegen, wo ein in meinen Augen simpler Sachverhalt mit dicken Design Patterns erschlagen wird.
Ich halte das für ein Gerücht. Man hört sehr oft diese lapidaren Aussagen, aber so wirklich gesehen habe ich sowas noch nicht. Man sieht vielleicht öfter mal sehr stark überladenen Java Code mit 300 Funktionsaufrufen im Callstack, aber das liegt weniger an den Design Patterns von der GoF.
Man verwendet schon viele Patterns... Sehr oft das Iterator Pattern, das ist nämlich auch eins
Ansonsten alles mögliche mal immer wieder, wenn es sich anbietet. Natürlich geh ich jetzt nicht her und nehme überall eine Factory, statt new aufzurufen. Aber trotzdem hab ich schon zig mal eine Factory oder Factory-ähnliche Konstrukte benutzt.
Auch Observer, Iterpreter, Commands, Composite, Adapter, Proxy usw... Auch wenn man nicht bewußt darauf achtet, überall mit Gewalt ein Pattern reinzuquetschen, bau ich wahrscheinlich doch jeden Tag oder zumindest jede Woche irgendwo ein Pattern ein, weil das einfach grundlegende Konstrukte sind.Bei MVC kommt es drauf an, wo man die Trennung macht. Was ist eine View? Wenn du eine neue Komponente schreibst, die es in deinem Framework nicht gibt, sagen wir ein Breadcrumbs Control, dann wärs natürlich schon genug, wenn du strikt darauf achtest, das so aufzubauen, dass es überhaupt nichts von deinem eigentlichen Code kennt. So, als ob das Teil des Frameworks wäre. Und nicht irgendwie schon in die "View" Klasse irgendwas anwendungsspezifisches reinzubringen.
Die andere Variante ist, und das hab ich schon sehr oft gesehen, dass man sehr viel Logik einfach im Controller schreibt. Die alten UI Frameworks haben mehr oder weniger dazu verleitet oder zumindest nichts geboten, was darauf hinweisen würde, dass es eine schlechte Idee ist. Man bastelt sich irgendwie ein Fenster zusammen, hat dann einen Click Handler für einen Button und dann fängt man an Code zu schreiben. Und dann sind es da 20 000 Zeilen Code in der GUI, jemand will den Code wiederverwenden, weil er ja schon da ist und dann stellt man fest, dass der Code gar nicht Teil des "Modells" ist, also der Basisklassen, die man woanders verwenden könnte, sondern direkt in der GUI drin. Und dann muss man erstmal alles umbauen. Und davon haben wir in unserem alten Code mehr als genug. Wenn man auf sowas achtet wär das für mich schon "MVC" genug.p.s. Strategy und Template wären noch erwähnenswert, denke ich.
-
Patterns sind doch eh hauptsaechlich dazu da, um schlaue Buecher zu schreiben. Ich habe fast noch nie ein Pattern gezielt gelernt und angewendet, wenn doch ging es meistens schief, sondern mache das meiste intuitiv oder uebernehme einfach gute Ansaetze, ohne jetzt speziell darueber nachzudenken.
Facade ist fuer mich z.B. eine normale funktion mit guter kapselung und ich finde es ziemlich daemlich, dass jemand dafuer jetzt einen speziellen Namen ausdenkt.Viel wichtiger finde ich dagegen Antipatterns, denn das sind halt wirklich Faelle, die man intuitiv macht und erst wenn mal ein Projekt wegen sowas zu komplex wird, lernt man, dass die doch nicht so toll sind.
-
Decorator drängt sich bei einer Pipe & Filter - Architektur auf.
-
Ich nutze oft "State": https://en.wikipedia.org/wiki/State_pattern
... in irgendeiner Form.
-
Pattern sind nichts anderes als eine einheitliche Namensgebung für Standardproblemlösungen.
Jeder Programmierer löst konstant Standardprobleme.
Design Pattern haben uns einfach nur Namen für diese Standardlösungen gegeben so dass wir nicht mehr kompliziert erklären müssen was wir meinen, sondern es mit einem Namen bezeichnen können.
Deshalb ist es irgendwie doof zu sagen Pattern sind gut oder schlecht - denn sie sind einfach nur Namen. Und einheitliche Namen sind praktisch. Sie helfen in der Kommunikation enorm.
-
Mechanics schrieb:
GangOfFive schrieb:
Regelmäßig sehe ich Code von Kollegen, wo ein in meinen Augen simpler Sachverhalt mit dicken Design Patterns erschlagen wird.
Ich halte das für ein Gerücht. Man hört sehr oft diese lapidaren Aussagen, aber so wirklich gesehen habe ich sowas noch nicht. Man sieht vielleicht öfter mal sehr stark überladenen Java Code mit 300 Funktionsaufrufen im Callstack, aber das liegt weniger an den Design Patterns von der GoF.
Ich habe so etwas schon selbst gesehen, doch ist das die Ausnahme und nicht die Regel. Overengineering ist durchaus häufiger zu bemerken (ich bin selbst nicht gänzlich immun dagegen, versuche es bewusst nur dann zu machen, wenn ich weiß das dies in der Zukunft tatsächlich sinnvoll ist [z.B. weil dafür schon ein Vorgang mit niedriger Priorität vorliegt, wichtigere Aufgaben aber vorher zu erledigen sind]).
-
Shade Of Mine schrieb:
Deshalb ist es irgendwie doof zu sagen Pattern sind gut oder schlecht - denn sie sind einfach nur Namen. Und einheitliche Namen sind praktisch. Sie helfen in der Kommunikation enorm.
Das Problem ist nur, das nach dem lesen des GoF-Buchs gerade Anfänger dazu neigen alle Pattern in Praxis zu nutzen, auch wenn sie eigentlich nicht nötig wären. Die einheitliche Benennung ist dagegen wiederum durchaus ein Argument für die Pattern.
-
GangOfFive schrieb:
Welche Design Patterns verwendet ihr regelmäßig? Falls ja, wären Beispiele nett.
Ich sehe mich öfters den Builder Pattern verwenden. Beispiel: Laden einer komplexen Objektstruktur aus einer Datei.
GangOfFive schrieb:
Welche Design Patterns sind evtl. Unfug?
Einer der wohl am weitesten verbreiteten und schlimmsten Antipattern ist der Singleton Pattern.
-
asc schrieb:
Shade Of Mine schrieb:
Deshalb ist es irgendwie doof zu sagen Pattern sind gut oder schlecht - denn sie sind einfach nur Namen. Und einheitliche Namen sind praktisch. Sie helfen in der Kommunikation enorm.
Das Problem ist nur, das nach dem lesen des GoF-Buchs gerade Anfänger dazu neigen alle Pattern in Praxis zu nutzen, auch wenn sie eigentlich nicht nötig wären. Die einheitliche Benennung ist dagegen wiederum durchaus ein Argument für die Pattern.
Das ist aber kein Problem von Pattern sondern einfach ein Problem dass Anfänger schlechten Code schreiben. Das kann dir nach einem Effective C++ auch passieren.
Aber mal ehrlich, wer gibt einem Anfänger das GoF Buch? Das ist zwar ein Standardwerk dass man im Regal stehen haben sollte, aber ich würde das nie Jemanden empfehlen zu lesen. Ist ja Trocken bis zum Umfallen. Es ist ja auch ein Pattern Katalog - zum Nachschlagen. Nichts zum aktiv lesen.
Ich denke es liegt eher daran dass es eine Zeitlang einen Pattern Hype gab, dass viele Leute gegen Pattern sind. Denn viele Leute haben in der Hypephase Pattern als Allgemeinlösung für alle Probleme angepriesen. Das sind sie nicht. Pattern sind eine Sammlung von Standardlösungen von Standardproblemen denen man einen Namen gegeben hat um sie katalogisieren zu können und darüber reden zu können.
Jeder Programmierer verwendet konstant überall Pattern. Weil er eben konstant und überall Standardprobleme löst.
-
dot schrieb:
Einer der wohl am weitesten verbreiteten und schlimmsten Antipattern ist der Singleton Pattern.
Das hängt aus meiner Sicht stark davon ab, wofür der SingleTon da ist. In einigen wenigen Fällen macht er durchaus Sinn (so z.B. in einem .NET Remoting Service, bei dem alle Remoting-Aufrufe in genau die gleiche Instanz gehen sollen.
-
Jeder der OOP und seine Programmiersprache verstanden hat, wird instinktiv Patterns einsetzen. Auch wenn er/sie es nicht weiß.
Denn die Patterns sind doch nur verallgemeinerte Lösungen, die selbst aus der Praxis entstanden sind.
Ich hatte damals, bevor ich etwas über Patterns oder GoF gehört/gelesen habe, schon Patterns eingesetzt. Das bringt schon alleine die Programmiersprache mit sich. Das Template-Pattern (nicht mit C++-Template zu verwechseln) wird jeder irgendwann mal anwenden, wenn er die Möglichkeit der Abstract-Methoden kennt.
Und das Singleton wird auch jeder anwenden, wer Static-Variablen kennt.
Ob er das dann so in einem Buch formuliert und verallgemeinert, ist dann eine andere Frage.
Der entscheidende Punkt ist, das die GoF es getan haben! :p
-
inflames2k schrieb:
dot schrieb:
Einer der wohl am weitesten verbreiteten und schlimmsten Antipattern ist der Singleton Pattern.
Das hängt aus meiner Sicht stark davon ab, wofür der SingleTon da ist. In einigen wenigen Fällen macht er durchaus Sinn (so z.B. in einem .NET Remoting Service, bei dem alle Remoting-Aufrufe in genau die gleiche Instanz gehen sollen.
Ich hab in all meinen Jahren noch kein einziges Beispiel gesehen, wo Singleton tatsächlich Sinn gemacht hätte und dein Beispiel ist da leider keine Ausnahme, sondern nur ein weiteres Beispiel für das übliche Missverständnis (die Frage "Brauche ich nur eines davon?" liefert entgegen gängiger Auffassung leider keine Antwort auf die Frage "Sollte ich den Singleton Pattern verwenden?". Letztere ist fast ausschließlich immer mit "Nein" zu beantworten)...
-
dot schrieb:
Ich hab in all meinen Jahren noch kein einziges Beispiel gesehen, wo Singleton tatsächlich Sinn gemacht hätte
Als Beispiel nahezu jede Userverwaltung.
Du willst pro User nur ein Objekt haben, aber allgemeinen Zugriff auf User Objekte erlauben.Singleton ist mehr als nur das Standard getInstance() dass man kennt. Bei Singleton geht es um das Beschränken der Instanzen einer Klasse. Das muss nicht eins sein.
-
Shade Of Mine schrieb:
Bei Singleton geht es um das Beschränken der Instanzen einer Klasse.
exakt, wo das beim Beispiel einer Userverwaltung Sinn ergeben würde seh ich aber grad nicht; du modellierst ja nicht jeden User als eigene Klasse!?
-
Artchi schrieb:
Jeder der OOP und seine Programmiersprache verstanden hat, wird instinktiv Patterns einsetzen. Auch wenn er/sie es nicht weiß.
Das GoF Buch war seinerzeit tatsächlich eine Offenbarung für mich. Davor hatte ich OOP nicht verstanden. Ich war damals zwar nicht unbedingt ein Anfänger, weil ich schon sehr viel programmiert hatte, aber das war noch vor dem Studium und mir hatte damals auch noch keiner gesagt, was gut und was schlecht ist. Erst mit dem GoF Buch hab ich erkannt, dass OOP mehr ist, als Funktionen in Structs zu stecken. Ich bin damals also zumindest nicht selber intuitiv draufgekommen.
