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