5.對象創(chuàng)建
通過“對象創(chuàng)建”模式繞開new，來避免對象創(chuàng)建(new)過程中所導(dǎo)致的緊耦合（依賴具體類）藕各，從而支持對象創(chuàng)建的穩(wěn)定例诀，他是接口抽象之后的第一步工作。
典型模式
Factory Method
Abstract Factory
Prototype
Builder
Factory Method
動機(jī)
在軟件系統(tǒng)中禁筏，經(jīng)常面臨創(chuàng)建對象的工作，由于需求的變化衡招，需要創(chuàng)建的對象的具體類型經(jīng)常變化篱昔。
定義一個創(chuàng)建對象的接口，讓子類決定實例化哪一個類。Factory Method使得一個類的實例化延遲（目的：解耦州刽，手段：虛函數(shù)）空执。
結(jié)構(gòu)
要點總結(jié)
Factory Method模式用于隔離類對對象的使用者和具體類型之間的耦合關(guān)系。面對經(jīng)常變化的具體類型穗椅，緊耦合關(guān)系（new）會導(dǎo)致軟件的脆弱辨绊。
Factory Method模式通過面向?qū)ο蟮氖址ǎ瑢⑺獎?chuàng)建的具體對象工作延遲到子類房待，從而實現(xiàn)一種擴(kuò)展（而非更改）的策略邢羔，較好的解決了緊耦合關(guān)系驼抹。
Factory Method模式解決“單個對象”的需求變化桑孩。缺點在于要求創(chuàng)建方法/參數(shù)相同。
Abstract Factory
動機(jī)
在軟件系統(tǒng)中框冀，經(jīng)常面臨著“一系列相互依賴的對象”的創(chuàng)建工作流椒，同時，由于需求的變化明也，往往存在更多系列對象的創(chuàng)建工作宣虾。
提供一個借口，讓該接口負(fù)責(zé)創(chuàng)建一系列“現(xiàn)骨干或者相互依賴的對象”温数，無需指定他們具體的類绣硝。
結(jié)構(gòu)
要點總結(jié)
如果沒有應(yīng)對“多系列對象構(gòu)建”的需求變化，則使用Factory Method就足夠了撑刺。
“系列對象”指的是在某一特定系列下的對象之間有相互依賴或作用的關(guān)系鹉胖。不同系列的對象之間不能相互依賴。
Abstract Factory模式主要在于應(yīng)對“新系列”的需求變動（可以擴(kuò)展一個系列）够傍，其缺點在于難以應(yīng)對“新對象”的需求變動（某個已有系列需要增加新的對象）甫菠。
設(shè)計模式主要解決穩(wěn)定中有變化的情況，如果在兩個極端情況冕屯，一是所有地方都有變化寂诱，二是所有地方都不變化，那么就根本沒有必要使用設(shè)計模式了安聘。
綜上所看痰洒，可以說Factory Method是Abstract Factory的一個特例，所以可以統(tǒng)稱為Factory模式浴韭。
Prototype
動機(jī)
在軟件系統(tǒng)中带迟，經(jīng)常面臨著“某些結(jié)構(gòu)復(fù)雜的對象”的創(chuàng)建工作；由于需求的變化囱桨，這些對象經(jīng)常面臨著劇烈的變化仓犬，但是他們卻擁有比較穩(wěn)定一致的接口。
使用原型實例制定創(chuàng)建對象的種類舍肠，然后通過拷貝（深克隆）這些原型來創(chuàng)建新的對象搀继。
和工廠模式不同窘面，它主要能夠解決工廠模式要求創(chuàng)建方法/參數(shù)相同的問題，尤其適應(yīng)“某些結(jié)構(gòu)復(fù)雜的對象”的創(chuàng)建工作叽躯。
結(jié)構(gòu)
要點總結(jié)
Prototype模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合财边。同樣要求這些“易變類”擁有“穩(wěn)定的接口”。
Prototype模式對于“如何創(chuàng)建易變類的實體對象”曹勇“原型克隆”的方法來做点骑，它使得我們可以非常靈活得動態(tài)創(chuàng)建“某些穩(wěn)定接口”的新對象————所需工作僅僅是注冊一個新類的對象酣难，然后在任何需要的地方Clone。
Prototype模式中的Clone方法可以利用某些框架中的序列化來實現(xiàn)深拷貝（C++使用拷貝構(gòu)造函數(shù)即可）黑滴。
Builder
動機(jī)
在軟件系統(tǒng)中憨募，經(jīng)常面臨著“一個復(fù)雜對象”的創(chuàng)建工作，其通常由各個部分的子對象用一定的算法構(gòu)成袁辈；由于需求的變化菜谣，這個負(fù)責(zé)對象的各個部分經(jīng)常面臨著劇烈的變化，但是將他們組合在一起的算法卻相對穩(wěn)定晚缩。
將一個復(fù)雜對象的構(gòu)建與其表示相分離尾膊，使得同樣的構(gòu)建過程（穩(wěn)定）可以創(chuàng)建不同的表示（變化）。
結(jié)構(gòu)
要點總結(jié)
Builder模式主要用于“分步驟構(gòu)建一個負(fù)責(zé)的對象”荞彼。在這其中冈敛，“分步驟”是一個穩(wěn)定的算法，而復(fù)雜對象的各個部分則經(jīng)常變化鸣皂。
變化點在哪里抓谴，封裝到哪里————Builder模式主要在于對應(yīng)“復(fù)雜對象各個部分”的頻繁需求變動。缺點在于難以應(yīng)對“分步驟構(gòu)建算法”的需求變動签夭。
在Builder模式中齐邦，要注意不同語言中構(gòu)造器內(nèi)調(diào)用虛函數(shù)的差別。
6.接口隔離
在組件構(gòu)建過程中第租，某些接口之間直接的依賴常常會帶來很多問題措拇、甚至根本無法實現(xiàn)。采用添加一層間接（穩(wěn)定）接口慎宾，來隔離本來互相緊密關(guān)聯(lián)的接口丐吓。
典型模式
Facade
Proxy
Adapter
Mediator
Facade
動機(jī)
上圖A方案的問題在于組件的客戶和組件中各種復(fù)雜的子系統(tǒng)有了過多的耦合，隨著外部客戶程序和各子系統(tǒng)的演化（變化）趟据，這種過多的耦合面臨很多變化的挑戰(zhàn)券犁。
為子系統(tǒng)中的一組接口提供一個一致（穩(wěn)定）的界面，F(xiàn)acade模式定義了一個高層接口汹碱，這個接口使得這一子系統(tǒng)更加容易使用（復(fù)用）粘衬。
結(jié)構(gòu)
更多的體現(xiàn)的是一種設(shè)計原則和思想。關(guān)鍵在于子系統(tǒng)內(nèi)外部的解耦。
要點總結(jié)
從客戶程序的角度來看稚新，F(xiàn)acade模式簡化了整個組件系統(tǒng)的接口勘伺，對于組件內(nèi)部與外部客戶程序來說，達(dá)到了“解耦”的效果————子系統(tǒng)內(nèi)部的任何變化不會影響到Facade接口的變化褂删。
Facade設(shè)計模式更注重從架構(gòu)的層次去看整個系統(tǒng)飞醉，而不是單個類的層次。Facade很多時候更是一種架構(gòu)設(shè)計模式屯阀。
Facade設(shè)計模式并非一個集裝箱缅帘，可以任意地放進(jìn)任何多個對象。Facade模式中組件的內(nèi)部應(yīng)該是“相互耦合關(guān)系比較大的一系列組件”难衰，而不是一個簡單的功能集合钦无。
Proxy
動機(jī)
在面向?qū)ο笙到y(tǒng)中，有些對象由于某種原因（比如對象創(chuàng)建的開銷很大召衔，或者某些操作需要安全控制铃诬，或者需要進(jìn)程外的訪問）祭陷，直接的訪問會給使用者苍凛、或者系統(tǒng)結(jié)構(gòu)帶來很多麻煩。如何在不是去透明操作對象的同事來管理/控制這些對象特有的負(fù)載型兵志？
為其他對象提供一種代理以控制（隔離醇蝴，使用接口）對這個對象的訪問。
結(jié)構(gòu)
要點總結(jié)
“增加一層間接層”是軟件系統(tǒng)中對許多復(fù)雜問題的一種常見的解決方法想罕。在面向?qū)ο笙到y(tǒng)中悠栓，直接使用某些對象會帶來很多問題，作為間接層的Proxy對象便是解決這一問題的常用手段按价。
具體的proxy設(shè)計模式的實現(xiàn)方法惭适、實現(xiàn)粒度都相差很大，有些可能對單個對象做細(xì)粒度的控制楼镐，如copy-on-write技術(shù)癞志，有些可能對組件模塊提供抽象代理層，在架構(gòu)層次對對象做Proxy框产。
Proxy并不一定要求保持接口完整的一致性凄杯，只要能夠?qū)崿F(xiàn)間接控制，有時候損及一些透明性是可以接受的秉宿。
Adapter
動機(jī)
在軟件系統(tǒng)中戒突，由于應(yīng)用環(huán)境的變化，常常需要將“一些現(xiàn)存的對象”放在新的環(huán)境中使用描睦，但是新環(huán)境要求的接口是這些現(xiàn)存對象所不滿足的膊存。
將一個類的接口轉(zhuǎn)換成客戶希望的另一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
結(jié)構(gòu)
要點總結(jié)
Adapter模式主要應(yīng)用于“希望復(fù)用一些實現(xiàn)的類隔崎，但是接口又與復(fù)用環(huán)境要求不一致的情況”嗡载，在遺留代碼復(fù)用和類庫遷移時非常有用。
GOF23 定義了兩種Adapter模式的實現(xiàn)結(jié)構(gòu)：
對象適配器
classAdapter:publicITarget{IAdaptee* pAdaptee;//非常靈活...? ? ? ? ? ? ? ? ? }
非常靈活仍稀，pAdaptee可以指向任何可具體的實現(xiàn)類洼滚。
類適配器
classAdapter:publicITarget,//共有接口protectedIAdaptee{//多繼承，實現(xiàn)繼承...? ? ? ? ? ? ? ? ? }
不是很好技潘，有局限性遥巴，如果IAdaptee僅僅是個接口，沒有實現(xiàn)享幽，如果換做具體類铲掐，那就沒有了靈活性，一般不推薦使用值桩。C++中可以摆霉，但是在JAVA等語言中不支持。
Adapter模式可以實現(xiàn)的非常靈活奔坟，不必拘泥于GOF23中定義的兩種結(jié)構(gòu)携栋。
Mediator
動機(jī)
在軟件構(gòu)建過程中，經(jīng)常會出現(xiàn)多個對象互相關(guān)聯(lián)交互的情況咳秉，對象之間常常會維持一種復(fù)雜的引用關(guān)系婉支，如果遇到一些需求的更改，這種直接的引用關(guān)系將面臨不斷的變化澜建。
用一個中介對象來封裝（封裝變化）一系列的對象交互向挖。中介者使各對象不需要顯式的相互引用（編譯時依賴to運行時依賴），從而使其耦合松散（管理變化）炕舵，而且可以獨立的改變他們之間的交互何之。
結(jié)構(gòu)
要點總結(jié)
將多個對象間復(fù)雜的關(guān)系關(guān)系解耦，Mediator模式將多個對象間的控制邏輯進(jìn)行集中管理咽筋，變“多個對象互相關(guān)聯(lián)”為“多個對象和一個中介者關(guān)聯(lián)”溶推，簡化了系統(tǒng)的維護(hù)，抵御了可能的變化晤硕。
隨著控制邏輯的復(fù)雜化悼潭，Mediator具體對象的實現(xiàn)可能相當(dāng)復(fù)雜（復(fù)雜的消息機(jī)制）。這時候可以對Mediator對象進(jìn)行分解處理舞箍。
Facade模式是解耦系統(tǒng)間（單向）的對象關(guān)聯(lián)關(guān)系舰褪；Mediator模式是解耦系統(tǒng)內(nèi)部各個對象之間（雙向）的關(guān)聯(lián)關(guān)系。
