設計模式（學習筆記）

設計原則:
1. 找出應用中可能需要變化之處,把他們獨立出來,不要和那些不需要變化的代碼混在一起.
2. 針對介面編程,而不是針對實現編程.
例如: dog和cat繼承於animal
   針對介面編程：dog d = new dog();
                 d.makesound();
   針對實現編程: animal a = new animal();
                 a.makesound();       利用多態調用

3. 多組合，少繼承（組合和委託可以在運行時動態擴充,達到繼承的效果,然而繼承是編譯時間就決定了的,缺

少彈性和不好的維護性）
4. 為了互動對象之間的松耦合設計而努力
5. 類應該對擴充開放,對修改關閉
6. 要依賴抽象,不要依賴具體類
7. 最少知識原則，只和你的密友談話.（適配或者外觀的重要性）

設計模式：
1. 策略模式 （鴨子）          //演算法的抽象與解耦,使得演算法容易替換,而不影響具體的類
   定義了演算法簇,分別封裝起來，讓他們之間可以互相替換，此模式讓演算法的變化獨立於使用演算法的客戶.
   鴨子的設計模式: 委託--》封裝--》抽象

2. 觀察者模式（observer）（天氣預報與畫板） //訊息響應的一種機制
   出版者 + 訂閱者 = 觀察者模式
   定義了對象之間的一對多的依賴,這樣一來，當一個對象改變狀態的時候,它的所有依賴者都會收到通知並

更新.
   subject(出版者)介面 需要有註冊和刪除observer的方法,以及通知observer的方法
   observer(訂閱者)介面 需要有響應出版者訊息的方法

3. 裝飾者模式 （咖啡及原料）  //屬性不同時而展現的不同狀態,通過裝飾來修改對象,而不需要添加新類
   動態將責任附加到對象上,若要擴充功能,裝飾者提供了比繼承更有彈性的替代方案.

   a. 抽象組件  --》 實體組件 （通過添加裝飾類動態添加方法,再裝飾實體達到擴充）
   b. 抽象組件  - 》 抽象裝飾者 --》 具體裝飾者

   具體裝飾者通過再實體組件上面構造,再添加具體裝飾上去,形成新的組件.（通過添加裝飾者類動態添加

方法,再裝飾實體達到擴充）

4. 原廠模式 （各種風格的pizza）    //封裝對象的建立過程
  所有工廠都是用來封裝對象的建立,讓我們是針對抽象編程,而不是針對具體類編程.
  a. 簡單工廠
     把所有建立工作委託給工廠去做,通過不同的工廠製作出不同的產品
  b. Factory 方法（繼承） 
     定義了一個建立對象的介面,但由子類決定要執行個體化的類是哪一個.工程方法讓類把執行個體化延遲到子類.
     建立者類: creater抽象類別 --》 具體方法的creater（工廠）
     產品類:   產品抽象類別 --》 具體產品類
  c. 抽象原廠模式（對象組合）
     提供一個介面,用於建立相關或依賴對象的家族，而不需要明確指定具體類（即介面不關心具體的產品

類是什麼）.
     抽象產品類由工廠介面組合而來.

5. 單件模式     //若是全域的變數,需要在啟動的時候執行個體化它,存在弊端
   確保一個類只有一個執行個體,並提供一個全域的訪問點.
   static的單件對象，private 的構造器，static 的getinstance()方法,不存在的時候就建立,存在則不創

建

6. 命令模式(遙控器按鈕操作多個對象)   //各種各樣的命令請求
   將請求封裝成對象,以便使用不同的請求,隊列或者日誌來參數化其他對象.命令模式也支援可撤銷的操作.
   命令寄件者: 命令對象 + 事件方法(調用到命令對象的execute())
   命令對象:   包含具體的執行者

7. 適配器模式和面板模式 （不同的對象之間的交流或者一處理多個任務的情況）
   a. 適配器模式 （鴨子與火雞）
     將一個類的介面,轉換成客戶期望的另一個介面.適配器讓原本不相容的類可以合作無間.
     對象適配器:  適配器繼承客戶需要的目標介面,並委託被適配對象處理
     類適配器：   適配器繼承於客戶需要的目標類和被適配類,再實現內部方法轉換
   b. 面板模式 （家庭影院,遙控器控制）
      提供了一個統一的介面,用來訪問子系統中的一群介面.外觀定義了一個高層介面,讓子系統更容易使用

.     客戶將一切操作委託給外觀,外觀再處理子系統的響應.