設計模式: 對軟體程式設計中普遍存在的問題的整體解決方案. (面向對象程式設計), 為了将來更好的擴充(修改)
後續所有的 Client 本身不是設計模式的一部分, 它是客戶,調用這個設計模式.
1） 代碼重用性 (相同功能的代碼, 不用重複編寫)
2） 可讀性（程式設計規範性，便于其他程式的閱讀和了解）
3）可擴充（當需要增加新的功能時，非常友善也稱為可維護性）
4）可靠性（增加新的功能後，對原來的功能沒有影響）
5）高内聚，低耦合（子產品内部緊密，子產品和子產品之間依賴性低， 如果1個子產品出了問題，不要把問題帶到另一個子產品）
1. 抛出問題, 先代碼實作(非設計模式方式)
2. 具體設計模式說明和解釋(生活應用場景)
3. 代碼實作
4. UML圖 (原理與角色)
5. 具體源碼應用 & 分析
1. 單一職責原則
對類來說， 一個類應該負責一個職責, 降低變更帶來的風險. 如果 A 類負責2個不同的職責， 職責1， 職責2， 當職責1需求變更而改變 A 時,
可能造成職責2執行錯誤，是以要将類拆分成不同職責的 A1 和 A2.
2. 接口隔離原則
一個類對另一個類的依賴, 應該是建立在最小的接口上. 類A 通過接口 ITarget 對類 B(實作接口的類) 有依賴, 接口中有5個方法, 但是 A 實際上
隻需要其中3個, 但是, B 需要實作全部接口中的5個方法.
3. 依賴倒轉原則
要依賴抽象(接口 / 抽象類), A 依賴接口, B 具體實作的是接口. 因為接口穩定. 抽象的目的在于制定好規範. 而抽象不會涉及任何具體操作.
盡量針對接口程式設計
4. 裡氏替換原則
用來指導繼承, 裡氏替換原則：引用基類的地方能透明使用其子類進行替換(子類盡量不要重寫父類的方法).
5. 開閉原則OCP（最重要）
一個類, 函數 或者子產品，對擴充開放(提供方提供新方法)，對修改關閉（使用方不用修改之前的代碼）. 說白了, 可以擴充新的, 且不用修改原有的.
這樣，當你增加新功能（擴充）時, 就不會影響之前的代碼（因為沒有修改），這樣, 别人引用你原有代碼的人就不用擔心（因為沒有修改）
舉例: 比如新增加一個圖形時(長方形，正方形，圓形)，增加新圖形，對之前的沒有影響.(不是通過 if-else)
6. 迪米特法則 (降低類之間的耦合)
一個對象應該與其他對象保持最少的了解, 迪米特法則又叫最少知道原則, 類對外提供的隻能是 public 方法. 隻與直接朋友進行通信.
直接朋友的概念: B類時 A 類的成員變量, B類是 A類中某個方法的參數, B類 是 A 類中某個方法的傳回類型.
是以, 基本上可以了解為不要在方法裡定義對象(陌生類), 如果要用到, 盡量把它變成成員變量, 或者是參數傳入, 或者是由傳回類型需要在内部定義.
7. 合成複用原則
盡量使用 組合 / 聚合 has-a, 盡量少的使用繼承 is-a.
在 eclipse 中, 也可以通過拖拽源碼的方式, 直接把類似 class, interface 等拖拽到圖形編輯框中.
類圖中各種關系的含義
Dependency 依賴: A 類指向 B類, 表示 A 使用 B 提供的方法 等. (A 也可以通過接口依賴于B類對接口的實作)
Association關聯: 表示類和類之間的連接配接，使得一個類知道另一個類的方法，可以是雙向的. 1:1, 1:n 等
Generalization 泛化: 子類或者子接口繼承父類或者父接口. （可以了解為繼承關系）
Realization 實作: 是指一個類實作 一個或多個接口.
Aggregation 聚合(has-a): 表示整體與部分的關系，帶菱形空心箭頭的指向整體. (部分可以離開整體)
Composite 組合(has-a): 整體與部分的關系，但是部分不可以離開整體， 帶菱形實心箭頭的指向整體
關聯關系的3種: 關聯, 聚合, 組合, 實際上這3中都是關聯關系, 那有什麼不同呢?
Association: 普通關聯關系
Aggregation 聚合， 書架上可以有 0...n 本書, 書是書架上的一部分,(即使書架上沒有書, 書架也可以單獨存在), 且book 也是可以獨立的.
Composite 組合, Head 類隻能存在于 Human 中, 不能獨立出來. （整體和部分是不可分開的(無論對主體還是部分都是一樣)）
比如當你建立一個對象 new Human， 那麼這時就必須自動執行個體化 Head Body 等（在類定義中, 直接執行個體化, 就是這種關系）