单例与仅填充静态字段的类有何不同？
【问题讨论】：
标签： java design-patterns
几乎每次我编写一个静态类时，我最终都希望我将它实现为一个非静态类。考虑：
由于这两点，非静态类使得为依赖它们的项目编写更可靠的单元测试成为可能。
然而，单例模式离静态类只有半步之遥。您有点获得了这些好处，但是如果您通过“ClassName.Instance”直接在其他类中访问它们，那么您正在为获得这些好处制造障碍。就像 ph0enix 指出的那样，使用依赖注入模式会更好。这样，一个 DI 框架可以被告知一个特定的类是（或不是）一个单例。您可以获得模拟、单元测试、多态性和更多灵活性的所有好处。
【讨论】：
让我总结一下:)
本质区别是：单例的存在形式是对象，静态不是。这导致了以下事情：
最后但同样重要的是，无论何时你要实现一个单例，请考虑重新设计你的想法，不要使用这个上帝对象（相信我，你会倾向于把所有“有趣”的东西放到这个类中）并使用一个名为“Context”或类似名称的普通类。
【讨论】：
单例可以懒惰地初始化。
【讨论】：
我认为，重要的是面向对象编程中的“对象”。除了少数情况，我们应该限制使用静态类。这些情况是：
另一个重要的事情是单例是可扩展的。单例可以扩展。在 Math 类中，使用 final 方法，避免了该类对象的创建和扩展。 java.lang.System 类也是如此。但是，Runtime 类是单个对象，而不是静态方法。在这种情况下，您可以为不同的目的覆盖 Runtime 类的继承方法。
您可以延迟创建单例对象，直到需要它（延迟加载）。但是，对于静态方法类，没有条件之类的东西。如果您到达该类的任何静态成员，该类将被加载到内存中。
因此，静态方法类最基本的好处是您不必创建对象，但是如果使用不当，它将使您的代码不再面向对象。
【讨论】：
Date.Now 电话。然而，在 99.99% 的情况下，使用静态 Date.Now 方法调用几乎不可能进行模拟测试。或者更确切地说，静态方法不允许通常允许注入和模拟。
区别与语言无关。根据定义，单例是：“确保一个类只有一个实例并提供对其的全局访问点。”仅填充静态字段的类与单例不同，但在您的使用场景中，它们可能提供相同的功能。但正如 JRL 所说，懒惰的启动是其中一个区别。
【讨论】：
至少您可以更轻松地用模拟或存根替换它以进行单元测试。但我不是单身人士的忠实粉丝，正如你所描述的原因：它是伪装的全局变量。
【讨论】：
一个单例类将有一个实例，通常每个类加载器只有一个。所以它可以有常规方法（非静态），并且可以在该特定实例上调用它们。
虽然类只有静态方法，但实际上没有必要创建实例（因此大多数人/框架都将这类 Util 类抽象化）。您将直接调用类上的方法。
【讨论】：
首先想到的是，如果您想使用仅具有静态方法和属性的类而不是单例，则必须使用静态初始化程序来正确初始化某些属性。示例：
class NoSingleton {
static {
//initialize foo with something complex that can't be done otherwise
}
static private foo;
}
这将在类加载时执行，这可能不是您想要的。如果您将其实现为单例，则您可以更好地控制整个 shebang。但是我认为在任何情况下使用单例都不是一个好主意。
【讨论】：
单例是一个只有一个实例的类，强制执行。该类可能具有状态（是的，我知道静态变量保持状态），并非所有成员变量或方法都需要是静态的。
变体是这些对象的一个小池，如果所有方法都是静态的，这是不可能的。
【讨论】：
注意：这些示例是用 C# 编写的，因为这是我更熟悉的，但这个概念应该同样适用于 Java。
忽略关于何时适合使用 Singleton 对象的争论，我知道的一个主要区别是 Singleton 对象有一个可以传递的实例。
如果您使用静态类，您将自己硬连接到特定实现，并且无法在运行时更改其行为。
使用静态类的糟糕设计：
public class MyClass
{
public void SomeMethod(string filename)
{
if (File.Exists(filename))
// do something
}
}
或者，您可以让构造函数接受特定接口的实例。在生产中，您可以使用该接口的 Singleton 实现，但在单元测试中，您可以简单地模拟接口并更改其行为以满足您的需求（例如，使其抛出一些模糊的异常）。
public class MyClass
{
private IFileSystem m_fileSystem;
public MyClass(IFileSystem fileSystem)
{
m_fileSystem = fileSystem;
}
public void SomeMethod(string filename)
{
if (m_fileSystem.FileExists(filename))
// do something
}
}
这并不是说静态类总是不好的，只是不适合文件系统、数据库连接和其他低层依赖项。
【讨论】：
单例的主要优点之一是您可以实现接口并从其他类继承。有时你有一组单例，它们都提供类似的功能，你想实现一个公共接口，但负责不同的资源。
【讨论】：
单例类： 单例类是每个类加载器只能存在单个实例的类。
助手类（只有静态字段/方法的类）： 不存在此类的实例。只有字段和方法可以作为常量或辅助方法直接访问。
blog 中的这几行很好地描述了它：
首先，单例模式非常 如果你想创建一个很有用 类的实例。为了我的帮手 我们真的不想上课 实例化类的任何副本。 你不应该使用的原因 单例类是因为这个 我们不使用任何辅助类 变量。单例类将 如果它包含一组 我们只想要一组的变量 和使用的方法 变量，但在我们的帮助类中，我们 除了 传入的（我们将其设为最终版本）。 因此，我不相信我们 想要一个单例实例，因为我们 不想要任何变量，我们不想要 希望任何人实例化这个类。 所以如果你不想要任何人 实例化类，即 通常如果你有某种 helper/utils 类然后我使用什么 我称静态类，一个类 一个私有构造函数，并且只有 由无任何静态方法组成 任何变量。
【讨论】：