跳到主要內容

轉接器模式 (Adapter Pattern)

        此模式從字面上來看應該不難理解,用現實生活中的例子來看,就好比出國時想讓自己帶的電器也能在國外用,但國外的插座孔跟電器插頭不同時要怎麼辦?有一個轉接頭就可以啦~

        以程式面來看,假如你有一個系統,希望它能和一家新廠商的 library 搭配使用,但新廠商的介面卻不同於舊廠商的介面。當不能或不想修改現有的程式碼時,就可以寫一個類別,將新廠商的介面轉換成你所希望的介面。

        接下來看點程式碼吧。這裡使用策略模式中使用的鴨子類別,並新增一組火雞類別:
// 鴨子介面
public interface Duck {

    public void quack();
    public void fly();
}

// 綠頭鴨是鴨子的次類別
public class MallardDuck implements Duck {

    @Override
    public void quack()
    {
        System.out.println("Quack");
    }

    @Override
    public void fly()
    {
        System.out.println("I'm flying");
    }
}

// 火雞介面
public interface Turkey {

    // 火雞只會喀喀叫
    public void gobble();
    public void fly();
}

public class WildTurkey implements Turkey {

    @Override
    public void gobble()
    {
        System.out.println("Gobble gobble");
    }

    @Override
    public void fly()
    {
        System.out.println("I'm flying a short distance");
    }
}

        當你想用火雞物件來假裝成鴨子物件,四筒扮五筒,很明顯因為兩邊介面不同不能直接用時,就寫個轉接器吧:
// 轉接器要實作要轉換的型態,
// 也就是你的客戶所希望看到的介面
public class TurkeyAdapter implements Duck {

    private Turkey mTurkey;

    // 需要取得被轉換者的物件參考
    // 範例是利用建構者取得
    public TurkeyAdapter(Turkey turkey)
    {
        mTurkey = turkey;
    }

    // 實作介面的方法,並把方法都導向
    // 使用被轉接者提供的方法
    @Override
    public void quack()
    {
        mTurkey.gobble();
    }

    @Override
    public void fly()
    {
        mTurkey.fly();
    }
}
        從上述的程式碼,我們可以理解:
  1. 客戶透過目標介面 (Duck) 呼叫轉接器的方法,如 TurkeyAdapter.fly(),對轉接器發出要求。
  2. 轉接器透過被轉接者介面 (Turkey),呼叫被轉接者的方法,將請求轉給被轉接者。
  3. 客戶接收到呼叫的結果,不會發現這一切都是透過轉接器居中聯繫。
        看到這裡可能有人會有疑問,假如系統中新舊並存時應該怎麼辦呢?只要建立一個雙向的轉接器,支援兩邊的介面即可。當然這就需要實作兩邊介面的所有方法。接下來我們就來看正式的轉接器模式定義及類別圖吧:

轉接器模式將一個類別的介面,轉換成別一個介面以供客戶使用。轉接器讓原本介面不相容的類別可以合作無間。
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.



        此模式充滿著良好的 OO 設計守則:檢查使用的物件合成,並以修改的介面包裝被轉接者。這種作法還有額外的優點,就是被轉接者的任何次類別,都可以搭配轉接器使用。要注意,此模式是建立客戶和介面之間的關係,不是建立客戶和實作內容的關係。

        其實轉接器可以有兩種模式:「物件」轉接器跟「類別」轉接器,上面看到的是物件轉接器。而類別轉接器需要多重繼承才能實作它,雖然在 Java 中不可能實作類別轉接器,但我們還是能看看它的類別圖:


        其中主要的差異就是利用繼承被轉接者和目標類別,設計出類別轉接器。

參考資料:

        深入淺出設計模式(Head First Design Patterns)

留言

這個網誌中的熱門文章

訪問者模式 (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...

裝飾者模式 (Decorator Pattern)

        假如你有一間飲料店, 目前只有賣幾種咖啡。因為生意很好, 因此想更換菜單…         以下是目前菜單的類別圖:         簡單說明此類別圖, cost() 是抽象的, 子類別要實作自己的 cost() 來告知飲料的價格。         買咖啡時, 也可要求要加料, 例如牛奶(Milk)、摩卡(Mocha,就是巧克力口味)。這樣的新類別要如何設計呢 ? 看起來是不能直接新增所需的子類別, 例如 EspressoWithMilk, EspressoWithMilkAndMocha, DarkRoastWithMilk, DarkRoastWithMilkAndMocha… 這樣加下去, 日後飲料跟配料越來越多時, 類別也就越多, 這實在不是個好設計。         換個方式設計呢, 在 Beverage 裡面加入所有的配料如何 ? 這樣好像也不太好, 未來要是配料有更動, Beverage 程式碼就要重寫, 而未來要是有新口味的飲料時, 有些配料就不太合理 ( 薑茶加摩卡 ? ), 更麻煩的是, 無法應付機車的客人 (例如要加 3 份牛奶)。這時候裝飾者模式就能上場啦。在介紹裝飾者模式前, 先說明其設計守則: 類別應該開放, 以便擴充 ; 應該關閉, 禁止修改。         我們的目標是允許類別容易擴充, 在不修改現有程式碼的情形就能搭配新的行為。這樣的設計具有彈性, 可以接受新功能以達到改變需求的目的。這看起來好像有點矛盾, 但是的確有一些技術可以在不直接修改程式碼的情形下進行擴充, 如裝飾者模式。         這時候應該有人會問: 那是不是以後我的專案架構設計都遵循這個守則就是好設計了 ? 答案是不太可能, 也沒這必要, 就算做得到, 也可能是浪費, 容易導致程式碼複雜且難以理解。只需小心選擇哪些部分未來會擴充, 這些部份遵循這個設計守則即可。         接下來...

狀態模式 (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"); } ...