是否应该使用 Singleton 设计模式来实现用户界面？答案

【问题标题】：Should a user interface be implemented using the Singleton design pattern?是否应该使用 Singleton 设计模式来实现用户界面？
【发布时间】：2008-10-30 20:53:27
【问题描述】：

我想不出许多（或根本没有）应该在桌面应用程序中实例化多个独立用户界面的原因。将 UI 实现为单例是一种好习惯吗？这种方法有优点还是缺点？

【问题讨论】：

标签： design-patterns oop

【解决方案1】：

呃...我一直打开多个 Internet Explorer、Word 和 Excel 副本！

编辑：我还在 Eudora 中同时打开了几封电子邮件

我认为没有充分的理由将用户界面限制为单例...

【讨论】：

但是这些都是同一个过程吗？（老实说，我不知道）。如果它们不是，那么它们并不重要，因为单例是 process 本地
@[Evan Teran]：在 Windows MDI 应用程序中，同一表单的多个副本将位于同一进程中。对于 IE/Word/Excel，它们可能是不同的进程。应用程序的单例范围对我来说意味着“每台机器”，但您的里程可能会有所不同;-)
我刚刚打开了 3 个 word 2007 实例，但在我的进程 lsit 中只看到一个 winword.exe。
另外，标准的单例模式使用静态存储来定位唯一的实例，它是每个进程（或每个应用程序域，在 .NET 中），而不是每个机器

【解决方案2】：

我能想到几个：

1) 文档界面。如果您的应用程序处理文档，最好让每个文档都有自己的窗口。它使用户可以更轻松地使用操作系统的应用程序切换功能来安排他们的工作空间和在文档之间切换。许多 MDI 应用程序通过将多个文档关联到同一个窗口中来防止这种情况发生，这限制了多显示器场景中屏幕空间的可用性。

2) 视图。通常情况下，UI 背后数据的多个不同视图无法轻松组合在单个 UI 实例中。您无法始终预测用户希望同时看到哪些数据组合，因此最好让他们灵活地实例化多个 UI。

顺便说一句，值得注意的是，许多人认为 Singleton 是一种反模式。

【讨论】：

【解决方案3】：

单身能给你带来什么好处？您是否意识到这种模式的潜在问题（例如所有明显实现的多线程问题）？

在实践中，如果没有令人信服的理由使用它，您可能希望避免使用 Singleton。对于 UI，即使没有多次实例化，实际上也没有令人信服的理由。

【讨论】：

关于潜在问题，不，我在这个阶段还没有完全意识到。我仍然只是在设计模式的池中弄湿我的脚。感谢您的意见。

【解决方案4】：

单例是一个全局变量。您将其设为全局会鼓励您在所有其他类中引用您的控件（想象一下您的数据抽象层从数据库中获取名称/地址对，为了方便起见，在此处更新您的名称/地址文本框）结果代码是脆弱，依赖关系变得难以解决。只需将责任限制在某个类的某个子集上就容易多了。

【讨论】：

【解决方案5】：

您使用单例的情况是错误拥有多个对象类型的实例，而不是因为您想不出任何好的理由拥有多个实例。

【讨论】：