c# - 需要帮助避免使用单例

Question

我并不讨厌单例，但我知道他们会受到虐待，因此我想学会避免在不需要时使用他们。

我正在开发跨平台应用程序(Windows XP/Vista/7、Windows Mobile 6.x、Windows CE5、Windows CE6)。作为该过程的一部分，我将代码重构到单独的项目中，以减少代码重复，从而有机会修复初始系统的错误。

要分离的应用程序的一个这样的部分非常简单，它是一个配置文件管理器。该项目负责存储配置文件。它有一个 Profile 类，其中包含应用程序所有部分使用的一些配置数据。它有一个 ProfileManager 类，其中包含 Profiles。 ProfileManager 将读取/保存 Profiles 作为硬盘驱动器上的单独 XML 文件，并允许应用程序检索和设置“事件的”Profile。简单。

在第一个内部构建中，GUI 是反模式 SmartGUI。这是一个没有完成 MVC/MVP 的 WinForms 实现，因为我们希望它能更快地工作而不是精心设计。这导致 ProfileManager 成为单例。这是从应用程序的任何地方，GUI 可以访问事件的 Profile。

这意味着我可以根据需要转到 ProfileManager.Instance.ActiveProfile 来检索系统不同部分的配置。每个 GUI 还可以更改配置文件，因此每个 GUI 都有一个保存按钮，因此它们都可以访问 ProfileManager.Instance.SaveActiveProfile() 方法。

我看不出这里使用单例有什么问题，因为我看不出其中有什么问题，但我知道单例并不理想。 有没有更好的方法来处理这个问题？是否应该将 ProfileManager 的实例传递给每个 Controller/Presenter？创建 ProfileManager 时，是否应该制作其他核心组件并在配置文件更改时注册到事件。该示例非常简单，并且可能是许多系统中的一个共同特征，因此认为这是学习如何避免单例的好地方。

附言我必须针对 Compact Framework 3.5 构建应用程序，它确实限制了很多可以使用的普通 .Net Framework 类。

Answer 1

单例遭到诽谤的原因之一是它们通常充当全局、共享且有时可变状态的容器。当您的应用程序确实需要访问全局共享状态时，单例是一个很好的抽象:需要访问麦克风或音频播放的移动应用程序需要对此进行协调，例如，因为只有一组扬声器。

对于您的应用程序，您有一个单一的“事件”配置文件，应用程序的不同部分需要能够修改。我认为您需要确定用户的个人资料是否真正适合这种抽象。鉴于配置文件的表现形式是磁盘上的单个 XML 文件，我认为作为一个单独的文件很好。

不过，我确实认为您应该使用依赖注入(inject)或工厂模式来获取配置文件管理器。您只需要为需要使用配置文件的类编写单元测试即可了解对此的需求；您希望能够在运行时传入以编程方式创建的配置文件，否则您的代码将与磁盘上某处的某个 XML 文件紧密耦合。