上周講述了DOF設(shè)計模式中的“對象創(chuàng)建”模式和“接口隔離”模式韵卤，本周講述DOF設(shè)計模式中的剩下的模式，“對象性能”模式（包括Singleton單件模式和Flyweight享元模式）、“狀態(tài)變化”模式（包括State狀態(tài)模式和Memento備忘錄）兔跌、“數(shù)據(jù)結(jié)構(gòu)”模式（包括Composite組合模式、Iterator迭代器和Chain of Responsibility職責(zé)鏈）、“行為變化”模式（包括Command命令模式和Visitor訪問器）以及“領(lǐng)域規(guī)則”模式（包括Interpreter解析器）赠制。

（一）“對象性能”模式

面向?qū)ο蠛芎玫慕鉀Q了“抽象”的問題，但是必不可免地要付出一定的代價挟憔。對于通常情況來講钟些，面向?qū)ο蟮某杀敬蠖伎梢院雎圆挥嫛５悄承┣闆r绊谭，面向?qū)ο笏鶐淼某杀颈仨氈?jǐn)慎處理政恍。

典型模式：Singleton、Flyweight达传。

1篙耗、Singleton單件模式

Singleton單件模式定義：保證一個類僅有一個實例，并提供一個該實例的全局訪問點宪赶。

Singleton單件模式動機(jī)：在軟件系統(tǒng)中宗弯，經(jīng)常有這樣一個特殊的類，必須保證它們在系統(tǒng)中只存在一個示例搂妻，才能確保他們的邏輯正確性蒙保、以及良好的效率紫岩。

如何繞過常規(guī)的構(gòu)造器雳灵，提供一種機(jī)制來保證一個類只有一個實例憔四？這個應(yīng)該類設(shè)計者的責(zé)任锹引，而不是使用者的責(zé)任寒锚。

優(yōu)點：減少了時間和空間的開銷（new實例的開銷）忽匈；提高了封裝性他嚷，使得外部不易改動實例坤溃。

缺點：懶漢式是以時間換空間的方式引几；餓漢式是以空間換時間的方式昧互。

Singleton單件模式的結(jié)構(gòu)如圖1所示。

圖1

總結(jié)：

（1）Singleton模式中的實例構(gòu)造器可以設(shè)置為protected以允許子類派生。

（2）Singleton模式一般不要支持拷貝構(gòu)造函數(shù)和Clone接口敞掘，因為這有可能會導(dǎo)致多個對象實例叽掘，與Singleton模式的初衷相違背。

（3）實現(xiàn)多線程環(huán)境下安全的Singleton渐逃，注意對雙檢查鎖的正確實現(xiàn)够掠。

雙檢查鎖，在lock的前后判斷m_instance是否為空茄菊。因為可能多個線程都走進(jìn)到m_instance==nullptr分支疯潭，所以之后每個線程在獲得鎖之后要再次判斷m_instance==nullptr，來確保m_instance不會被重復(fù)實例化面殖。但可能出現(xiàn)內(nèi)存讀寫reorder問題竖哩，在經(jīng)過編譯器優(yōu)化后，實例化Singleton可能不是按照分配空間脊僚、構(gòu)造和地址賦值給指針的順序進(jìn)行的相叁，而是按照分配空間、指針賦值辽幌、構(gòu)造這三個步驟增淹，當(dāng)一個線程執(zhí)行到指針賦值后，如果有另一個線程進(jìn)來判斷m_instance指針不為空乌企，直接返回m_instance虑润，并直接使用這個指針，那就會發(fā)生錯誤加酵，因為第一個線程還沒有執(zhí)行構(gòu)造器拳喻，所以這時雙檢查鎖也就是失效了。解決辦法猪腕，將變量聲明為volatile防止編譯器優(yōu)化代碼冗澈。

2、Flyweight享元模式

Flyweight享元模式定義：運(yùn)用共享技術(shù)有效地支持大量的細(xì)粒度對象陋葡。

Flyweight享元模式動機(jī)：在軟件系統(tǒng)中采用純粹對象方案的問題 在于大量細(xì)粒度的對象會很快充斥在系統(tǒng)中亚亲，從而帶來很高的運(yùn)行時代價——主要指內(nèi)存需求方面的代價。

Flyweight享元模式的結(jié)構(gòu)如圖2所示脖岛。

如2

總結(jié)：

（1）面向?qū)ο蠛芎玫慕鉀Q了抽相性的問題朵栖，但是作為一個運(yùn)行在機(jī)器中的程序?qū)嶓w，我們需要考慮對象的代價問題柴梆。Flyweight主要解決面向的代價問題，一般不觸及面向?qū)ο蟮某橄笮詥栴}终惑。

（2）Flyweight采用對象共享的做法來降低系統(tǒng)中的對象的個數(shù)绍在，從而降低細(xì)粒度對象給系統(tǒng)帶來的內(nèi)存壓力。在具體實現(xiàn)方面，要注意對像狀態(tài)的處理偿渡。

（3）對象的數(shù)量太大臼寄，從而導(dǎo)致對像內(nèi)存開銷加大——什么樣的數(shù)量才算大？這需要我們仔細(xì)根據(jù)具體應(yīng)用情況進(jìn)行評估溜宽，而不能憑空臆斷吉拳。

（二）“狀態(tài)變化”模式

在組建構(gòu)建過程中，某些對象的狀態(tài)經(jīng)常面臨變化适揉，“狀態(tài)變化”模式可以使變化進(jìn)行有效的管理留攒，同時又維持高層模塊的穩(wěn)定。

典型模式：State嫉嘀、Memento炼邀。

3、State狀態(tài)模式

State狀態(tài)模式定義：允許一個對象在其內(nèi)部狀態(tài)改變是改變它的行為剪侮。從而使對像看起來似乎修改其行為拭宁。

State狀態(tài)模式動機(jī)：在軟件構(gòu)建過程中，某些對象的狀態(tài)如果改變瓣俯，其行為也會隨之而發(fā)生變化杰标，比如文檔處于只讀狀態(tài)，其支持的行為和讀寫狀態(tài)支持的行為就可能會完全不同彩匕。

如何在運(yùn)行時根據(jù)對象的狀態(tài)來透明地更改對象的行為腔剂？而不會為對象操作和狀態(tài)轉(zhuǎn)化之間引入緊耦合？

優(yōu)點：

（1）狀態(tài)模式將與特定狀態(tài)相關(guān)的行為局部化推掸，并且將不同狀態(tài)的行為分割開來桶蝎。

（2）所有狀態(tài)相關(guān)的代碼都存在于某個ConcereteState中，所以通過定義新的子類很容易地增加新的狀態(tài)和轉(zhuǎn)換谅畅。

（3）狀態(tài)模式通過把各種狀態(tài)轉(zhuǎn)移邏輯分不到State的子類之間登渣，來減少相互間的依賴。

?缺點：導(dǎo)致較多的ConcreteState子類毡泻。

State狀態(tài)模式的結(jié)構(gòu)如圖3所示胜茧。

圖3

總結(jié)：

（1）通過擴(kuò)展子類，來添加進(jìn)狀態(tài)仇味，解決狀態(tài)轉(zhuǎn)化問題呻顽，當(dāng)有if...else時，可以轉(zhuǎn)換成此方法丹墨。

（2）State模式將所有與一個特定狀態(tài)相關(guān)的行為都放入一個State的子類對象中廊遍，在對像狀態(tài)切換時， 切換相應(yīng)的對象贩挣；但同時維持State的接口喉前，這樣實現(xiàn)了具體操作與狀態(tài)轉(zhuǎn)換之間的解耦没酣。

（3）為不同的狀態(tài)引入不同的對象使得狀態(tài)轉(zhuǎn)換變得更加明確，而且可以保證不會出現(xiàn)狀態(tài)不一致的情況卵迂，因為轉(zhuǎn)換是原子性的——即要么徹底轉(zhuǎn)換過來裕便，要么不轉(zhuǎn)換。

（4）如果State對象沒有實例變量见咒，那么各個上下文可以共享同一個State對象偿衰，從而節(jié)省對象開銷。

4改览、Memento備忘錄

Memento備忘錄模式定義：在不破壞封裝性的前提下下翎，不活一個對象的內(nèi)部狀態(tài)，并在該對像之外保存這個狀態(tài)恃疯。這樣以后就可以將該對像恢復(fù)到原想保存的狀態(tài)漏设。

Memento備忘錄模式動機(jī)：在軟件構(gòu)建過程中，某些對象的狀態(tài)在轉(zhuǎn)會過程中今妄，可能由于某種需求郑口，要求程序能夠回溯到對像之前處于某個點時的狀態(tài)。如果使用一些公有借口來讓其它對象得到對象的狀態(tài)盾鳞，便會暴露對象的實現(xiàn)細(xì)節(jié)犬性。

如何實現(xiàn)對象狀態(tài)的良好保存與恢復(fù)？但同時又不會因此而破壞對象本身的封裝性腾仅。

Memento備忘錄模式的結(jié)構(gòu)如圖4所示乒裆。

圖4

總結(jié)：

（1）在狀態(tài)轉(zhuǎn)化時，還原到某一個狀態(tài)推励，用原發(fā)器創(chuàng)建備忘錄鹤耍，保存。

（2）備忘錄（Memento）存儲原發(fā)器（Originator）對象的內(nèi)部狀態(tài)验辞，在需要時恢復(fù)原發(fā)器的狀態(tài)稿黄。

（3）Memento模式的核心是信息隱藏，即Originator需要向外接隱藏信息跌造，保持其封裝性杆怕。但同時又需要將其狀態(tài)保持到外界（Memento）

（4）由于現(xiàn)代語言運(yùn)行時（如C#、java等）都具有相當(dāng)?shù)膶ο笮蛄谢С挚翘埃虼送捎眯瘦^高陵珍、又較容易正確實現(xiàn)的序列化方案來實現(xiàn)Memento模式。

（三）“數(shù)據(jù)結(jié)構(gòu)”模式

常常有一些組建在內(nèi)部具有特定的數(shù)據(jù)結(jié)構(gòu)违施，如果讓客戶程序依賴這些特定的數(shù)據(jù)結(jié)構(gòu)互纯，將極大的破壞組件的復(fù)用。這時候磕蒲，將這些數(shù)據(jù)結(jié)構(gòu)封裝在內(nèi)部伟姐，在外部提供統(tǒng)一的接口收苏，來實現(xiàn)與特定數(shù)據(jù)結(jié)構(gòu)無關(guān)的訪問亿卤，是一種行之有效的解決方案愤兵。

典型模式：Composite、Iterator排吴、Chain of Responsibility秆乳。

5、Composite組合模式

Composite組合模式定義：將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層級結(jié)構(gòu)钻哩。Compisite使得用戶對單個對象和組合對象的使用具有一致性（穩(wěn)定）屹堰。

Composite組合模式動機(jī)：軟件在某些情況下，客戶代碼過多地依賴于對像容器復(fù)雜的內(nèi)部實現(xiàn)結(jié)構(gòu)街氢，對象容器內(nèi)部實現(xiàn)結(jié)構(gòu)（而非抽象接口）的變化將因其客戶代碼的頻繁變化扯键，帶來了代碼的維護(hù)性、擴(kuò)展性等弊端珊肃。

如何將“客戶代碼與復(fù)雜的對象容器結(jié)構(gòu)”解耦荣刑？讓對象容器自己來實現(xiàn)自身的復(fù)雜結(jié)構(gòu)，從而使得客戶代碼就像處理簡單對象一樣來處理復(fù)雜的對象容器伦乔？

Composite組合模式的結(jié)構(gòu)如圖5所示厉亏。

圖5

總結(jié)：

（1）Composite模式采用樹形結(jié)構(gòu)來實現(xiàn)普遍存在的對象容器，從而將“一對多”的關(guān)系轉(zhuǎn)化為“一對一”的關(guān)系烈和，使得客戶代碼可以一致地（復(fù)用）處理對象和對象容器爱只，無需關(guān)心處理的是單個對象還是組合的對象容器。

（2）將“客戶代碼與復(fù)雜的對象容器結(jié)構(gòu)”解耦是Composite的核心思想招刹，解耦之后恬试，客戶代碼將與純粹的抽象接口——而非對像容器的內(nèi)部實現(xiàn)結(jié)構(gòu)——發(fā)生依賴，從而更能“應(yīng)對變化”疯暑。

（3）Composite模式在具體實現(xiàn)中训柴，可以讓父對象中的子對象反向追溯；如果父對象有頻繁的遍歷需求缰儿，可使用緩存技巧來改善效率畦粮。

6、Iterator迭代器

Iterator迭代器模式定義：提供一種方法順序訪問一個聚合對象中的各個元素乖阵，而又不暴露（隔離變化宣赔，穩(wěn)定）該對象的內(nèi)部表示。

Iterator迭代器模式動機(jī)：在軟件構(gòu)建過程中瞪浸，集合對象內(nèi)部結(jié)構(gòu)常常變化各異儒将。但對于這些集合對象，我們希望在不暴露其內(nèi)部結(jié)構(gòu)的同時对蒲，可以讓外部客戶代碼透明的訪問其中包含的元素钩蚊；同時這種“透明遍歷”也為“同一種算法在多種集合對象上進(jìn)行操作”提供了可能贡翘。

使用面向?qū)ο蠹夹g(shù)將這種遍歷機(jī)制抽象為“迭代器對象”為“因?qū)ψ兓械募蠈ο蟆碧峁┝艘环N優(yōu)雅的方式。

Iterator迭代器模式的結(jié)構(gòu)如圖6所示砰逻。

圖6

總結(jié)：

（1）迭代抽象：訪問一個聚合對象的內(nèi)容而無需暴露他的內(nèi)部表示鸣驱。

（2）迭代多態(tài)：為遍歷不同的集合結(jié)構(gòu)提供一個統(tǒng)一的接口，從而支持同樣的算法在不同的集合結(jié)構(gòu)上進(jìn)行操作蝠咆。

（3）迭代器健壯性考慮：遍歷的同時更改迭代器所在的集合結(jié)構(gòu)踊东，會導(dǎo)致問題。

7刚操、Chain of Responsibility職責(zé)鏈

Chain of Responsibility職責(zé)鏈模式定義：使多個對像都有機(jī)會處理請求闸翅，從而避免請求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對像連成一條鏈菊霜，并沿著這條鏈傳遞請求坚冀，直到有一個對象處理它為止。

Chain of Responsibility職責(zé)鏈模式動機(jī)：在軟件構(gòu)建的過程中鉴逞，一個請求可能被多個對象處理记某，但是每個請求在運(yùn)行時只能有一個接受者，如果顯示指定华蜒，將必不可少的帶來請求發(fā)送者與接受者的耦合辙纬。

如何使請求的發(fā)送者不需要指定具體的接受者？讓請求的接受者自己在運(yùn)行時決定來處理請求叭喜，從而使兩者解耦贺拣。

Chain of Responsibility職責(zé)鏈模式的結(jié)構(gòu)如圖7所示。

圖7

總結(jié)：

（1）Chain of Responsibility模式的應(yīng)用場合在于“一個請求可能有多個接受者捂蕴，但是最后真正接受者只有一個”譬涡，這時候請求發(fā)送者與接受者的耦合可能出現(xiàn)“變化脆弱”的癥狀，職責(zé)鏈的目的就是將二者解耦啥辨，從而更好的應(yīng)對變化涡匀。

（2）應(yīng)用了Chain of Responsibility模式后，對象的職責(zé)分派將更具靈活性溉知。我們可以在運(yùn)行時動態(tài)添加/修改請求的處理指責(zé)陨瘩。

（3）如果請求傳遞到職責(zé)鏈的末尾仍得不到處理，應(yīng)該有一個合理的缺省機(jī)制级乍。這也是每一個接受者對象的責(zé)任舌劳，而不是發(fā)出請求的對象的責(zé)任。

（四）“行為變化”模式

在組建的構(gòu)建過程中玫荣，組建行為的變化經(jīng)常導(dǎo)致組建本身劇烈的變化甚淡。“行為變化”模式將組建的行為和組建本身進(jìn)行解耦捅厂，從而主持組件的變化贯卦，實現(xiàn)兩者之間的松耦合资柔。

典型模式：Command、Visitor撵割。

8贿堰、Command命令模式

Command命令模式模式定義：將一個請求（行為）封裝為對象，從而使你可用不同的請求睁枕，對客戶進(jìn)行參數(shù)化官边；對請求排隊或記錄請求日志以及支持可撤銷的操作。

Command命令模式動機(jī)：在軟件構(gòu)建構(gòu)成中外遇，“行為請求者”與“行為實現(xiàn)者”通常呈現(xiàn)一種“緊耦合”。但在某些場合——比如需要對行為進(jìn)行“記錄契吉、撤銷（undo）跳仿、事務(wù)”等處理，這種無法抵御變化的緊耦合是不合適的捐晶。

在這種情況下菲语，如何將“行為請求者”與“行為實現(xiàn)者”解耦？將一組行為抽象為對象惑灵，可以實現(xiàn)二者之間的松耦合山上。

Command命令模式的結(jié)構(gòu)如圖8所示。

圖8

總結(jié)：

（1）Command模式的根本目的在于“行為請求者”與“行為實現(xiàn)者”解耦英支，在面向?qū)ο蟮恼Z言中佩憾，常見的實現(xiàn)手段是“將行為抽象為對象”

（2）實現(xiàn)Command接口的具體命令對象ConcreteCommand有時候根據(jù)需要可能會保存一些額外的狀態(tài)信息。通過使用Composite模式干花，可以將多個“命令”封裝為一個“符合命令”MacroCommand

（3）Command模式與C++中的函數(shù)對像有些類似妄帘。但兩者定義行為接口的規(guī)范有所區(qū)別：Command以面向?qū)ο笾械摹敖涌?實現(xiàn)”來定義行為接口規(guī)范，更嚴(yán)格池凄，但有性能損失抡驼；C++函數(shù)對象以函數(shù)簽名來定義行為接口規(guī)范，更靈活肿仑，性能能高致盟。

9、Visitor訪問器

Visitor訪問器模式定義：表示一個作用與某對像結(jié)構(gòu)中的各元素的操作尤慰。使得可以在不改變（穩(wěn)定）各元素的類的前提下定義（擴(kuò)展）作用于這些元素的新操作（變化）馏锡。

Visitor訪問器模式動機(jī)：在軟件構(gòu)建的過程中，由于需求的改變割择，某些類層次結(jié)構(gòu)中常常需要增加新的行為（方法）眷篇。如果直接在類中做這樣的更改，將會給子類帶來很繁重的變更負(fù)擔(dān)荔泳，甚至破壞原有設(shè)計蕉饼。

如何在不更改類層次結(jié)構(gòu)的前提下虐杯，在運(yùn)行時根據(jù)需要透明地為類層次結(jié)構(gòu)上的各個類動態(tài)添加新的操作，從而避免上述問題昧港？

Visitor訪問器模式的結(jié)構(gòu)如圖9所示擎椰。

圖9

總結(jié)：

（1）Vistor模式通過所謂的雙重分發(fā)（double dispatch）來實現(xiàn)在不更改（不添加新的操作-編譯時）Element類層次結(jié)構(gòu)的前提下，在運(yùn)行時透明地為類層次結(jié)構(gòu)上的各個類動態(tài)添加新的操作（支持變化）创肥。

（2）所謂雙重分發(fā)即Vistor模式中間包括了兩個多態(tài)分發(fā)（注意其中的多態(tài)機(jī)制）：第一個accept方法的多態(tài)解析达舒；第二個為visitElementX方法的多態(tài)辨析。

（3）Visitor模式最大的缺點在于擴(kuò)展類層次結(jié)構(gòu)（增添新的Element子類）叹侄，會導(dǎo)致Visitor類的改變巩搏。因此Visitor模式適用于“Element類層次結(jié)構(gòu)穩(wěn)定，而其中的操作卻進(jìn)場面臨頻繁改動”趾代。

（五）“領(lǐng)域規(guī)則”模式

在特定領(lǐng)域內(nèi)贯底，某些變化雖然頻繁，但可以抽象為某種規(guī)則撒强。這時候禽捆，結(jié)合特定領(lǐng)域，將問題抽象為語法規(guī)則飘哨，從而給出該領(lǐng)域下的一般性解決方案胚想。

典型模式：Interpreter。

10芽隆、Interpreter解析器

Interpreter解析器模式定義：給定一個語言浊服，定義它的文法的一種表示，并定義一種解釋器摆马，這個解釋器使用該表示來解釋語言中的句子臼闻。

Interpreter解析器模式動機(jī)：在軟件構(gòu)建過程中，如果某一特定領(lǐng)域的問題比較復(fù)雜囤采，類似的結(jié)構(gòu)不斷的重復(fù)出現(xiàn)述呐，如果使用普通的變成方式來實現(xiàn)將面臨非常頻繁的變化。

在這種情況下蕉毯，將特定領(lǐng)域的問題表達(dá)為某種語法規(guī)則下的句子乓搬，然后構(gòu)建一個解析器來解釋這樣的句子，從而達(dá)到解決問題的目的代虾。

Interpreter解析器模式的結(jié)構(gòu)如圖10所示进肯。

圖10

總結(jié)：

（1）Interpreter模式的應(yīng)用場合是Interpreter模式應(yīng)用中的難點，只有滿足“業(yè)務(wù)規(guī)則頻繁變化棉磨，且類似的結(jié)構(gòu)不斷重復(fù)出現(xiàn)江掩，并且容易抽象為語法規(guī)則的問題”才適合使用Interpreter模式。

（2）使用Interpreter模式來表示文法規(guī)則，從而可以使用面向?qū)ο蠹记蓙矸奖愕亍皵U(kuò)展”文法环形。

（3）Interpreter模式比較適合簡單的文法表示策泣，對于復(fù)雜的文法表示，Interpreter模式會產(chǎn)生比較大的類層次結(jié)構(gòu)抬吟，需要求助于語法分析生成器這樣的標(biāo)準(zhǔn)工具萨咕。

設(shè)計模式總結(jié)

一個目標(biāo)：管理變化，提高復(fù)用火本。

兩種手段：分解危队，抽象。

八大原則：依賴倒置原則（DIP）

? ? ? ? ? ? ? ? ? ? 開放封閉原則（OCP）

? ? ? ? ? ? ? ? ? ? 單一職責(zé)原則（SRP）

? ? ? ? ? ? ? ? ? ? Liskov替換原則（LSP）

? ? ? ? ? ? ? ? ? ? 接口隔離原則（ISP）

? ? ? ? ? ? ? ? ? ? 優(yōu)先使用對象組合钙畔，而不是類繼承

? ? ? ? ? ? ? ? ? ? 封裝變化點

? ? ? ? ? ? ? ? ? ? 針對接口編程茫陆，而不是針對實現(xiàn)編程

八大原則關(guān)系

重構(gòu)方法：靜態(tài)變?yōu)閯討B(tài)，早綁定變?yōu)橥斫壎ㄈ婿^承變?yōu)榻M合盅弛，編譯時依賴變?yōu)檫\(yùn)行時依賴，緊耦合變?yōu)樗神詈稀?/p>

C++對象模型：

C++對象模型

不需要設(shè)計模式的情況：

（1）代碼可讀性很差時叔锐；（2）需求理解很淺時；（3）變化沒有顯現(xiàn)時见秽；（4）不是系統(tǒng)的關(guān)鍵依賴點時愉烙；（5）項目沒有復(fù)用價值時；（6）項目將來要發(fā)布時解取。

設(shè)計模式經(jīng)驗：

（1）不要為模式而模式步责；（2）關(guān)注抽象類和接口；（3）理清變化點和穩(wěn)定點禀苦；（4）審視依賴關(guān)系蔓肯；（5）要有Framework和Appliacation的區(qū)隔思維；（6）良好的設(shè)計是演化的結(jié)果振乏。