Oop 名为“User”的类是否应该是Singleton模式的实现？

今天我读了很多关于单例模式如何糟糕的文章，比如

违反单一责任原则

无法子类化

无法使用抽象类或接口类

跨应用程序的高耦合

使单元测试变得困难

然后我记得我有一个名为

User

的程序，它有字段

userName

和

password

以及与

User

相关的其他内容。在我的设想中，程序应该只有一个用户实例，这是在一个人登录我的程序时创建的。基于此，我应该坚持将设计

User

类作为单例模式，还是应该使用任何好的设计构思

---

补充：

---

另一个疑问。使用单例模式，我可以在任何地方获得唯一的实例

myUser

。如果我不应该使用Singleion模式，我应该如何获得唯一的实例

myUser

？

如果您查看Microsoft Membership，您会发现它们将所有数据存储在会话级别。我看到的实现这种逻辑的最好方法是单例模式，它将存储在所有会话级别上，因为您不需要两个类来处理用户数据。作为替代方案，您可以使用静态类，但在这种情况下无法序列化您的用户数据。现在有许多框架可以帮助您连接依赖注入，以便您可以在框架中指定您期望某个对象的行为类似于单例。换句话说，如果另一个对象也需要相同的“singleton”对象，那么框架不应该创建新实例，而应该“注入”已经存在的实例

例如，如果您使用Java开发，您可能会看到Guice的工作方式：它们允许您指定是要创建“渴望的单例”（即使还不需要也要创建）还是“懒惰的单例”（仅在需要时动态创建）。即使您不使用Java，其他编程语言也有类似的概念，您可以留意

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

---

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

这取决于您的背景。若您的应用程序必须有一个且只有一个用户，那个么使用单例模式。你提到的5点将完全适得其反

在你的例子中，情况并非如此。但是只有一个且只有一个实例对于一个进程的执行是必需的。你应该考虑@Koning的回应

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

SecurityContextHolder.getContext(). getAuthentication()

---

除非小猫死了，否则通常不需要强制执行单个实例并提供对它的全局访问。您可以控制应用程序对象，因此只需创建用户一次，而且只能创建一次。同样，当您使用依赖注入时，通常不需要全局访问对象；一个用户类应该只有一个实例，这是非常违反直觉的。换句话说：对于所有用户来说，拥有一个类用户不是更有意义吗；还有一个叫做CurrentUser之类的特殊类（甚至可能是单例类）@好建议，谢谢。