Welche Design Patterns nutzt ihr in der Praxis regelmäßig?
-
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...
-
dot schrieb:
ich wüsste nicht, was man da jetzt "strenger" oder "milder" auslegen könnte...
Die "milde" Auslegung wäre tatsächlich, "die eine sinnvolle Instanz in einem Programm", also von mir aus eine etwas schöner verpackte globale Variable. Und das finde ich pragmatisch auch ok und verwende das schon ab und zu. Wenn wir beim Design der Software entscheiden, ok, wir brauchen eine (oder eine) Benutzerverwaltung, und es ist nicht abzusehen, warum es zwei Instanzen davon geben sollte, dann ist es aus praktischer Sicht vielleicht tatsächlich sauberer, die hinter einem Singleton zu verstecken, statt die Instanz überall durchzureichen, weil sie vielleicht jemand irgendwo brauchen könnte. Das ist dann halt ein "logischer" Singleton. Ist kein Problem, wenn man mehrere Instanzen erstellt (oder vielleicht doch, wer weiß), aber von der Logik her braucht man nur eine.
-
dot schrieb:
"es muss um jeden Preis sichergestellt werden, dass von diesem hier niemals mehr als eines instanziert wird, weil sonst die Welt untergeht" -> Singleton
Was anderes hat auch keiner gesagt. Sinngemäß jedenfalls, ohne den blöden Weltuntergang.
-
Ich bin consumer und ersteller meines codes und ich lege fest: es gibt nur einen Log pro Programminstanz. Alles andere ist Unsinn (leg ich einfach fest).
Und wenn ich diese Entscheidung fälle, und durchsetzen will dann ist das genau hier richtig. Nur weil "könnte doch..." Nein! Soll es nicht! Darf es nicht!Ich kenne in meinem Studium auch einen Pattern Fetischisten. Und zwar immer bis zum letzten Detail eingehalten und durchgesetzt. Wie vom Gesetz vorgeschrieben. Ich sehe auch Vorteile, aber angestellt bei ihm will ich niemals sein.
(Ich arbeite mit ihm zwar am selben Institut, an der selben Software, aber das ist groß genug, dass wir uns nicht auf die Füße treten).
-
Mechanics schrieb:
also von mir aus eine etwas schöner verpackte globale Variable.
Was ist daran schoener verpackt? Ich habe die 30 Seiten vorher jetzt nicht gelesen, aber das scheint mir der Hauptpunkt zu sein. Ich habe jetzt kein grosses Problem mit Singletons, aber den Vorteil zu einer globalen Variable sehe ich nicht wirklich, ausser wenn man eben wirklich unbedingt verhindern muss dass es mehrere Instanzen dieser Klasse gibt. (Was, wie du selbst ja festgestellt hast, ziemlich selten ist.)
-
Ich hab vorher auch nichts dazu geschrieben
Spontane Überlegungen, warum das eine schöner verpackte globale Variable ist:
- Man hat weniger Probleme wegen der Reihenfolge beim Erstellen/Zerstören von statischen Objekten. Oder man hats zumindest besser im Griff, wir können für unsere Singletons z.B. die Reihenfolge beim Zerstören definieren.
- Man hat besser im Griff, wie die Instanzen benutzt werden können. So wie mit private/public. Wär vielleicht nicht weiter dramatisch, wenn jemand eine weitere Instanz erstellt, aber das ist bei vielen private Membern auch der Fall. Man hat einfach ein besseres Gefühl, wenn man die API möglichst nur so benutzen kann, wie man sich das gedacht hat.
- Was wir ab und zu haben, sind thread local Objekte, die den Singleton überschreiben. Das macht halt der Singleton intern. Wenn man einen Prozess hat, bei dem man weiß, das man nicht DIE Instanz benutzen will, legt man so einen Singleton-Überschreiber auf den Stack, der z.B. für diesen Thread oder global gilt. Eine ganz andere Klasse, die in sich abgeschlossen ist und einfach nur den Singleton benutzt, und die irgendwo 20 Aufrufebenen drunter benutzt wird, bekommt dann die Instanz, die wir wollen, weil die Zugriffsfunktion des Singletons sich drum kümmert. Ok, damit ist es dann eigentlich kein Singleton, sondern eher ein Service Locator. Aber das Objekt, das die Services verwaltet, ist ein Singleton.
-
volkard schrieb:
[...]
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.
[...]Harhar, genau so ist es
Besonders diese blöden Manager. Für jeden Mist einen Manager mit wahnsinnig sprechenden Namen wie "ObjectManager". Oder Handler. Manager und Handler sind anscheinen super suffixe für Klassennamen.Und dann beginnt nämlich die Klickorgie. Bis man dann mal herausgefunden hat, wo wirklich mal die Funktionalität steckt, vergehen Stunden und merken kann man sich das dann auch nicht, weil ständig irgendwas irgendwo "gemanaged" oder "gehandlet" wird.
Furchtbar.
-
Harhar schrieb:
volkard schrieb:
[...]
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.
[...]Harhar, genau so ist es
Besonders diese blöden Manager. Für jeden Mist einen Manager mit wahnsinnig sprechenden Namen wie "ObjectManager". Oder Handler. Manager und Handler sind anscheinen super suffixe für Klassennamen.Und dann beginnt nämlich die Klickorgie. Bis man dann mal herausgefunden hat, wo wirklich mal die Funktionalität steckt, vergehen Stunden und merken kann man sich das dann auch nicht, weil ständig irgendwas irgendwo "gemanaged" oder "gehandlet" wird.
Furchtbar.
ja natürlich kann man alles "vergewaltigen" und so in klickorgien enden.
das passiert dann wahrscheinlich aber genauso mit oder ohne patterns, ebenso wie die namen eher wenig mit den patterns zutun haben, da man meiner meinung nach auch design patterns treffend benennen kann... (trozdem aber noch dem programmierer einen hinweis gibt das es sich um ein pattern handelt)
natürlich kann man durch patterns bzw. eine spezielle anwendung dieser patterns schlecht nachvollziehbaren und wartbaren code schreiben, wenn diese patterns jedoch nach den regeln angewendet werden und auch noch sinnvoll eingesetzt werden (vll impliziert das eine das andere... ) dann erleichtern diese mir das lesen und nachvollziehen von code stücken.
da ich weiß pattern x macht x und das macht genau das...
wie oben schon gesagt wurde es sind ja standardlösungen für standardprobleme...
(ich finde gerade in bezug auf wartbarkeit und nachvollziehbarkeit eine anwendung von design patterns angebracht!)wenn jeder jetzt seine "individuelle" lösung für alles baut ist das evt. auch nicht besser als das entsprechende pattern (da diese ja auch von mehreren programmierern benutzt werden und so meiner meinung nach auch fehlerunanfälliger sind...)
meiner meinung nach sind es halt standardlösungen und wenn diese passen kann/sollte man sie meiner meinung nach nutzen, dazu sind es allgemein bekannte lösungen, die im normalfall jeder programmierer kennt oder schonmal gesehen hat ( bzw. wenigstens nachschlagen kann... )
da ich im normalfall dann sofort weiß was macht pattern x...
wenn nicht schlage ichhalt nochmal schnell nach...ps. 1. dies gilt nat. nur sofern die patterns regelgetreu angewendet werden...
2. ist nur meine meinung...
(sicherlich machen patterns auch nicht immer sinn obwohl sie laut definition
passen sollten/können...)
-
sry für den doppelpost...
aber kann nicht editieren und hab das eben vergessen:Fazit:
Es gibt meiner meinung nach mehrere wege nach Rom, sofern die Funktionalität fehlerfrei umgesetzt ist/wird spielt es in meinen augen auch keine rolle ob mit oder ohne pattern.Nur meiner meinung nach kann man halt für standardprobleme ruhig die standardlösung verwenden (sofern der einsatz sinn macht) da es mir zumindest an mancher stelle hilft den code schnell nachzuvollziehen.
z.b. observer nutze ich gerne und oft...
(jedoch kann man sicher diese probleme meistens oder immer auch anders lösen)oder mvc für grafische oberflächen...
(zumindest wenn mvc eigenschaften gebraucht werden... bzw. vorteile bringen)
ich lasse mich aber auch immer gerne eines besseren belehren, schließlich lernt man nie aus ...es gibt aber meiner meinung nach auch genug "fälle" in denen eine individuelle lösung sinn macht vll sogar besser ist.
(deswegen viele wege führen nach rom...)i.wo ist es finde ich dann halt auch einfach geschmachssache oder künstlerische freiheit des programmieres (sofern man das als kunstlerisches werk betrachtet
)davon abgesehen das man im team arbeitet und sich vorher über den einsatz von design patterns festgelegt hat (dann sollte man meiner meinung nach um jeden preis diese "festlegungen" einhalten)
lg
