Welche Design Patterns nutzt ihr in der Praxis regelmäßig?
-
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...
-
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.
