我想要一个替代单身的设计

Question

我意识到有很多关于单身人士的讨论以及为什么那些不好.这不是这个问题的意思.我理解单身人士的弊端.

我有一个场景,使用单例很容易,看起来很有意义.但是,我想要一种能够在没有大量开销的情况下完成我需要的替代方案.

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

我们的主要类叫做MobileMain.它拥有状态栏区域并负责创建它.然后我们有一个StatusBarManager类.StatusBarManager当前是一个静态类,但也可以是一个单例.这是课程的开始.

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类的静态公共实例.然后,要进行状态栏更新,您可以调用MobileMain.StatusBarManager.SetInformationText或管理器的其他方法.StatusBarManager不是单例,但MobileMain只会创建它的静态实例.这里的问题是MobileMain现在有一个StatusBar和一个StatusBarManager,它只管理它拥有的StatusBar.还有一个全局avaialble静态实例到StatusBarManager,只是一个不同的所有者.

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

Answer 1

是否有 StatusBar 类或 StatusBarManager 类并不是什么大问题。但是，让应用程序中的许多类了解 StatusBars 和 StatusBarManagers 是一个坏主意，它会导致强耦合，有一天可能会带来痛苦。

如何？

想象一下，当前向状态栏报告状态的组件必须在另一个使用文本控制台报告状态的应用程序中重用？- 向多个地方报告状态？或者 - 根本不报告状态！

最佳选择： - 事件监听。在您的类上公开 Status Changed 事件（您可以使用回调），或者在您的类共有的现有共享资源上公开一个 Status Changed 事件。其他方（例如您的状态栏）可以订阅该事件。并且应在订阅不再需要/有效时取消订阅，以防止泄漏，正如您提到的！

-既然您已经标记了 WPF，对于 WPF，具有依赖属性“StatusText”可能看起来是另一个诱人的选择，使用这种方法，当您有多个状态属性时，您需要一种方法来找出哪个属性告诉您最多的信息现在需要在状态栏上显示有趣的状态！这可能是绑定、多重绑定（blech、复杂性）或依赖属性更改的事件处理程序。

但是 - 我建议您尽可能将 DependencyObjects 和 DependencyProperties 限制在您的 UI 层。原因是它们隐式依赖于 UI 线程上的 Dispatcher，因此无法轻松适应非 UI 任务。

由于您的应用程序有许多不同的部分，您可能还会发现将这两者结合起来是合理的，使用一个地方和另一个地方。