實現一個子系統通信設計模式

我有以下的體系結構：

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(); 
    }

門面設計模式會在這裏工作嗎？如果是這樣，它將如何實施？如果沒有這種設計模式應該用於這種情況？

來源

2012-02-16 Ryan R

溝通的延伸是什麼？它是基於事件的本質還是子系統1確實是x，因此子系統2也需要y？ – 2012-02-16 21:08:30

目前，它是後者。儘管使用事件聽起來像一個很好的解決方案。你可以擴展這個嗎？ – 2012-02-16 21:10:56

那麼，如果這將是基於事件的基礎，如哦音樂來自電線。您可以使用事件（內置.net）訂閱事件，並根據需要爲每個子系統處理。這將阻止子系統必須彼此瞭解。 – 2012-02-16 21:20:08

這很大程度上取決於子系統之間的通信類型。

如果它是抽象的，即子系統實際上不必知道彼此，基於發佈 - 訂閱的消息機制可能是合適的。有關引言，請參閱https://en.wikipedia.org/wiki/Publish/subscribe，但我認爲該概念應該相當簡單。

另一方面，如果子系統真的必須以具體的方式彼此認識，爲什麼他們的子系統是第一位的？進行這種劃分表明確實存在關注的分離，因此找到一個抽象接口應該不那麼難。如果是這樣，也許你應該重新考慮你的子系統的責任。

來源

2012-02-16 21:23:42 theDmi

我永遠不會記得設計模式名稱。爲什麼你不能讓每個子系統知道其他子系統？

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個子系統多，你應該有一個全球性的子系統註冊表，但現在不用擔心。

來源

2012-02-16 21:01:31 zmbq

因此，從'MainApplication'我們會發送子系統對象到每個子系統？有趣。我有興趣使用你提到的界面，你可以擴展你的答案來展示一個例子嗎？謝謝。 – 2012-02-16 21:05:30

如果這是一個好的解決方案，那麼添加和刪除接口子系統的列表會更好，然後保存子系統的n個變量。 – 2012-02-16 21:06:24

實現一個子系統通信設計模式

回答

相關問題