Design Pattern murmur

        假設你設計一個系統，其中會有一些相似類別，類別中都有某些方法內容相似，但還是需要判斷目前要做事的是哪個類別才能呼叫對應的適當類別。通常遇到這種情情，在 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...

        原型模式，光看字面上的意思很難了解這在幹麻，我們直接先來看正式定義及類別圖： (中文好難翻譯，我不會…) Specify the kind of objects to create using a prototypical instance, and create new objects by copying this prototype.         從定義上我們大概可以知道，這個模式的用途是讓我們可以 透過複製的方式產生一個新物件 。可是產生物件幹麻要這麼麻煩，不是直接 new 出一個新物件就好了嗎? 還是一句老話： 有時建立物件的代價很高 。假如你所需要建立的物件，其所需的資料是放在遠端資料庫的，這樣當每建立一個物件，就要讀取資料庫一次，這其實是很花成本的。         從類別圖我們可以看到，有一個公開的介面 Prototype，其子類別都需要實作 clone。而 client 這邊在取得物件時，不是透過 new 的方式，而是使用 clone() 來取得所需的物件。因此我們可以知道，此模式的重點在於 client 的程式碼可以在不知道特定類別為何的情形下可以生成新的物件 。         接下來來看簡單的範例程式碼吧。在 Java 中，每個類別都繼承了 Object 這個類別，表示每個類別都含有 clone() 這個方法。但是要讓 clone() 能動，類別還必須實作 java.lang.Cloneable 這個標籤介面( Tag Interface，Marker Interface )。除了這點之外，還要注意你的 clone() 是想要淺層複製 (shallow copy) 還是深層複製 (deep copy)。 // 在 Java, 要實作 Cloneable // 才能 override Object 的 clone() 方法 public class SomeObj implements Cloneable { // 某個 primitive type 成員, // shallow copy 可以複製值 ...

        備忘錄模式的用途很單純，就是 提供物件回到之前狀態的功能，簡單說就是備份 (存檔) 的機制 。備忘錄模式是一個在現實世界中很常使用到的模式，如遊戲的儲存記錄，文書編輯器的「上一步」功能等。簡單介紹完這個模式後，就來看一下正式的定義及類別圖吧： 不違反封裝的情形下，取得物件的內部狀態。如此可以回復物件之前的狀態。 Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later. Originator：就是定義中提到的要保留內部狀態的物件。現實例子就像是遊戲角色狀態，或是文書編輯器中的文字等。 Memento：保留 Originator 內部狀態 (資料) 的物件，例如遊戲中要存檔的資料。 Caretaker：主要功用是管理 Memento 物件。         看上面的介紹，可能有人會有疑惑，為什麼不要 Originator 自己處理存檔功能就好，還要花心力額外獨立出存檔跟管理存檔的物件？這樣做的目的其實是為了讓 類別的權責單一化(單一責任守則：一個類別應該只有一個改變的理由。) 。以生活中的例子來說，不把遊戲記錄檔獨立出來，你要怎麼拿到你朋友的超強記錄呢XD 而且 Caretaker 能管理的不是只有一個 Memento 物件，就好比文書編輯器通常不可能只「上一步」一次，要是把處理多個狀態的功能，以及保留目前狀態的功能，都放在 Originator，Originator 功能會太複雜，未來也不好維護。         看到這邊，我們應該能知道備忘錄模式有兩個目標： 儲存物件的重要狀態 維護物件的封裝         接下來來看簡單的程式碼來看備忘錄模式是如何運作的： // Originator public class GamePlayer { // 遊戲角色的生命值 private int mHp; ...

        中介者模式，又稱栛調者模式，直接照字面上解釋，就是有一個中介者負責處理事情。因為有一個 中介者可以負責事情，如處理、傳遞、通知，就可以簡化物件之間的溝通和控制制方式，進而降低物件之間的耦合性 (相依性，依賴性)。 中介者模式定義一個可以封裝一組物件互動的物件，可以使物件不用直接互相引用而降低耦合性，且可以獨立改變物件之間的互動關係。 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 可能需要顯示提示訊息。當沒有使用中介者模式時，這些元件可能彼此都要...

        解譯器模式簡單來說就是 把一句有特殊規則的語句，透過解釋器將它真正的意思表現出來 。相信有學過 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...

        享元模式，又稱蠅量級模式 (Flyweight 是拳擊術語，指最輕量的級別，蠅量級)，單看文字可能有點難理解，但簡單來說就是 共享元件(資源) 。試想一個情節：公司裡每個人都會有員工資訊，也都會有名片。假設名片是個類別時，對於每個員工，都需要 new 出名片的實體，而實際上名片裡也只是內容不同而已。當 員工越多時，就需要 new 出越多名片物件，造成記憶體浪費 ，這時候就適合使用享元模式。以下為享元模式的正式定義及類別圖： 共享物件，用來儘可能減少記憶體使用量以及分享資訊給儘可能多的相似物件。 Use sharing to support large numbers of fine-grained objects efficiently. Flyweight：所有具象 Flyweight 子類別的共同介面 ConcreteFlyweight：Flyweight 的具象子類別，就是要共享的元件類別。共享元件本身有內部的資料或狀態的話，都是在這裡維護。 FlyweightFactory：負責創建與管理共享元件 (如例子中的名片)。通常會確認共享元件是否已存在，存在就直接給 Client 用，否則就創建新的共享元件。 Client：取得共享元件並使用的角色，通常會結合外部資訊來使用共享元件 (如例子中的員工資訊) // 名片是共享元件 // 提供一個介面讓子類別實作 public abstract class NameCard { // 名片要顯示的資訊 protected String mId; protected String mDept; protected String mTel; public abstract void show(Employee e); } public class GeneralNameCard extends NameCard { @Override public void show(Employee e) { // 從外部資源取得資料 mId = e.getId(); mDept = e.getDept(); m...

        假設你的公司時常會收到不同的電子郵件如垃圾信，顧客的抱怨信，顧客的感謝信等等，而公司希望對這些不同類型的信都先用制式的罐頭信回應 (就是 不同的信件有不同的處理方式 )。當你要寫程式處理公司的電子郵件時，直接寫在一個 class 是最簡單的作法。但你勢必會用到 if/else 或 switch 等來判斷不同的信件，而這樣做有一些缺點，例如 程式複雜性增加，不夠彈性，擴充困難 等等。當你希望 多個物件 (處理信的方式) 都有機會能處理相同請求時 (新寄來的電子郵件) 時，可以考慮責任鏈模式。先介紹此模式的正式定義及類別圖： 讓多個物件都有機會可以處理請求，以避免請求的發送者和接受者之間產生耦合關係。將這些物件連成一條鏈，並沿著這條鏈傳遞請求，直到有一個物件處理這個請求為止。 Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.         從類別圖來看這個模式很單純，每個子類別都有要實作的方法來處理它們能處理的特殊請求。 當有不能處理的請求時，也能傳給下一個子類別繼續處理 。當然這邊就是由設計者自行決定要有幾個子類別來處理哪些不同的請求，以及決定這些子類別傳遞請求的順序為何。         接著來看一下套用責任鏈模式的簡單程式碼吧 // 所有處理郵件的子類別要繼承的介面 public abstract class MailHandler { // 每個處理郵件類別都要記錄下一個 // 能處理的人是誰 protected MailHandler mHandler; public MailHandler(MailHandler handler) { mHandler = handl...

        今天你要為一個遊樂園設計程式，讓客人可以自由選擇旅館及各種門票、餐廳訂位、或是其他特殊活動來建立自己的假期計畫，但你可能會遇到一些問題：每個客人的 假期計畫都不一樣 ，如旅行天數不同，或是想住的旅館會不同，而且為了要滿足客製化假期內容的要求，你的設計可能會有 很多建構子 才能滿足需求： public class Vocation { // 客人只要求天數，其他隨便排 public Vocation(Date begin, Date end) { // ... } // 客人要求天數，還指定飯店 public Vocation(Date begin, Date end, Hotel hotel) { // ... } // 客人指定天數，飯店，還有餐廳 public Vocation(Date begin, Date end, Hotel hotel, Restaurant restaurant) { // ... } // 可能還有其他可以讓客人選擇的建構子 }         這樣對於客戶而言，他需要先知道全部的建構子有哪些，才能知道要選用哪個來建立適合自己的假期物件。但有時候我們提供的的建構子可能還是不符合客戶的要求，因此我們需要有一個有彈性的結構，可以把 整個假期物件的產生過程封裝起來 ，而且客戶還可以不影響物件建立的步驟，建立出自己想要的假期物件，這就是這次要介紹的建立者模式！         我們先來看看建立者模式的定義及類別圖吧 將一個複雜對象的建構和表現分離，使得同樣的建構過程可以產生出不同的表現 Separate the construction of a complex object from its representation so that the same construction process can create different representations. ...

        今天你要設計一個搖控器程式，想要讓不同廠商的電視都能使用的話，依我們對物件導向的了解，我們知道把搖控器抽象化成一個介面是個不錯的方法，各家廠商都依照此介面去實作他們的搖控器程式就可以。上述的類別圖看起來會如下所示：         看起來這樣的架構好像還 OK，但繼續使用下去就會發現有問題了。假如 LG，Sony 都有自己特定 API，則各家的搖控器在操作電視的 method 勢必要使用廠商的電視 API。當某天 LG 修改了 API，則所有的 LGControl 都要跟著修改。另外當哪天 RemoteControl 也需要做修改時，是不是底下的實作也需要跟著修改了？是否有一個模式，能 不只有改變實作，同時也能改變抽象 呢？答案就是接下來要介紹的模式：橋接模式。 橋接模式把抽象和實作分開，如此他們兩個可以互相獨立 Decouple an abstraction from its implementation so that the two can vary independently.          橋接模式允許你改變實作及抽象，採取的作法是 將實作與抽象放在兩個不同的類別階層中 ，由類別圖來看會比較清楚：         以我們搖控器的例子來解釋這個類別圖的話，Abstraction 就是我們的 RemoteControl。Implementor 就是我們 把容易變動的 method 獨立出來的一個介面，讓實作依賴此介面 。例如 on()，off()，setChannel() 等都是跟廠商的 API 有關係，因此把這些 method 當成介面放在 Implementor 很適合。 ConcreteImplementorA 及 ConcreteImplementorB 就是各家廠商的實作。從類別圖可以看到，當未來 Abstraction 需要做更改時，我們一樣可以創造一個 RefinedAbstraction，而不影響功能上的實作，因為會變動的 method 都移到了 Implementor。Abstraction 和 Impl...

        代理人模式如同字面上的意思，就是做事情時(如取得某些資料)，是透過代理人，而不是直接跟提供資料的物件構通。先來看看此模式的正式定義及類別圖： 代理人模式讓某個物件具有一個替身，藉以控制外界對此物件的影響。 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...

        如果今天你要設計一台如下圖的糖果機，你會怎麼設計呢？         有上過資訊相關課程的人，應該不難從上圖聯想到 狀態圖 ，上圖中每個圓圈都是一個狀態，而每個箭頭就代表狀態的轉換。有了這個概念後，把它轉成程式就不難了： 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"); } ...

        延續之前 反覆器模式 的菜單例子，雖然已經簡化了程式碼，但是 Waitress 裡還是要呼叫 printMenu() 多次，看起來滿醜的，要是未來有新菜單加入，Waitress 程式碼勢必要修改，這算不算是「違反開放關閉守則」？是否有什麼方式可以將菜單合併，或是只傳給 Waitress 一個反覆器，而此反覆器可以在所有菜單間遊走呢？         最簡單的改法，就是把菜單全包進一個 ArrayList，然後取得 ArrayList 的反覆器，這樣Waitress 有再多的菜單也不怕了： public class Waitress { private ArrayList<Menu> mMenus; public Waitress(ArrayList<Menu> menus) { this.mMenus = menus; } public void printMenu() { Iterator menuIterator = menus.iterator(); while(menuIterator.hasNext()) { Menu menu = (Menu) menuIterator.next(); printMenu(menu.createIterator()); } } public void printMenu(Iterator iterator) { while(iterator.hasNext()) { MenuItem menuItem = (MenuItem)iterator.next(); System.out.print(menuItem.getName() + ", "); System.out.println(menuItem.getPrice()); } } }    ...

        假如你有一間早餐店，菜單用 ArrayList 存，有一間午餐店，菜單用 Array 存。今天你想把兩間餐廳合併成一間，但是馬上就遇到問題：要顯示菜單給顧客看時，要分別使用 for 來走訪 ArrayList 跟 Array，這樣造成程式維護上的困難，因為要寫兩次 for，未來要是合併另一間餐廳，又使用不同型態存菜單的話，程式碼不就又要大改? 是否有方法可以 封裝重複的動作呢 ? 答案是可以的喔，讓我們直接看程式碼來了解怎麼做。 // 這個就是菜單的共通介面 // 為了能夠走訪所有菜色 public interface Iterator { // 得知是否還有更多元素 boolean hasNext(); // 取得下一個元素 Object next(); } // 只是一個簡單的介面 // 可以取得一個反覆器, 取得菜單內容 public interface Menu { Iterator createIterator(); } // 以午餐店, 使用 Array 當例子 public class LunchMenuIterator implements Iterator { private MunuItem[] mItems; private int mPosition = 0; // 紀錄目前走訪的位置 // 建構式傳入一個菜單 Array public LunchMenuIterator(MenuItem[] items) { mItems = items; } @Override public Object next() { // 傳回目前位置的元素, 並增加位置 MenuItem menuItem = mItems[position]; position = position + 1; return menuItem; } @Override public boolean hasNext() { // 因為是 Array, 要檢查是否超出長度 ...

        你有一家飲料店，主要提供咖啡跟茶。泡咖啡跟泡茶的程式碼如以下所示： public class Coffee { // 這是店裡統一的泡咖啡SOP void prepareRecipe() { // 煮開水 boilWater(); // 用沸水沖泡咖啡 brewCoffeeGrinds(); // 把咖啡倒進杯子 pourInCup(); // 加糖和牛奶 addSugarAndMilk(); } // 底下省略這些方法的實作... } public class Tea { // 這是店裡統一的泡茶SOP void prepareRecipe() { // 煮開水 boilWater(); // 用沸水沖泡茶包 steepTeaBag(); // 把茶倒進杯子 pourInCup(); // 加檸檬 addSLemon(); } // 底下省略這些方法的實作... }         prepareRecipe看起來好像喔，應該可以抽象化。第一步很自然的把一些一樣的方法，如biolWater 跟 pourInCup，放到超類別裡，就稱為 Beverage。而雖然咖啡是沖泡「咖啡」、加糖跟牛奶，茶是沖泡「茶葉」、加檸檬，兩種飲料加的東西不一樣，但是做的「動作」是一樣的，只是處裡不同的原料而已。有了這些想法後，就可以來改上面的程式碼了： public abstract class Beverage { // 宣告為 final 是因為不想次類別 // 推翻這個方法, 這是統一的演算法 final void prepareRecipe() { // 煮開水 boilWater(); // 用沸水沖泡 // 跟上面程式碼比, ...

        某天你心血來潮，想在家裡準備家庭劇院組。你為此做了一番研究，找來了覺得適合的播放器、投影機、螢幕、音響等等的設備，當你要準備開始看電影時，你要做哪些事呢？ 將燈光調暗 開啟螢幕 打開投影機 設定投影機輸入模式 打開音響 設定音響音量 打開播放器 開始播放         將這些動作寫成程式碼的話： // 將燈光調暗到 10% 的亮度 lights.dim(10); screen.on(); projecter.on(); projecter.setInput(player); // 開啟喇叭 amp.on(); amp.setVolumn(5); player.on(); player.play();         這樣看起來做的事好像沒很多，但是當看完電影後，要把所有設備關掉要怎麼做？全部反向做一次嗎？假如要聽音樂而已，也要這麼麻煩嗎？未來升級新設備時，還要重新學習操作流程嗎？         這時候最直覺的想法一定是：把這些事包成一個 function 就好啦。這就是表象模式的精神所在，將一個或數個類別複雜的一切都隱藏起來，只露出美好的表面(就是簡化介面啦)。         使用表象模式，可以將一個複雜的次系統，變得容易使用。表象類別提供更合理的介面，來簡化原先的複雜介面。假如不想用表象介面時，還是可以直接操作次系統。         在這邊特別說明一下，表象模式跟 轉接器模式 雖然都是用來封裝類別，但是他們的目的卻是不同的。轉接器模式的目的是 改變介面以符合客戶的期望 。而表象模式是 提供次系統一個簡化的介面 。 public class HomeTheaterFacade { // 這就是合成 // 會用到的次系統元件全都在這裡 Amplifier mAmp; Player mPlayer; Projector mProjector; TheaterLights mLights; Sc...