Welche Design Patterns nutzt ihr in der Praxis regelmäßig?
-
Shade Of Mine schrieb:
Bei Singleton geht es um das Beschränken der Instanzen einer Klasse. Das muss nicht eins sein.
Doch, muss es. Sonst hieße das Entwurfsmuster ja Multipleton.
Es stellt sicher, dass von einer Klasse genau ein Objekt existiert
https://de.wikipedia.org/wiki/Singleton_(Entwurfsmuster)
Zum Singleton gehört auch die globale Verfügbarkeit.
-
Ich nutze auch Singleton, steinigt mich doch! :p
Für Logs, Configs und "Spezial"-Resourcen. Für gewöhnlich wenn es um Dinge geht die über die Programmgrenzen hinausgehen und mit einzigartigen Entitäten verbunden sind.------------------------------------------------
Ich liebe Signal&Slots, Observer, Reactor und diverse Callbackansätze.
Alle anderen Pattern die vorkommen sind "natürlich" entstanden.
Insbesondere diese:
Factory, Lazy XYZ, RAII, Adaptor / Wrapper, Proxy, Iterator und vieles was mit Multithreading zu tun hat, sind täglich Brot (so to speak). Aber das ist nicht wirklich überraschend.Ich habe mal vor einiger Zeit ein Projekt abgeglichen mit der Wikipedia Seite für 'Software Design Patterns'. Von den Myriaden an Patterns die darin vorkommen war nicht eines bewusst eingesetzt.
-
GangOfFive schrieb:
Regelmäßig sehe ich Code von Kollegen, wo ein in meinen Augen simpler Sachverhalt mit dicken Design Patterns erschlagen wird.
Yupp, geht mir auch so.
Wenn alleine das Wort "Pattern" fällt, ist das Thema schon durch. Ein Java-Kid. Alles voll formalem Schmonz, Schnittstellen, Factories, Dependency Injection und vor allem Manager, ObjectManager, ManagerManager, PatternManager und schwupps hat man mit 1500 Zeilen Code was gebaut, was allerbequemstens in 50 passt.
Die vergewaltigten Patterns sind dann noch das geringste Problem.
Klar benutze ich auch (vielleicht sogar die meisten üblicherweise aufgelisteten) Patterns, ich nenne sie aber nur ganz selten so, nur wenn sie in Reinform auftauchen, was bei Strategy, Meyers-Singleton oder Factories mal vorkömmt. Sonst heißen sie nur Standard-Problemlösungen, Tricks oder Hacks. Und ich setze sie selten ein, vielleicht so selten wie Vererbung, häufiger als switch, seltener als do.
-
dot schrieb:
Einer der wohl am weitesten verbreiteten und schlimmsten Antipattern ist der Singleton Pattern.
Naja, das sehe ich anders.
Es gibt auch in Foren und Chats Patterns und das Verleumden aller Singletons ist eins der am weitesten verbreiteten Antipatterns.
-
5cript schrieb:
Ich nutze auch Singleton, steinigt mich doch! :p
Für Logs, Configs und "Spezial"-Resourcen. Für gewöhnlich wenn es um Dinge geht die über die Programmgrenzen hinausgehen und mit einzigartigen Entitäten verbunden sind.Gesteinigt wird nur für Apostasie und Ehebruch.
Ne, ernsthaft: Singletons sind voll okay (für die von dir genannten Fälle z.B.). Diese Anti-Haltung finde ich sehr befremdlich.
-
volkard schrieb:
dot schrieb:
Einer der wohl am weitesten verbreiteten und schlimmsten Antipattern ist der Singleton Pattern.
Naja, das sehe ich anders.
Es gibt auch in Foren und Chats Patterns und das Verleumden aller Singletons ist eins der am weitesten verbreiteten Antipatterns.Singletons hebeln so'n bisschen die Segnungen der Objektorientierung aus. Letztlich bleibt nur noch Kapselung erhalten. Das muss hartgesottenen OOP-Freaks wohl voll gegen den Strich gehen.
-
Leprechaun schrieb:
Ne, ernsthaft: Singletons sind voll okay (für die von dir genannten Fälle z.B.). Diese Anti-Haltung finde ich sehr befremdlich.
Singletons werden gerne mal als globale Variablen missbraucht. Man klatscht nicht einfach so einen globalen integer rein, denn so hat man es ja damals bei dem alten C gemacht und man ist ja ein moderner Programmierer. Stattdessen macht man eine neue Klasse mit einem privaten integer, schreibt sich lehrbuchgetreu getter und setter, verpackt das ganze in ein singleton und schon hat man 50 Zeilen Code geschrieben ohne geistige Arbeit in eine Ueberarbeitung des Codekonzepts zu stecken und die anderen Programmierer muessen erstmal noch nochvollziehen, was dieser Code macht.
Sie sind ein nuetzliches Werkzeug, aber oft ein grober Anfaengerfehler, gerade wenn jemand zu OOP gezwungen wird, ohne es wirklich zu verstehen.
-
Marthog schrieb:
Leprechaun schrieb:
Ne, ernsthaft: Singletons sind voll okay (für die von dir genannten Fälle z.B.). Diese Anti-Haltung finde ich sehr befremdlich.
Singletons werden gerne mal als globale Variablen missbraucht. Man klatscht nicht einfach so einen globalen integer rein, denn so hat man es ja damals bei dem alten C gemacht und man ist ja ein moderner Programmierer. Stattdessen macht man eine neue Klasse mit einem privaten integer, schreibt sich lehrbuchgetreu getter und setter, verpackt das ganze in ein singleton und schon hat man 50 Zeilen Code geschrieben ohne geistige Arbeit in eine Ueberarbeitung des Codekonzepts zu stecken und die anderen Programmierer muessen erstmal noch nochvollziehen, was dieser Code macht.
Sie sind ein nuetzliches Werkzeug, aber oft ein grober Anfaengerfehler, gerade wenn jemand zu OOP gezwungen wird, ohne es wirklich zu verstehen.Sorry, aber der Logger soll doch global sein.
Also wird's auch ne globale Variable (ggfls. als Singleton, das ist recht egal).
-
Marthog schrieb:
Leprechaun schrieb:
Ne, ernsthaft: Singletons sind voll okay (für die von dir genannten Fälle z.B.). Diese Anti-Haltung finde ich sehr befremdlich.
Singletons werden gerne mal als globale Variablen missbraucht. Man klatscht nicht einfach so einen globalen integer rein, denn so hat man es ja damals bei dem alten C gemacht und man ist ja ein moderner Programmierer. Stattdessen macht man eine neue Klasse mit einem privaten integer, schreibt sich lehrbuchgetreu getter und setter, verpackt das ganze in ein singleton und schon hat man 50 Zeilen Code geschrieben ohne geistige Arbeit in eine Ueberarbeitung des Codekonzepts zu stecken und die anderen Programmierer muessen erstmal noch nochvollziehen, was dieser Code macht.
Sie sind ein nuetzliches Werkzeug, aber oft ein grober Anfaengerfehler, gerade wenn jemand zu OOP gezwungen wird, ohne es wirklich zu verstehen.Je mächtiger ein Werkzeug, desto größer seine Mißbrauchsmöglichkeiten.
-
5cript schrieb:
Ich nutze auch Singleton, steinigt mich doch! :p
Für Logs, Configs und "Spezial"-Resourcen. Für gewöhnlich wenn es um Dinge geht die über die Programmgrenzen hinausgehen und mit einzigartigen Entitäten verbunden sind.Dann hast du Singleton offenbar falsch verstanden, besser nochmal auf Seite 127 im GoF nachschlagen...
-
dot schrieb:
Dann hast du Singleton offenbar falsch verstanden
Oder du.
-
Leprechaun schrieb:
dot schrieb:
Dann hast du Singleton offenbar falsch verstanden
Oder du.
nope und du kannst dich gern selbst davon überzeugen, am einfachsten durch aufmerksames Lesen besagter Seite 127...
-
dot schrieb:
Leprechaun schrieb:
dot schrieb:
Dann hast du Singleton offenbar falsch verstanden
Oder du.
nope und du kannst dich gern selbst davon überzeugen, am einfachsten durch aufmerksames Lesen besagter Seite 127...
Was hast du denn an seiner Anwendung von Singletons zu kritisieren?
-
Leprechaun schrieb:
Was hast du denn an seiner Anwendung von Singletons zu kritisieren?
In keinem der genannten Beispiele ist die Forcierung einer Beschränkung der Anzahl der Instanzen eines Typs von Bedeutung. Der einzige (!) Zweck des Singleton Pattern ist Forcierung einer Beschränkung der Anzahl der Instanzen eines Typs, ergo ist Singleton nicht angebracht, so einfach ist das (und genau so steht's auch schon seit 1994 im Buche). Leider hat vor langer Zeit wohl mal einer das Buch falsch verstanden und ist auf die Idee gekommen, dass das Singleton Pattern irgendwie eine nette Verpackung für globale Variablen ist, in der die auf einmal toll aussehen. Das ist natürlich völliger Schwachsinn, nur irgendwie machen es ihm seither trotzdem alle nach...
Nochmal zum Mitschreiben:
"ich brauch nur eines davon" -> kein Singleton, man macht einfach nur eines davon
"es muss um jeden Preis sichergestellt werden, dass von diesem hier niemals mehr als eines instanziert wird, weil sonst die Welt untergeht" -> Singleton
-
@Dot ich versteh dein wiederspruch nicht.
Die Beispiele sind gerade prestigeniert mit einem Singleton gelöst werden, weil die Logik sonst nicht mit meheren Instanzen korrekt laufen würden.
Aber meiners erachten sollte man es anders lösen, wegen den Nachteilen des Singletons. (Implizite Abhängigkeit, ...)
-
Zeus schrieb:
Die Beispiele sind gerade prestigeniert mit einem Singleton gelöst werden, weil die Logik sonst nicht mit meheren Instanzen korrekt laufen würden.
Nö, Singleton ist hier nicht angebracht. "Die Logik" verwendet vielleicht nur ein konkretes Logfile, es gibt aber keinen Grund, wieso es explizit verboten werden muss, dass irgendwo anders noch ein Logfile existiert. Ein Logfile ist einfach nur ein File, in dem Ereignisse protokolliert werden. Es ist keine inhärente Eigenschaft des Konzeptes des Logfiles, dass zu jedem Zeitpunkt nur eines davon existieren kann...
-
dot schrieb:
Zeus schrieb:
Die Beispiele sind gerade prestigeniert mit einem Singleton gelöst werden, weil die Logik sonst nicht mit meheren Instanzen korrekt laufen würden.
Nö, Singleton ist hier nicht angebracht. "Die Logik" verwendet vielleicht nur ein konkretes Logfile, es gibt aber keinen Grund, wieso es explizit verboten werden muss, dass irgendwo anders noch ein Logfile existiert...
Weil die Logs evtl noch validiert werden und dazu gehören sie in einem File? Aber das ist nicht das thema. Mir missfällt deine gesetztgeben Kraft, besonders weil wir relativ abstrakt über Softwaredesign reden.
-
Zeus schrieb:
Weil die Logs evtl noch validiert werden und dazu gehören sie in einem File?
Und nur weil ein Teil eines Programmes ein Logfile verwendet, muss für jeden anderen Teil des Programmes verboten werden, dass dieser ein anderes Logfile hat?
-
dot schrieb:
Nö, Singleton ist hier nicht angebracht. "Die Logik" verwendet vielleicht nur ein konkretes Logfile, es gibt aber keinen Grund, wieso es explizit verboten werden muss, dass irgendwo anders noch ein Logfile existiert.
Ich denke, du siehst die Definition eines Singletons unnötig streng. Wenn man da so betrachtet, findest du wahrscheinlich kein einziges Beispiel, wo es wirklich sinnvoll wäre, nur eine einzige Instanz zu haben.
Wobei es mir beim Logging auch schon paar mal aufgefallen, dass es grad als DAS sinnvolle Beispiel für Singletons aufgeführt wurde, da es ja nur Sinn macht, einen zentralen "Logging Service" zu haben (oder irgendwie so ähnlich beschrieben). Macht jetzt nicht unbedingt Sinn, vielleicht will man ja zwei unterschiedliche Bibliotheken in einem Programm verbinden, die eine gemeinsame Logging Bibliothek benutzen, aber doch völlig unterschiedlich loggen sollen. Wobei man das dann eben über die Logging Einstellungen regelt, aber in dem Fall ist eben das globale Objekt so flexibel, was aber nicht heißt, dass es unbedingt sinnvoller ist, als andere globale Objekte. Genauso könnte man argumentieren, dass man jedes komische globale Objekt einfach über irgendwelche komplizierten Regeln "flexibel" macht und schon hat man kein Problem mit globalen Objekten.
-
Mechanics schrieb:
dot schrieb:
Nö, Singleton ist hier nicht angebracht. "Die Logik" verwendet vielleicht nur ein konkretes Logfile, es gibt aber keinen Grund, wieso es explizit verboten werden muss, dass irgendwo anders noch ein Logfile existiert.
Ich denke, du siehst die Definition eines Singletons unnötig streng. Wenn man da so betrachtet, findest du wahrscheinlich kein einziges Beispiel, wo es wirklich sinnvoll wäre, nur eine einzige Instanz zu haben.
...nur eine einzige Instanz zu erlauben; das ist ja gerade der Punkt. Und richtig erkannt, genau darum gibt es praktisch kein Beispiel wo es sinnvoll wäre.
Der Singleton Pattern dient dazu, sicherzustellen, dass ein Typ nur einmal instanziert wird. Etwas, das mehr als einmal instanziert werden kann ist kein Singleton. Sonst gibt es über Singleton eigentlich nichts zu sagen, es gibt genau diese eine Eigenschaft, die den Singleton ausmacht und der Name allein reicht eigentlich schon als Beschreibung; ich wüsste nicht, was man da jetzt "strenger" oder "milder" auslegen könnte...
