将Singletons用于不可变的无参数类是否不好？

Question

我现在正在研究一个小型Java项目，在这样做的同时，在那里创建了多个代表某种Constant行为的类，例如用作其他方法的默认返回值。

现在所有这些共同点是它们是完全不变的，并且它们只有一个无参数构造函数。这意味着创建该类的多个实例将始终导致相同的对象。

每次使用这些类时最好只创建一个新实例吗？或者使用singelton模式是否可以接受这种情况？

Answer 1

假设您有一个小的项目和用作默认返回值的不可变类，请考虑一下单例的利弊。

专业人士在这种情况下：

• 应用程序构造一个对象而不是多个对象； 请记住，通常在Java中构造一个新对象是廉价的操作。 如果您的对象寿命不长，GC将收集它们，而不会对您的应用程序性能产生重大影响。如果您不必每秒创建数千个此类对象，则适用此方法。

缺点：

• 更多可读写的代码； 尽管编写getInstance()方法似乎没什么大不了，但是其他与您一起工作的人（可能）将花费一些时间来探索getInstance()在修正错误或仅理解某些业务逻辑时的实际作用。尽管它们具有常规名称，但我已经看到了许多令人惊讶的getInstance()方法。

• 潜在的并发问题； 即使您的项目很小，您也可能要利用多个线程。在这种情况下，您必须编写getInstance()作为同步方法，引入double-checked locking，使用枚举或其他方法。 即使您知道这种特殊性，也不能保证其他开发人员不会犯错。

因此，我认为没有一个正确的答案，这取决于您如何看待未来项目的发展。

Answer 2

在您的情况下，使用Singleton模式是有意义的。对于简单的应用程序，可以使用静态方法返回实例。如果您在提供控制反转的环境（例如Spring）中工作，则IOC框架将为您处理单例。

Answer 3

如果公开修改不可变类状态的方法，则必须始终返回该类的新实例。

Answer 4

即使在一个小型项目中，我也会努力遵守Dependency Inversion Principle，即，一个类不会实例化其自己的依赖关系，而是通常在构造函数中声明它们。这样，每个类都可以独立开发和测试，同时可以使用Spring或Guice或manual dependency injection之类的框架将所有其他类捆绑在一起。通过这样的设置，您可能只有一个相关的类实例，但是您无需实现经典的单例模式。

创建一个小项目是要进行正确的权衡：您不想过度设计，但也不想编写不可扩展和不可维护的代码。所以不，几乎没有任何有效的借口使用单例模式（由类加载器来保护单例）。