“對象創建”模式
- 通過“對象創建”模式繞開new，來避免對象創建（new）過程中所導致的緊耦合（依賴具體類），從而支持對象創建的穩定。它是接口抽象之后的第一步工作。
- 典型模式
- Factory Method
- Abstract Factory
- Prototype
- Builder
Factory Method 工廠方法
動機（Motivation）
- 在軟件系統中，經常面臨著創建對象的工作；由于需求的變化，需要創建的對象的具體類型經常變化。
- 如何應對這種變化？如何繞過常規的對象創建方法（new），提供一種“封裝機制”來避免客戶程序和這種“具體對象創建工作”的緊耦合？
模式定義
定義一個用于創建對象的接口，讓子類決定實例化哪一個類。Factory Method 使得一個類的實例化延遲（目的：解耦，手段：虛函數）到子類。
——《設計模式》GoF
結構（Structure）
Product和Creator 穩定
ConcreteProduct和ConcreteCreator 變化
要點總結
- Factory Method 模式用于隔離類對象的使用者和具體類型之間的耦合關系。面對一個經常變化的具體類型，緊耦合關系（new）會導致軟件的脆弱。
- Factory Method 模式通過面向對象的方法，將所要創建的具體對象工作延遲到子類，從而實現一種擴展（而非更改）的策略。缺點在于要求創建方法/參數相同。
Abstract Factory 抽象工廠
動機（Motivation）
- 在軟件系統中，經常面臨著“一系列相互依賴的對象”的創建工作；同時，由于需求的變化，往往存在更多系列對象的創建工作。
- 如何應對這種變化？如何繞過常規的對象創建方法（new），提供一種“封裝機制”來避免客戶程序的這種“多系列具體對象創建工作”的緊耦合？
模式定義
提供一個接口，讓該接口負責創建一系列“相關或者相互依賴的對象”，無需指定它們具體的類。
——《設計模式》GoF
結構（Structure）
AbstractFactory和AbstractProduct 穩定
ConcreteFactory和Client 變化
要點總結
- 如果沒有對應“多系列對象構建”的需求變化，則沒有必要使用Abstract Factory 模式，這時候使用簡單的工廠完全可以。
- “系列對象”指的是在某一特定系列下的對象之間相互依賴、或作用的關系。不同系列的對象之間不能相互依賴。
- Abstract Factory 模式主要在于應對“新系列”的需求變動。其缺點在于難以應對“新對象”的需求變動。
典型實現
把一系列相關對象由一個基類關聯在一起，防止錯誤的交叉調用。
Prototype 原型模式
動機（Motivation）
- 在軟件系統中，經常面臨著“某些結構復雜的對象”的創建工作；由于需求的變化，這些對象經常面臨著劇烈的變化，但是它們卻擁有比較穩定一致的接口。
- 如何應對這種變化？如何向“客戶程序（使用這些對象的程序）”隔離出“這些易變對象”，從而使得“依賴這些易變對象的客戶程序”不隨著需求改變而改變？
模式定義
使用原型實例制定創建對象的種類，然后通過拷貝這些原型來創建新的對象。
——《設計模式》GoF
結構（Structure）
Prototype 穩定
ConcretePrototype 變化
要點總結
- Prototype 模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合關系，它同樣要求這些“易變類”擁有“穩定的接口”。
- Prototype 模式對于“如何創建易變類的實體對象”采用“原型克隆”的方法來做，它使得我們可以非常靈活地動態創建“擁有某些穩定接口”的新對象——所需工作僅僅是注冊一個新類的對象（即原型），然后在任何需要的地方Clone。
- Prototype 模式中的Clone 方法可以利用某些框架中的序列化來實現深拷貝。
return new Self(*this);
Builder 構建器
動機（Motivation）
- 在軟件系統中，有時候面臨“一個復雜對象”的創建工作，其通常由各個部分的子對象用一定的算法構成；由于需求的變化，這個復雜對象的各個部分經常面臨著劇烈的變化，但是將它們組合在一起的算法卻相對穩定。
- 如何應對這種變化？如何提供一種“封裝機制”來隔離出“復雜對象的各個部分”的變化，從而保持系統中的“穩定構建算法”不隨著需求改變而改變？
C++中構造函數里的虛函數是靜態綁定，而不是動態綁定。
子類里構造函數的虛函數調用的是父類的虛函數。
模式定義
將一個復雜對象的構建與其表示相分離，使得同樣的構建過程（穩定）可以創建不同的表示（變化）。
——《設計模式》GoF
結構（Structure）
Director 和 Builder 穩定
ConcreteBuilder 變化
要點總結
- Builder 模式主要用于“分步驟構建一個復雜的對象”。在這其中“分步驟”是一個穩定的算法，而復雜對象的各個部分則經常變化。
- 變化點在哪里，封裝哪里——Builder模式主要在于應對“復雜對象各個部分”的頻繁需求變動。其缺點在于難以應對“分步驟構建算法”的需求包圍。
- 在Builder模式中，需要注意不同語言中構建器內調用虛函數的差別（C++ vs. C#和Java）。
“接口隔離”模式
- 在組建構建過程中，某些接口之間直接的依賴常會帶來很多問題、甚至根本無法實現。采用添加一層間接（穩定）接口，來隔離本來互相緊密關聯的接口是一種常見的解決方案。
- 典型模式
- Facade（系統內外）
- Proxy（被隔離）
- Adapter（新老接口）
- Mediator（系統內）
Facade 門面模式
系統間耦合的復雜度
動機（Motivation）
- 上述A方案的問題在于組件的客戶和組件中各種復雜的子系統有了過多的耦合，隨著外部客戶程序和各子系統的演化，這種過多的耦合面臨很多變化的挑戰。
- 如何簡化外部客戶程序和系統間的交互接口？如何將外部客戶程序的演化和內部子系統的變化之間的依賴相互解耦？
模式定義
為子系統中的一組接口提供一個一致（穩定）的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用（復用）。
——《設計模式》GoF
結構（Structure）
要點總結
- 從客戶程序的角度來看，Facade模式簡化了整個組件系統的接口，對于組件內部與外部客戶程序來說，達到了一種“解耦”的效果——內部子系統的任何變化不會影響到Facade接口的變化。
- Facade 設計模式更注重從架構的層次去看整個系統，而不是單個類的層次。Facade 很多時候更是一種架構設計模式。
- Facade 設計模式并非是一個集裝箱，可以任意地放進任何多個對象。Facade 模式中組件的內部應該是“相互耦合關系比較大的一系列組件”，而不是一個簡單的功能集合。
Proxy 代理模式
動機（Motivation）
- 在面向對象系統中，有些對象由于某種原因（比如對象創建的開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問等），直接訪問會給使用者、或者系統結構帶來很多麻煩。
- 如何在不失去透明操作對象的同時來管理/控制這些對象特有的復雜性？增加一層間接層是軟件開發中常見的解決方式。
透明操作是指一致性。
模式定義
為其他對象提供一種代理以控制（隔離，使用接口）對這個對象的訪問。
——《設計模式》 GoF
結構（Structure）
Subject穩定
RealSubject和Proxy變化
要點總結
- “增加一層間接層”是軟件系統中對許多復雜問題的一種常見解決方法。在面向對象系統中，直接使用某些對象會帶來很多問題，作間接層的proxy對象便是解決這一問題的常用手段。
- 具體proxy設計模式的實現方法、實現粒度都相差很大，有些可能對單個對象做細粒度的控制，如copy-on-write技術，有些可能對組建模塊提供抽象代理層，在架構層次對對象做proxy。
- Proxy并不一定要求保持接口完整的一致性，只要能夠實現間接控制，有時候損及一些透明性是可以接受的。
Adapter 適配器
動機（Motivation）
- 在軟件系統中，由于應用環境的變化，常常需要將“一些現存的對象”放在新的環境中應用，但是新環境要求的接口是這些現存對象所不滿足的。
- 如何應對這種“遷移的變化”？如何既能利用現有對象的良好實現，同時又能滿足新的應用環境所要求的接口？
模式定義
將一個類的接口轉換成客戶希望的另一個接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
——《設計模式》GoF
結構（Structure）
Target和Adaptee穩定
Adapter變化
要點總結
- Adapter模式主要應用于“希望復用一些現存的類，但是接口又與復用環境要求不一致的情況”，在遺留代碼復用、類庫遷移等方面非常有用。
- GoF 23 定義了兩種Adapter模式的實現結構：對象適配器和類適配器。但類適配器采用“多繼承”的實現方式，一般不推薦使用。對象適配器采用“對象組合”的方式，更符合松耦合精神。
- Adapter模式可以實現的非常靈活，不必拘泥于GoF23中定義的兩種結構。例如，完全可以將Adapter模式中的“現存對象”作為新的接口方法參數，來達到適配的目的。
類適配器，不太好，有很多其他困擾的問題
protected 繼承，只用實現
只有壞處，沒有好處
Mediator 中介者
動機（Motivation）
- 在軟件構建過程中，經常會出現多個對象互相關聯交互的情況，對象之間常常會維持一種復雜的引用關系，如果遇到一些需求的更改，這種直接的引用關系將面臨不斷的變化。
- 在這種情況下，我們可以使用一個“中介對象”來管理對象間的關聯關系，避免相互交互的對象之間的緊耦合引用關系，從而更好的抵御變化。
模式變化
用一個中介對象來封裝（封裝變化）一系列的對象交互。中介者使各對象不需要顯式的相互引用（編譯時依賴→運行時依賴），從而使其耦合松散（管理變化），而且可以獨立地改變它們之間的交互。
——《設計模式》GoF
結構（Structure）
要點總結
- 將多個對象間復雜的關聯關系解耦，Mediator模式將多個對象間的控制邏輯進行集中管理，變“多個對象互相關聯”為“多個對象和一個中介者關聯”，簡化了系統的維護，抵御了可能的變化。
- 隨著控制邏輯的復雜化，Mediator具體對象的實現可能相當復雜。
這時候可以對Mediator對象進行分界處理。 - Facade模式是解耦系統間（單向）的對象關聯關系；Mediator模式是解耦系統內各個對象之間（雙向）的關聯關系。
