一个名为“User”的类应该是单例模式的实现吗？答案

【问题标题】：Should a class named `User` be an implementation of Singleton Pattern?一个名为“User”的类应该是单例模式的实现吗？
【发布时间】：2016-10-04 05:42:59
【问题描述】：

今天看了很多关于Singleton Pattern的不好的文章，比如

违反单一责任原则
无法继承
无法使用抽象类或接口类
跨应用程序的高耦合
使单元测试变得困难

然后我记得我有一个程序，它有一个名为User 的类，其中有userName 和password 字段以及与User 相关的其他内容。在我的设想中，该程序应该只有一个用户实例，它是在人类登录我的程序时创建的。基于此，我应该坚持将User 类设计为单例模式，还是应该使用任何好的设计理念？

补充：

另一个疑问。使用单例模式，我可以在任何地方获得唯一的实例myUser。如果我不应该使用 Singletion Pattern，我应该如何获得唯一的实例myUser？

【问题讨论】：

除非小猫死去，否则您通常不需要强制执行单个实例并提供对其的全局访问。您控制您的应用程序对象，因此只需创建用户一次且仅一次。同样，当您使用依赖注入时，通常不需要对对象的全局访问。
提示：我会首先为该类找到一个新名称； User 类应该只有一个实例是非常违反直觉的。换句话说：为所有用户设置一个类用户不是更有意义吗？和一个名为 CurrentUser 或类似的特殊类（甚至可能是单例）？！
@GhostCat 好建议，谢谢。

标签： oop design-patterns singleton

【解决方案1】：

您可能想查看dependency injection。如今，存在许多框架来帮助您连接依赖注入，以便您可以在框架中指定您希望某个对象表现得像一个单例。换句话说，如果另一个对象也需要相同的“单例”对象，则框架不应该创建新实例，而是“注入”已经存在的实例。

如果您使用 Java 进行开发，您可以看看 Guice 的做法：https://github.com/google/guice/wiki/Scopes 它们允许您指定是要创建“急切的单例”（即使还不需要创建）还是“懒惰的”单例”（仅在需要时动态创建）。即使您不使用 Java，其他编程语言也有类似的概念，您可以留意。

我的建议是让“用户”对象不是单例，并将“用户”对象“注入”到需要“用户”对象的类中。如果可能，让您选择的依赖注入框架来处理连接，这样您就不会意外创建多个实例。

这样，您仍然能够实现您在问题中发布的大部分上述优势，并且仍然享受“单身”的好处。

【讨论】：

【解决方案2】：

这取决于您的上下文。如果您的应用程序必须只有一个用户，则使用单例模式。您提到的 5 点将完全适得其反。

在您的示例中，情况并非如此。但是对于一个进程的执行，只有一个且只有一个实例是强制性的。那么您应该考虑@Koning 的响应。

例如，Spring security 实现了一些使用静态方法记录用户的常见模式：

SecurityContextHolder.getContext(). getAuthentication()

【讨论】：

【解决方案3】：

如果您查看 Microsoft 成员资格，您会发现他们在会话级别存储所有数据。我认为实现这种将存储在所有会话级别的逻辑的最佳方式是单例模式，因为您不需要两个类来处理用户数据。作为替代方案，您可以使用静态类，但在这种情况下您无法序列化您的用户数据

【讨论】：