調解員模式或責任太多

Question

在我的應用程序中，我有幾個必須瞭解彼此的組件，例如菜單欄和工具欄，這兩個組件都需要知道表添加或刪除作業，以及找出選擇哪個工作。

因此，我創建了一個名爲guiMediator的對象，我傳遞給每個對象，並向它們註冊自己，以便它們可以使用該對象互相訪問。它還負責在添加新工作或後臺工作人員完成工作時觸發事件。

既然知道很多關於系統的知識，這種類型的用法在一個地方負有多少責任，或者這是模式的正確用法？

Answer 1

通常我會使用類似的東西在命令模式：

1. 用戶點擊「菜單欄上的「Foo」按鈕，該按鈕執行FooButtonClickedCommand。
2. FooButtonClickedCommand做它應該做的任何事情，然後適當地修改視圖（菜單欄，表格等）。

所以，你的命令知道你所有的視圖組件，但是你的視圖組件需要知道的唯一事情是當用戶完成一個給定的動作時執行哪個命令。

Answer 2

聽起來比選擇好......但是，嘿，我嫁給了醜陋的至少妹妹;-)

Answer 3

我會使用被動視圖，您可以閱讀有關here的信息。

• 你乾脆把每種形式的界面背後
• 每個窗體將與一個或多個UI註冊自己的對象
• 的UI對象要自然組織，如設置，輸入，顯示器等字處理器可能只有一個用於每個文檔的UI對象。機器控制器可能每個屏幕都有多個對象。
• 該接口被實現爲將事件傳遞給UI對象的細殼，並展示了表示控件，將表面繪製到UI對象。
• 然後，UIObject接受輸入並計算出要執行的命令對象
• 命令對象將更新模型，然後告訴一個或多個UI對象更新視圖。
• UIObjects更新視圖。

請注意，UI界面以外的任何地方都不瞭解按鈕，複選框等。您可以使用接口將實際實現抽象出來。

這會給你幾個好處。首先，它將記錄您的代碼如何與UI進行交互，爲您提供一個實現模擬對象以用於自動化測試的地方，並最終允許您更改UI的範圍。

例如，用可點擊的面板代替命令按鈕。然後，表單將從面板而不是按鈕開始傳遞點擊事件。表單可以不知道每個小部件應該執行的實際命令。 UI對象負責照顧。