Ich denke, eine Anwendungskonfiguration eine hervorragende Nutzung des Singleton-Musters ist. Ich neige dazu, es selbst zu verwenden, um zu verhindern, dass ich die Konfiguration jedes Mal neu lesen muss, wenn ich darauf zugreifen möchte, und weil ich möchte, dass die Konfiguration stark typisiert wird (d. H. Nicht Nicht-String-Werte jedes Mal konvertieren müssen). Ich verwende gewöhnlich einige Backdoor-Methoden für mein Singleton, um die Testbarkeit zu unterstützen - d. H. Die Fähigkeit, eine XML-Konfiguration zu injizieren, sodass ich sie in meinem Test einstellen kann und den Singleton so zerstören kann, dass er bei Bedarf neu erstellt wird. Typischerweise sind dies private Methoden, auf die ich über Reflektion zugreife, so dass sie von der öffentlichen Schnittstelle verborgen sind.
BEARBEITEN Wir leben und lernen. Während ich denke, dass die Anwendungskonfiguration einer der wenigen Orte ist, an denen ein Singleton verwendet werden kann, mache ich das nicht mehr. In der Regel werde ich jetzt eine Schnittstelle und eine Standardklassenimplementierung unter Verwendung von statischen Lazy<T> Hintergrundfeldern für die Konfigurationseigenschaften erstellen. Dies ermöglicht mir, das Verhalten "Einmal initialisieren" für jede Eigenschaft mit einem besseren Design für die Testbarkeit zu haben.
+1, die Menschen lieben ihre kleine Regeln wie „nur einen Ausgang aus einer Schleife“ oder „keine Singletons erlaubt“ zu erstellen. Ich wäre lieber pragmatisch als dogmatisch, da das Dogma dazu führt, dass Menschen nicht für sich selbst denken können. Wenn Sie nur ein X-Objekt haben können, sollten Sie nur ein XConfig-Objekt haben. – paxdiablo
Eine einzelne Instanz eines Konfigurationsobjekts ist in Ordnung und wünschenswert, aber es macht nicht die Verwendung eines Singleton, um es gut zu bekommen.Die Verwendung von Hacks wie testspezifische Methoden in Ihrer tatsächlichen Klasse sind auch nicht für sauberen Code oder Tests geeignet. – ColinD