跳到主要內容

中介者模式 (Mediator Pattern)

        中介者模式，又稱栛調者模式，直接照字面上解釋，就是有一個中介者負責處理事情。因為有一個中介者可以負責事情，如處理、傳遞、通知，就可以簡化物件之間的溝通和控制制方式，進而降低物件之間的耦合性(相依性，依賴性)。

中介者模式定義一個可以封裝一組物件互動的物件，可以使物件不用直接互相引用而降低耦合性，且可以獨立改變物件之間的互動關係。


Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.



        類別圖中的 Colleague 相關類別，指的就是實際上要做事，彼此可能因為不同的需求而會有相依性的類別。ConcreteColleague 之間不會直接溝通，而是透過 Mediator。看到這邊，可以順便跟表象模式來做個比較。這兩個模式都同樣有管理一群類別的味道，但不同之處是在於 Client 的角度。表象模式中，Client 是不會直接跟物件們溝通，都是透過表象來做事。而中介者模式中，Client 還是可以直接跟物件們溝通，只不過中介者模式是強調的是物件們不會直接溝通。另外表象模式跟中介者模式都是很好的認識極少化守則(又稱迪米特法則)實踐，表象模式是把這個守則應用在 Client 跟要溝通的物件們，而中介者模式是把這個守則應用在物件們之間的溝通。

        接下來看個簡單的範例吧。假設你現在要設計一個 GUI 的登入畫面，有四個元件：可以讓使用者輸入帳號密碼的 EditText，顯示帳號或是密碼有問題的 TextView，以及可以讓使用者確定要登入的 Button。一般來說，當帳號密碼有問題，登入 Button 就不能按，且 TextView 可能需要顯示提示訊息。當沒有使用中介者模式時，這些元件可能彼此都要互相知道才能達到上述需求，但加入了中介者模式後： 
// Colleague 介面
public abstract class View {

    protected mediator mMediator;

    protected void setMediator(Mediator m)
    {
        mMediator = m;
 }

    public abstract void action();
}

public class TextView extends View {

    @Override
    public void action()
    {
        System.out.println("User touch TextView");
    }
}

public abstract class EditText extends View {

    @Override
    public void action()
    {
        System.out.println("User touch EditText");
 }
}

public class AccountEditText extends EditText {

    // 假設 EditText 有 text 改變的 callback
    @Override
    public void onTextChanged()
    {
        if(!isAccountValid())
        {
            mMediator.showAccountError();
        }
    }

    public boolean isAccountValid()
    {
        // 省略
    }
}

public class PasswordEditText extends EditText {

    // 假設 EditText 有 text 改變的 callback
    @Override
    public void onTextChanged()
    {
        if(!isPasswordValid())
        {
            mMediator.showPasswordError();
        }
    }

    public boolean isPasswordValid()
    {
        // 省略
    }
}

public class Button extends View {

    @Override
    public void action()
    {
        if(loginSuccess())
        {
            mMediator.loginSuccess();
        }
        else
        {
            mMediator.loginFail();
        }
    }
}

// Mediator 介面
public interface Mediator {

    void loginFail();
    void loginSuccess();
    void showAccountError();
    void showPasswordError();
}

// 實際的 Mediator 類別
// 負責處理使用者登入的不同情況的畫面顯示
public class LoginMediator implements Mediator {

    private TextView mHintView;
    private EditText mAccountView;
    private EditText mPasswordView;
    private Button mSubmitButton;

    public LoginMediator(TextView hintView, EditText accountView,
            EditText passwordView, Button submitButton)
    {
        mHintView = hintView;
        mAccountView = accountView;
        mPasswordView = passwordView;
        mSubmitButton = submitButton;
    }

    @Override
    public void loginFail()
    {
        // 登入失敗時, 提示使用者,
        // 並把帳號密碼清空
        mHintView.setText("Login failed");
        mSubmitButton.setEnabled(true);
        mAccountView.setText("");
        mPasswordView.setText("");
    }

    @Override
    public void loginFail()
    {
        // 可能跳到其他畫面,
        // 這個畫面可以不做事
        mHintView.setText("Login success");
    }

    @Override
    public void showAccountError()
    {
        // 帳號有問題, 提示使用者,
        // 並讓登入按鈕不能按
        mHintView.setText("User account error");
        mSubmitButton.setEnabled(false);
        mAccountView.setText("");
    }

    @Override
    public void showPasswordError()
    {
        // 密碼有問題, 提示使用者,
        // 並讓登入按鈕不能按
        mHintView.setText("User account error");
        mSubmitButton.setEnabled(false);
        mPasswordView.setText("");
    }
}

public class MediatorDemo {

    Mediator mMediator;

    public static void main(String[] args)
    {
        // 實例化所需 GUI 元件, 這邊參考就好
        TextView hintView = new TextView(...);
        EditText accountView = new AccountEditText(...);
        EditText passwordView = new PasswordEditText(...);
        Button submitView = new Button(...);

        mMediator = new LoginMediator(hintView, accountView,
                                      passwordView, submitView);

        hintView.setMediator(mMediator);
        accountView.setMediator(mMediator);
        passwordView.setMediator(mMediator);
        submitView.setMediator(mMediator);

        // 等待 GUI 事件...
    }

    // 假設我們有設定元件 touch 的 callback
    @Override
    public void onViewClicked(View view)
    {
        view.action();
    }
}
        可以看出上面的程式碼，各個元件不用知道彼此的情形，只要專心處理自己的事，元件之間所需要的互動就交給 Mediator 來負責就好。

        最後來總結一下中介者模式的優缺點。由上面的介紹可以知道，此模式最大的用意就是讓物件可以彼此鬆綁，進而增加物件的再利用。，而把控制邏輯集中管理 (都由 Mediator 處理)，可以簡化系統維護。但要是中介者本身設計不好的話，中介者本身會很複雜。

參考資料:

        深入淺出設計模式(Head First Design Patterns)
        Mediator 模式
標籤：

留言

張貼留言

這個網誌中的熱門文章

訪問者模式 (Visitor Pattern)

        假設你設計一個系統，其中會有一些相似類別，類別中都有某些方法內容相似，但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情，在 Java 中最直接的做法就是使用 instanceof 關鍵字來判斷，如以下的簡單範例： public interface CarComponent { public void printMessage(); } public class Wheel implements CarComponent { @Override public void printMessage() { System.out.println("This is a wheel"); } // 這是 Wheel 跟 Engine 不同的方法 public void doWheel() { System.out.println("Checking wheel..."); } } public class Engine implements CarComponent { @Override public void printMessage() { System.out.println("This is a engine"); } // 這是 Wheel 跟 Engine 不同的方法 public void doEngine() { System.out.println("Testing this engine..."); } } public class Car { private List mComponents; public Car() { mComponents = new ArrayList<carcomponent>(); } // 有些時候我們還是需要針對不同類別去做不同的事情 public void setComponent(CarCompon...
1 則留言
閱讀完整內容

解譯器模式 (Interpreter Pattern)

        解譯器模式簡單來說就是 把一句有特殊規則的語句，透過解釋器將它真正的意思表現出來 。相信有學過 Context-free grammar (CFG)，Backus–Naur form (BNF)，或是 Compiler 相關程的人會比較了解這個模式 (不是我，我早就忘光了…)。不知道上面術語的人，還是可以透過接下來的介紹來稍微了解這個模式。先來看一下這個模式的正式定義及類別圖： 定義一個語言與其文法，使用一個解譯器來表示這個語言的敘述 Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language Context 通常是指待解譯的語句 AbstractExpression 是所有規則都要實作的介面 TerminalExpression 是指無法再展開的規則，算是最小單位的規則 NonterminalExpression 是指可以再展開的規則，可以展開成 NonterninalExpression 和 TerminalExpression 的組合         從類別圖可以看到，語法可能可以一直展開，這時就可以用語法樹來表示，而語法樹以程式來表達的話，就可以使用 合成模式 。而通常比較正式的語法會用 BNF 來表示，如下： expression ::= plus | minus | variable | number plus ::= expression expression '+' minus ::= expression expression '-' variable ::= 'a' | 'b' | 'c' | ... | 'z' digit = '0' | '1' | ... | '9' number ::= digit | digit number 而 每個語法都會定義一個類別 ，如 pl...
2 則留言
閱讀完整內容

狀態模式 (State Pattern)

        如果今天你要設計一台如下圖的糖果機，你會怎麼設計呢？         有上過資訊相關課程的人，應該不難從上圖聯想到 狀態圖 ，上圖中每個圓圈都是一個狀態，而每個箭頭就代表狀態的轉換。有了這個概念後，把它轉成程式就不難了： public class CandyMachine { // 以下四個值表示糖果機會用到的狀態 final static int SOLD_OUT = 0; final static int NO_COIN = 1; final static int HAS_COIN = 2; final static int SOLD = 3; // 需要有一個變數來記錄目前的狀態 // 初始設為賣完, 因為一開始機器裡沒糖果 int mState = SOLD_OUT; // 也要有另一個變數記錄目前剩多少顆糖果 int mCount = 0; public CandyMachine(int count) { mCount = count; // 機器內有糖果的話就跳到沒投錢的狀態, // 表示糖果機在等人投錢 if(mCount > 0) { mState = NO_COIN; } } // 當投錢時會執行這個方法 public void insertCoin() { if(mState == HAS_COIN) { System.out.println("You can't insert another coin"); } else if(mState == NO_COIN) { mState == HAS_COIN; System.out.println("You inserted a coin"); } ...
3 則留言
閱讀完整內容