Design Pattern murmur

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

        用來說明觀察者模式最常見也最容易懂的例子就是報社訂閱報紙: 報社的主要工作就是出版報紙 (提供資料) 用戶可向報社訂閱報紙。只要報社有出版新報紙, 而你在報社的訂閱名單中, 你都可以收到最新的報紙。 當你不想再看報紙時, 可隨時取消訂閱, 報社就不會送報紙到你家。 只要報社還存在, 用戶就可隨時向報社訂閱或取消訂閱報紙。         假如你看得懂上面的例子的話, 其實也大概了解觀察者模式在幹什麼。把上面的例子, 報社改名為主題 (Subject), 訂閱者改為觀察者 (Observer), 觀察者模式 = 出版者 ＋ 訂閱者 。         更精確的觀察者模式定義為: 觀察者模式定義了物件之間的一對多關係, 如此一來, 當一個物件改變狀態, 其他相依者都會收到通知並自動被更新 。 Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.         以下來看個簡單的觀察者模式類別圖:         主題介面定義了 registerObserver(), removeObserver(), 可以讓物件變成觀察者, 或從觀察者名單中移除, 而觀察者介面定義了 update(), 當主題有改變時, 可以用來通知所有觀察者。在此介紹觀察者模式的設計守則: 設計時, 盡量讓需要互動的物件之間關係鬆綁 。此設計讓我們建立有彈性的 OO 系統, 能夠因應變化, 因為物件的相依性被降到最低。 關於觀察者的一切, 主題只知道觀察者有實作特定介面 (也就是 Observer 介面) 。主題不需要知道觀察者的具體類別為何、做了什麼、及其細節。 任何時候都可以加入新的觀察者 。 有新型態的觀察者出現時, 主題的程式碼不用修改 。主題不在乎觀察者實際類別, 只在乎有沒有實作觀察者介面。 片面改...

        假設你在公司做了一套鴨子遊戲, 類別圖如下:         某天, 主管要求你把這遊戲加上新功能: 讓鴨子會飛, 這時程式要怎麼修改呢? 最簡單的方式, 就是在父類別裡加一個 method: fly(), 這樣就所有的鴨子都會飛啦。但是這樣好像怪怪的，因為 並不是每種鴨子都會飛 。就算把不會飛的鴨子 fly() 裡什麼事都不做, 未來當不會飛的鴨子越來越多, 程式維護起來也很麻煩。         既然繼承不行，那改成介面(Interface) 應該可以吧 ?  因為不是所有鴨子都會飛跟叫, 因此就把這兩個行為拉出來變 Interface, 其類別圖如下:         但是這也不是個好的方法。一來程式碼無法再利用, 二來當鴨子的種類變多時, 每種鴨子都要自己實作 Flyable 或 Quackable, 而這時候策略模式就派上用場了。         定義:  策略模式 定義了演算法家族, 個別封裝起來,  讓它們之間可以互相替換。此模式讓演算法的變動, 不會影響到使用演算法的程式。 Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.          設計守則:         1. 把程式中可能變動的部份獨立出來         2. 寫程式是針對介面寫, 不是針對實作方式寫         3. 多用合成, 少用繼承         根據守則1, 我們知道目前會變動的就是飛跟叫的行為, 而這兩個行為...