我正在考虑在我正在开发的 winforms 应用程序中使用单例模式，但很多人似乎认为单例是邪恶的。我正计划制作一个单例的“主菜单”表单。我想不出有什么理由需要我的主菜单的多个实例，而且它总是出现的第一个表单，所以如果它被不必要地实例化，我不担心浪费资源。
此外，如果主菜单有多个实例，我可能会看到问题。例如，如果另一个表单有一个“主菜单”按钮并且有多个主菜单实例，那么显示哪个实例的决定似乎是模棱两可的。
另外，如果我有另一个必须查看程序状态以确定是否已经存在主菜单实例的 winform，那么我觉得我正在破坏模块化，尽管我可能错了。
在这种情况下我应该避免使用单例还是将主菜单设为静态会更好？
几天前我才开始使用 c#，在过去的几年里我并没有真正用 OOP 做太多事情，所以如果这是一个愚蠢的问题，我深表歉意。
谢谢
人们喜欢全局状态。这显然很容易理解，对我们来说很有意义。您不必担心您使用的是哪个版本，因为它们都是相同的。
但是全局状态会引入各种奇怪的错误，因此通常不鼓励。C# 做出了许多设计决策，以使全局状态更难被遗漏。例如，您只允许将静态变量附加到必须管理它们的类。
单例是获得这种全局状态的另一种方式，但是它们的相似之处在于它们可能会导致问题。如果您的一个屏幕设置了主菜单的一部分然后转换到它，而没有意识到后台进程取消了更改，导致显示奇怪的主菜单怎么办？
单例的另一种替代方法是确保变量到达需要它们的位置。这样做的一种方法是跟踪一堆菜单，实际上 Android 在下面就是这样工作的。每个 UI 都有一组位于其上方的父级，如果它想返回，它可以切换到这些父级。通过确保只有您的初始启动过程创建初始主菜单屏幕，您可以保证只创建一个，但是所有屏幕仍然可以通过检查层次结构来访问它。
此外，如果您谈论的是 winform，它们已经内置了一个层次结构系统，您可以使用它来提供此功能。
MainMenu一直显示？如果没有，那么在旧实例关闭时释放它并在每次需要打开它时创建一个新实例是有意义的。这样其他模块就不需要知道它的实例，他们只需在需要打开它时创建一个。
你几乎可以滥用一切。
单例是一种确保在任何时候只有一个对象实例处于活动状态，并且您可以同步访问它的方法。使用静态类，您将失去这一点，因为任何人都可以随时访问静态类，因此您需要确保您的方法不会做任何可能受并发影响的事情。
除此之外，如果我没看错的话，你想要一个作为父表单的表单来拥有你的菜单的唯一实例，而所有其他表单都是这个表单的子表单。如果是这种情况，那么您应该检查 Winforms 中的 MDI（多文档界面），因为这将恰好涵盖您的场景。
否则，我要做的只是为我的父表单（带有主菜单的那个）定义一个类，并让一个单例公开访问它，并为所有子表单使用另一个基类。