【问题标题】:Implementing a Subsystem Communication Design Pattern实现子系统通信设计模式
【发布时间】:2012-02-16 20:46:39
【问题描述】:

我正在为以下内容寻找合适的设计模式:

我的系统结构如下:

MainApplication
    SubSystem1
    SubSystem2
    SubSystem3

MainApplication 在哪里初始化每个子系统,

    SubSystem1 s1;
    SubSystem2 s2;
    SubSystem3 s3;

    public MainApplication()
    {
        s1 = new SubSystem1();
        s2 = new SubSystem2();
        s3 = new SubSystem3();
    }

每个子系统应该能够相互通信。

在每个子系统中如何调用另一个子系统的方法?例如s1

    public SubSystem1()
    {
        s2.Method1();
        s3.Method2();
    }

外观设计模式在这里可以使用吗?如果是这样,它将如何实施?如果不是这种情况应该使用哪种设计模式?

【问题讨论】:

  • 通讯的扩展是什么?是基于事件的性质还是子系统 1 执行 x,因此子系统 2 也需要执行 y?
  • 目前是后者。虽然,使用事件听起来是一个不错的解决方案。你能扩展一下吗?
  • 好吧,如果它是基于事件的,比如哦,音乐就传来了。您可以使用事件(内置 .net)订阅事件并根据需要让每个子系统进程。这将防止子系统必须相互了解。

标签: c# design-patterns facade


【解决方案1】:

这在很大程度上取决于子系统之间的通信类型。

如果它是抽象的,即子系统实际上不必相互了解,基于发布-订阅的消息传递机制可能是合适的。有关介绍,请参阅 https://en.wikipedia.org/wiki/Publish/subscribe,但我认为这个概念应该相当简单。

另一方面,如果子系统确实必须以具体的方式相互了解,那么为什么它们首先是子系统?进行这种划分表明确实存在关注点分离,因此找到抽象接口应该不难。如果是,也许您应该重新考虑您的子系统职责。

【讨论】:

    【解决方案2】:

    我从来不记得设计模式的名称。为什么不能让每个子系统知道其他子系统?

    s1.SetSubsystem2(s2);
    s1.SetSubsystem3(s3); 
    ...
    

    如果您想更加适应未来的变化,请在 interface 中描述每个子系统的接口,并确保 SetSubsystemX 采用该接口,而不是具体类。

    编辑:界面示例。

    假设您的第一个子系统知道如何发送电子邮件,第二个子系统知道如何打印文件。你应该声明两个接口:

    interface IEmailSubsystem
    {
        void SendEmail(string content);
    }
    
    interface IPrintSubsystem
    {
        void PrintFile(string path);
    }
    

    然后你可以定义你的两个子系统对象:

    class Subsystem1: IEmailSubsystem ...
    class Subsystem2: IPrintSubsystem ...
    

    如果您最终需要超过 3 个子系统,您应该有一个全局子系统注册表,但暂时不要担心。

    【讨论】:

    • 所以从MainApplication 我们将子系统对象发送到每个子系统?有趣的。我有兴趣使用您提到的界面,您可以扩展您的答案以显示示例吗?谢谢。
    • 如果这是一个好的解决方案,添加和删除接口子系统的列表会比保存子系统的 n 个变量更好。
    猜你喜欢
    • 1970-01-01
    • 2010-11-21
    • 1970-01-01
    • 2013-12-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-12-04
    • 2012-07-04
    相关资源
    最近更新 更多