我曾经使用singleton获取单个实例，但由于测试中的一些缺点而被其他人否认。有什么缺点？ 有没有其他获取全局实例的好方法？
那么我可以在应用程序中只创建一个单例类 Global 作为全局集线器吗？这样我就可以将任何其他类的单个实例放在 Global.Instance 中。
【问题讨论】：
好的，为什么单身人士不好，你可以在这里阅读：What is so bad about singletons?
专门用于测试：典型的单例模式如下所示
class MyClass
{
private static MyClass m_Instance = new MyClass();
public static MyClass Instance
{
get { return m_Instance; }
}
}
现在假设您必须运行一大堆涉及MyClass.Instance 的测试。这个类带有一个状态，你通常需要有一种方法在测试之间重置它，以便每个测试都可以从一个干净的初始状态开始。现在您可以添加一个Reset() 方法，但这意味着您将代码添加到您的类中只是为了能够测试它，这是不可取的。
改用什么：好吧，单例本身并不是什么坏事。它导致的问题是，这样编写代码很容易：
class SomeClass
{
public void SomeMethod()
{
...
MyClass.Instance.DoSomething();
}
}
现在你已经创建了一个对你不能轻易破坏的单例实例的隐式依赖。解决这个问题的一种方法是通过依赖注入（已经提到过）：
class SomeClass
{
public SomeClass(MyClass myClass)
{
m_MyClass = myClass;
}
public void SomeMethod()
{
...
m_MyClass.DoSomething();
}
}
你可以这样做：
var someClass = new SomeClass(MyClass.Instance);
在你的程序中和
var someClass = new SomeClass(new MyClass());
用于测试。
所以单身人士并不是那么糟糕，有时是适合工作的正确工具，但是您需要注意如何使用它们。
【讨论】：
在我看来，可测试性是主要困难，为了在一定程度上解决这个问题，我们有统一容器。
检查 Unity 容器http://unity.codeplex.com/
【讨论】：
我没有看到任何可测试性和单例的问题。我也看不出 DI 是如何替代它们的。
【讨论】：
考虑改用所谓的“环境上下文”模式。这个例子取自 Mark Seeman 的优秀 .NET 中的依赖注入一书。这种模式使您可以轻松使用单例，并且还具有可测试性。这里的重点是存在所谓的良好“默认值”（即示例中显示的 DefaultTimeProvider）。要考虑的另一件事是不要滥用这种模式，在大多数情况下，您可以将不同的依赖项注入到类的构造函数中。这种模式应该只用于贯穿整个应用程序的关注点。
public abstract class TimeProvider
{
private static TimeProvider current;
static TimeProvider()
{
TimeProvider.current = new DefaultTimeProvider();
}
public static TimeProvider Current
{
get { return TimeProvider.current; }
set
{
if (value == null)
{
throw new ArgumentNullException("value");
}
TimeProvider.current = value;
}
}
public abstract DateTime UtcNow { get; }
public static void ResetToDefault()
{
TimeProvider.current = new DefaultTimeProvider();
}
}
【讨论】：