跳到主要內容

中介者模式 (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 則留言
閱讀完整內容

代理人模式 (Proxy Pattern)

        代理人模式如同字面上的意思，就是做事情時(如取得某些資料)，是透過代理人，而不是直接跟提供資料的物件構通。先來看看此模式的正式定義及類別圖： 代理人模式讓某個物件具有一個替身，藉以控制外界對此物件的影響。 Provide a surrogate or placeholder for another object to control access to it.         從類別圖可以看到， Subject 是共用的介面，可以讓客戶 將 Proxy 物件視為 RealSubject 物件 來處理。RealSubject 是真正做事的物件，被 Proxy 代理， Proxy 可以控制 RealSubject 的存取 。Proxy 持有 RealSubject 的參考，客戶和 RealSubject 的互動都要透過 Proxy，在某些情形下這樣的限制是必要的，如 RealSubject 是遠端物件， RealSubject 建立成本高等等。         此模式有許多種變形，都是依據上面的原則而發展出來的。以下介紹  深入淺出設計模式(Head First Design Patterns) 裡面提到的一些應用方式：         1. 遠端代理人(Remote) ：算是最常使用到的應用方式。在網路中或是跨 Process 的各種程式，不可能直接存取(assess) 不同程式間的物件，因此就需要遠端代理人。 Java RMI  和 Android AIDL  都算是遠端代理人的實踐。         2. 虛擬代理人(Virtual) ：代理的對象是建立很花費資源的物件。當物件建立前和建立中，由虛擬代理人扮演代理的角色。物件建立完成後，代理人就會將讓求直接轉給物件。以下為簡單範例程式： // Proxy 實作跟 RealSubject 共同的介面 Icon public class ImageProxy implements Icon { // 這是我們的 RealSubje...
張貼留言
閱讀完整內容