Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Hier geht es doch nicht darum dass statics in C# keine globalen Variablen wären und es dafür andere Konzepte gibt.
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.
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.
Quellcode |
|
1 2 3 4 5 6 7 8 |
public class MySingleton { public static final MySingleton instance = new MySingleton(); private MySingleton() {} [...] } |
Quellcode |
|
1 2 3 4 5 6 7 8 |
public class MySingleton implements TestableInterface { public static final MySingleton instance = new MySingleton(); private MySingleton() {} [...] } |
Quellcode |
|
1 2 3 4 5 6 7 8 9 10 11 |
public class ContainerClass { private static class MySingleton implements TestableInterface { public static final MySingleton instance = new MySingleton(); private MySingleton() {} [...] } } |
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
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.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Genau dafür ist das Interface gedacht, damit verwendender Code gegen ein Interface implementiert wird, nicht gegen die konkrete Klasse.Man kann aber auch nicht einfach einen Mock oder einen Stub injecten, [...]
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.[...], weil das dem Prinzip des Singletons widerspricht.
... 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.)Genau das wäre ja aber saubere Dependency-Injection über Parameter und keine typische Verwendung des Singletons.
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Werbeanzeige