spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Schorsch«

Hier geht es doch nicht darum dass statics in C# keine globalen Variablen wären und es dafür andere Konzepte gibt.

Doch, genau das wurde hier ja implizit behauptet, nämlich dass statische Variablen irgendwie eine bessere Alternative zu globalen Variablen wären!? Und das ist halt einfach falsch und das wollte ich nicht so stehen lassen...

Zitat von »LetsGo«

Ich glaube, dass hier zwei Welten aufeinander treffen, deren Konzepte sich sehr stark unterscheiden. Es ist halt ein Unterschied ob ich Server-Backend schreibe oder eine "normale" Anwendung (Spiel) programmiere.

Sehe nicht, inwiefern das an so grundlegenden Dingen wie den Problemen von globalen Variablen und Singleton etwas ändern sollte. Dinge wie implizite Abhängigkeiten und action-at-a-distance Effekte sind ja nicht nur subjektiv und nur in "normalen Anwendungen" schlecht...

Zitat von »LetsGo«

In bestimmten Umgebungen ist (gerade bei verteilten Anwendungen) ist es eben praktisch einen Singleton zu haben, gerade weil man nur eine Instanz haben darf. Genau das ist eben auch der Sinn des Singletons.

Kannst du mir ein Beispiel für eine solche Umgebung/Anwendung geben, in der ein Singleton sich als gutes Design erwiesen hat? Fänd ich jetzt wirklich spannend...

Da hier so über Singleton geschimpft wird, eine kleine Geschichte:

Ich war in einem Vorstellungsgespräch bei einem großen deutschen Telefon-/Internet-Anbieter. Es war mein erstes überhaupt. Es ging um eine Stelle als Java-Entwickler. Da fragte mein Gegenüber mich ob ich mir was unter Design-Patterns vorstellen kann und ich soll doch mal ein Paar nennen. Ich zählte darauf hin den Standard auf: Factory, Singleton, bla bla. Und er meinte dann Singleton sei für ihn das schlimmste Anti-Pattern überhaupt

Ich finds irgendwie lustig, aber auch traurig, weil er irgendwie schon recht hat xD

Wenn wir schon bei guten Pattern sind, und ich auch schon Anti-Pattern erwähnt habe:

https://de.wikipedia.org/wiki/Anti-Pattern


Schon interessant. Ich habe mich beim lesen des öfteren selbst ertappt

Hallo zusammen,

mein erster Post in eurem Forum

Da hier gerade wild über das Singleton Pattern diskutiert wird möchte ich da auch noch kurz etwas zu sagen.
In der hardwarenahen Programmierung wird das Singleton häufiger angewendet. Wenn man einen Microkontroller hat und
eine Schnittstelle vom Betriebssystem und von einer Anwendung benutzt werden soll, kann man mit einem Singleton
den Zugriff kontrollieren, da ja tatsächlich auch nur eine physikalische Instanz vorhanden ist.

In der Uni haben wir mal die Siedler von Katan programmiert und die Übertragung des Datenmodells wurde mit JSON
vorgegeben. Zum Verarbeiten der Nachrichten haben wir dann die Chain of rsponsibillity verwendet.

Bei den Game an dem ich derzeit mitarbeite benutzen wir für die AI Agents.

Ist dann halt miserabel testbar, nöch?

Testbarkeit könnte man auch mit Singletons haben, würde man nicht einfach strikt die Standardimplementation verwenden. (Das ist auch der Grund, warum ich grundsätzlich die Standardimplementierungen vom Singleton als schlecht beschreibe, nicht aber Singleton grundsätzlich.)

Beispiel für Standardimplementation (Java):

Testbare Variante:
Voraussetzung dabei wäre, dass die Instanz nur von einer Stelle abgerufen wird und an die anderen weitergereicht wird. Erzwingen kann man dies, indem die Implementierung eine innere Klasse einer anderen Klasse ist, welche die Instanz dann weiterreichen kann.


Weiterhin bleibt für viele das Problem, dass Singleton oft nicht notwendig ist, da es reicht, nur eine Instanz zu erzeugen, statt eine Obergrenze von 1 zu erzwingen.
Mit Dependency Injection hat man noch weitere Möglichkeiten, die Verteilung der Instanz zu steuern. (Das wurde meines Wissens bereits weiter oben beschrieben.)


@GrischaG:
Und wie wird verhindert, dass die Software, die auf die Hardware zugreift, nicht mehrfach ausgeführt wird? Wie verhindert man, dass nicht 2 unterschiedliche Programme auf die gleiche Hardware zugreifen? Ich denke, dass diese Probleme mit Singletons nicht gelöst werden können.

Zitat von »Sacaldur«

Und wie wird verhindert, dass die Software, die auf die Hardware zugreift, nicht mehrfach ausgeführt wird? Wie verhindert man, dass nicht 2 unterschiedliche Programme auf die gleiche Hardware zugreifen? Ich denke, dass diese Probleme mit Singletons nicht gelöst werden können.

Ja da muss man noch weiteres implementieren. Bei kleinen Systemen gibt es meist nur eine Anwendung die zugreift. Aber selbst dann muss ein Stack imlementiert werden der vom BS überwacht wird oder das BS arbeitet mit Semaphoren. Kann man sicherlich auch anders lösen, in diesem Zusammenhang sind mir Singletons in der Praxis begegnet.

Sacaldur, dein Beispiel habe ich nicht verstanden. Wieso wird aus einem Singleton plötzlich etwas schön testbares, nur weil ich es in einen Container packe und von einem magischen TestableInterface ableite? Weder das Interface, noch der Container machen für mich Sinn. Im Verlauf redest du dann auch noch davon, dass Voraussetzung wäre, dass das Teil weitergereicht wird. Genau das wäre ja aber saubere Dependency-Injection über Parameter und keine typische Verwendung des Singletons.
Code mit einem Singleton ist ja unter anderem schlecht testbar, weil der Zustand des Singletons für den Test undefinierbar/unkontrollierbar ist. Man kann aber auch nicht einfach einen Mock oder einen Stub injecten, weil das dem Prinzip des Singletons widerspricht. Wenn das ginge, wäre es ja kein Singleton mehr, sondern lediglich eine normale globale/statische Variable mit public get/set Methoden drumrum. Sicher kann man das tun. Aber das ist weder ein Singleton, noch irgendwie besser testbar, weil man dann statt dem Interface von Klassen und Methoden keinen Blackbox-Test mehr machen kann, sondern explizit wissen muss, wie diese Dinge intern arbeiten, um aus dem gewünschten Input den gewünschten Output zu erzeugen, damit man den entsprechenden Stub/Mock injecten kann. Das ist nichts, was ich "gut testbar" nennen würde.

Zitat von »BlueCobold«

Man kann aber auch nicht einfach einen Mock oder einen Stub injecten, [...]

Genau dafür ist das Interface gedacht, damit verwendender Code gegen ein Interface implementiert wird, nicht gegen die konkrete Klasse.

Zitat von »BlueCobold«

[...], weil das dem Prinzip des Singletons widerspricht.

Wenn man das Interface mehrfach implementiert, dann wäre eine Implementation das Singleton (wovon es nur 1 Instanz gäbe), eine andere wäre ein Mock für die Tests, aber kein Singleton. Somit wären Stellen, die das Interface verwenden testbar, auch wenn zur Laufzeit auf das Singleton zugegriffen wird.

Der Container würde nur zur Compile Time sicherstellen, dass das Singleton nicht über einen global zugreifbaren Member abgerufen wird.

Zitat von »BlueCobold«

Genau das wäre ja aber saubere Dependency-Injection über Parameter und keine typische Verwendung des Singletons.

... und ich habe gerade beschreiben wollen, dass die typische Verwendung (mit der "Standardimplementierung") bereits für einen Großteil der Probleme sorgt. Ich sehe also keinen Widerspruch zu meiner Ausführung. (Nur würde ich beim Weiterreichen erstmal nur von "Inversion of Control" reden.)

Macht für mich eigentlich sinn.