c# - 我想要一个单例的设计替代方案

Question

我意识到有很多关于单例的讨论以及它为什么不好。这不是这个问题的意思。我了解单例的缺点。

我有一个场景，其中使用单例很容易并且看起来很有意义。但是，我想要一个替代方案，它可以在没有大量开销的情况下完成我的需要。

我们的应用程序设计为客户端，通常在现场的笔记本电脑上运行并与后端服务器通信。我们在主应用程序的底部有一个状态栏。它包含一些显示各种雕像和信息的文本区域以及几个图标。图标会更改其图像以指示其状态。例如 GPS 图标，指示是否已连接以及错误状态。

我们的主类称为 MobileMain。它拥有状态栏区域并负责创建它。然后我们有一个 StatusBarManager 类。 StatusBarManager 目前是一个静态类，但也可以是一个单例。这是类(class)的开始。

public static class StatusBarManager
{
    static ScreenStatusBar StatusBar;

    /// <summary>
    /// Creates the status bar that it manages and returns it.
    /// </summary>
    public static ScreenStatusBar CreateStatusBar()
    {
        StatusBar = new ScreenStatusBar();
        return StatusBar;
    }

MobileMain 向 StatusBarManager 请求 StatusBar。然后它使用 StatusBar。没有其他类看到 StatusBar，只有 StatusBarManager。

状态栏的更新几乎可以来自应用程序的任何地方。大约有 20 个类可以更新状态栏上的文本区域，还有其他类可以更新图标状态。

只会有一个 StatusBar 和一个 StatusBarManager。

有什么更好的实现建议吗？

我的一些想法:

使 StatusBarManager 成为一个实例类。在我的 MobileMain 类中，持有 StatusBarManager 类的静态公共(public)实例。然后要进行状态栏更新，您可以调用 MobileMain.StatusBarManager.SetInformationText 或管理器的其他一些方法。 StatusBarManager 不会是单例，但 MobileMain 只会创建它的静态实例。这里的问题是 MobileMain 现在有一个 StatusBar 和一个 StatusBarManager，它只管理它拥有的 StatusBar。 StatusBarManager 仍然有一个全局可用的静态实例，只是所有者不同。

另一个想法是使用类似 EventEggregator 类的东西。我从来没有用过，但读过它们。我想这个概念是它将是一个全局可用的类。在每个想要更新状态栏的类中，它将发布一个 StatusBarUpdate 事件。 StatusBarManager 将是唯一订阅 StatusBarUpdate 事件并接收所有通知的类。我已经读过，如果您在清理对象时不小心取消订阅事件，那么这种方法可能会导致泄漏。这种方法值得研究吗？

Answer 1

我更喜欢保存对象的静态类。因此，您可以访问的对象数量取决于您的静态类提供的接口(interface)。只要您的应用程序仍然可以扩展，静态就不错。

单例的另一个很好的替代方案是 Monostate 模式，其中您有一个类实现私有(private)静态字段来表示“单例”行为。

参见:
Monostate
Monostate vs. Singleton

更新:它经常帮助我牢记 REST 之类的 api，即使对于内部程序结构也是如此。拥有一个从任何地方更新并向每个人发送通知的类在引发条件和无限循环方面很难控制(更新 -> 事件 -> 更新 -> ...)

构建一个(静态或非静态)状态栏界面，您可以在需要的地方访问它。通过一个静态类，您可以在其中访问您的状态栏界面，或者如果您使用此类技术则通过依赖注入(inject)(不推荐用于较小的项目)。对状态栏界面的每次调用都必须独立于状态栏可能引发的任何事件，以避免引发条件的进一步问题。将状态栏界面想象成一个网站，可以从程序的其他部分调用以推送和拉取信息。