中國是一個含蓄的民族，處對象一般都得通過一個介紹人。
這是一本闡述微觀設計的書，而不是闡述宏觀設計的書。
《Java與模式》首先闡述了代碼的設計原則，又描述了怎樣來創(chuàng)建一個類或?qū)ο?，緊接著告訴大家怎樣來組織這些類和對象來實現(xiàn)功能。它是設計模式，而不是架構(gòu)模式。
OO面向?qū)ο缶幊蹋瑢嵸|(zhì)上是面向抽象編程，即面向接口編程。所謂的面向接口編程，指類之間都要使用接口來通信。類來封裝對象的行為，接口來封裝類之間的通信方法，接口是更高層次的抽象。這里的接口可以是一個具體類，一個抽象類，或是一個Java接口，它不單單指Java接口。
第四章： 開閉原則
抽象化：面向?qū)ο笤O計的重要原則是創(chuàng)建抽象化，并且從抽象化導出具體化。具體化可以給出不用的版本，每一個版本都給出不同的實現(xiàn)。
1。開閉原則
一個軟件應該對擴展開放，對修改關閉。
一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里面。
繼承應當被看做是封裝變化的方法，而不應當被認為是從一般的對象生成特殊的對象的方法。
一種可變性不應當與另一種可變性混合在一起。最好所有的繼承結(jié)構(gòu)不超過兩層，不然就意味著將兩種不同的可變性混合在了一起。
2。里氏代換原則
任何基類可以出現(xiàn)的地方，子類一定可以出現(xiàn)。
3。依賴倒轉(zhuǎn)原則
要依賴于抽象，不要依賴于實現(xiàn)。
4。合成/聚合復用原則
要盡量使用合成/聚合，而不是繼承關系達到復用的目的。
5。迪米特法則
一個軟件實體應當與盡可能少的其它實體發(fā)生相互作用。(模塊之間)
6。接口隔離原則
應當為客戶端提供盡可能小的單獨的接口，而不是提供大的總接口。
7。策略模式
將每一個算法用一個類封裝起來，多個類實現(xiàn)同一個接口。用到哪種策略就實例化哪個類。
**************************************************************
第五章： 接口
它應當只用來聲明一個新的類型
1。接口可以認為是繼承的一種，叫做接口繼承，而extends叫做實現(xiàn)繼承。接口是個角色，而實現(xiàn)類是這個角色的演員。接口這個角色使之可以動態(tài)的智能的選擇演員。
可插入性：
別的類只讓這個角色做事情，而它不必關心是哪個演員做的。
2。用它來聲明一個新的類型。在理想情況下，一個具體的java類應當只實現(xiàn)java接口和抽象java類中聲明過的方法，而不應當給出多余的方法。
3。類型等級結(jié)構(gòu)：java接口一般用來作為一個類型的等級結(jié)構(gòu)的起點。
class本身是個類型，但它的起點應該是它所實現(xiàn)的接口。
混合類型：當一個具體的類處于一個類的等級結(jié)構(gòu)中的時候，它再實現(xiàn)一個接口，它就成了混合類型，而不單單是等級結(jié)構(gòu)中的子類型?；旌项愋褪潜ＷC基于這個等級結(jié)構(gòu)類型的可插入性的關鍵。
**************************************************************
第六章 抽象類
1。它代表一個抽象概念，它和接口一樣，是一個等級結(jié)構(gòu)的起點。但這點上它不如接口好。
2。繼承都是從抽象類開始的。抽象類是用來繼承的，而具體類不是用來繼承的。具體類應該使用聚合的方法實現(xiàn)重用，而避免使用繼承來實現(xiàn)。
例子：類B繼承類A ===》寫個接口或抽象類C，類A和類B實現(xiàn)C。
類“貓”繼承“虎”===》他倆都實現(xiàn)“動物”接口
3。在一個從抽象類到多個具體類的繼承關系中，共同的代碼應當盡量移動到抽象類里。換句話說，共同的代碼應當盡量向等級結(jié)構(gòu)上方移動。
反之，抽象類應當擁有盡量少的數(shù)據(jù)，數(shù)據(jù)應放在等級結(jié)構(gòu)低端，即具體類中定義。
4。依賴倒轉(zhuǎn)原則：針對抽象類編程，不針對具體子類編程。
5。擴展超類，不要修改超類的方法，不建議使用重寫。
*************************************************************
第八章 依賴倒轉(zhuǎn)原則
1。要依賴于抽象，不要依賴于實現(xiàn)。把抽象層次作為復用的重點，而不是具體層次。
2。三種偶合關系：
零偶合：兩個類沒關系
具體偶合：發(fā)生在兩個具體的類，由一個類對另一個具體的類直接引用。
抽象偶合：發(fā)生在一個具體類和一個抽象類，更具靈活性。(好)
客戶類盡量和抽象層打交道。
3。依賴倒轉(zhuǎn)原則的兩種表述：
抽象不應當依賴于細節(jié)，細節(jié)應當依賴于抽象；
要針對接口編程，不要針對實現(xiàn)編程。(重點)
4。針對接口編程：應當使用java接口和抽象java類進行變量的類型聲明，參量的類型聲明，方法的返還類型聲明，以及數(shù)據(jù)類型的轉(zhuǎn)換等。
不要針對實現(xiàn)編程：不應當使用具體java類進行變量的類型聲明，參量的類型聲明，方法的返還類型聲明，以及數(shù)據(jù)類型的轉(zhuǎn)換等。
5。一個具體java類應當只實現(xiàn)java接口和抽象java類中聲明過的方法，而不應當給出多余的方法。
6。在多數(shù)情況下，一個java程序需要引用一個對象。這個時候，如果這個對象有一個抽象類型的話，應當使用這個抽象類型作為變量的靜態(tài)類型。 接口 x = new 類();
7。java語言中創(chuàng)建一個對象的過程是違背“開閉”和“依賴倒轉(zhuǎn)”原則的。因為對象被創(chuàng)建之后，它就確定了，不能由抽象自動尋找使用哪個對象來處理問題。
8。缺省適配模式：抽象類的唯一優(yōu)點是有具體類的部分實現(xiàn)，接口補充了抽象類的所有缺點，所以聯(lián)合使用抽象類和接口是一個很好的選擇。
************************************************************
第九章 接口隔離原則
1。使用多個專門的接口比使用單一的總接口要好。
從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小的接口上的。一個接口應當簡單地代表一個角色，而不是多個角色。多個演員可以同時演一個角色，就象孫悟空的孩兒一樣。
*************************************************************
第十章 合成/聚合復用原則
1。合成/聚合區(qū)別：聚合用來表示“擁有”或整體與部分的關系，而合成則用來表示一種強得多的“擁有”關系。在一個合成關系里，部分和整體的生命周期是一樣的。合成就象所說的“合成品”，拆開就壞。
2。當兩個類有些類似相同的屬性的時候，要分清他們是is-a還是has-a關系。如果是is-a關系，才可以用繼承；如果是has-a就另當別論了。
***********************************************************
第十一章 迪米特法則
1。一個對象應當對其它對象有盡可能少的了解。
2。兩個類不必直接通信，可以通過第三者(抽象)轉(zhuǎn)發(fā)這個調(diào)用。
這個抽象的第三者可以是門面，可以是調(diào)停者，甚至是一個抽象類或接口。
3。模塊要獨立，獨立被封裝，他們只靠public的API來通信。
4。只要有可能，一個類應當設計成不變類，其屬性都應該是私有的。
5。如果一個類有太多的包訪問權(quán)限的方法，可以考慮使用多個類把一個類的私有方法和公有方法分開。
*************************************************************
第三部分：創(chuàng)建模式
建造產(chǎn)品的過程就是創(chuàng)建對象的過程，本部分描述怎樣創(chuàng)建對象。
它是對類是實例化過程的抽象化。分為類的創(chuàng)建模式和對象的創(chuàng)建模式兩種。類的創(chuàng)建模式使用繼承，將類的創(chuàng)建延遲到了子類，從而封裝了客戶端將得到哪些具體類的信息。對象的創(chuàng)建模式則把對象的創(chuàng)建過程動態(tài)的委派給另一個對象，從而動態(tài)的決定客戶端將得到哪些具體類的實例，以及這些類的實例是如何被創(chuàng)建和組合在一起的。
靜態(tài)方法體內(nèi)用來實例化對象，這樣的方法可以稱作靜態(tài)工廠方法。
第十二章 簡單工廠（FACTORY）模式
追MM少不了請吃飯了，麥當勞的雞翅和肯德基的雞翅都是MM愛吃的東西，雖然口味有所不同，但不管你帶MM去麥當勞或肯德基，只管向服務員說“來四個雞翅”就行了。麥當勞和肯德基就是生產(chǎn)雞翅的Factory
工廠模式：客戶類和工廠類分開。消費者任何時候需要某種產(chǎn)品，只需向工廠請求即可。消費者無須修改就可以接納新產(chǎn)品。缺點是當產(chǎn)品修改時，工廠類也要做相應的修改。如：如何創(chuàng)建及如何向客戶端提供。
1。工廠模式主要負責將大量有共同接口(即前面講的抽象第三者)的類實例化。
要求 制造
客戶-------->工廠(方法返回抽象產(chǎn)品)-------->產(chǎn)品(實現(xiàn)抽象產(chǎn)品接口)
下面是多個產(chǎn)品及抽象產(chǎn)品的情況，解決方案是仍然只使用一個factory。
但新增產(chǎn)品的話必將導致工廠類的修改。如：如何創(chuàng)建及如何向客戶端提供。
2．一個工廠類可以有多于一個的靜態(tài)工廠方法，用于創(chuàng)建不同抽象類型的產(chǎn)品對象。
3．如果一個工廠只創(chuàng)建一個產(chǎn)品對象，那么可以省略掉抽象產(chǎn)品層。
4．有時也可以將工廠和抽象產(chǎn)品層合并起來，這時候一個抽象產(chǎn)品類同時也是子類的工廠。
如果抽象產(chǎn)品層已經(jīng)被省略，那么也可以將工廠和產(chǎn)品層合并在一起，這就是三個角色全部合并的情況。
5．工廠可以循環(huán)使用它所創(chuàng)建的產(chǎn)品對象。
*******************************************************************************
第十三章 工廠方法（FACTORY METHOD）模式
請MM去麥當勞吃漢堡，不同的MM有不同的口味，要每個都記住是一件煩人的事情，我一般采用Factory Method模式，帶著MM到服務員那兒，說“要一個漢堡”，具體要什么樣的漢堡呢，讓MM直接跟服務員說就行了。
1． 工廠方法模式：核心工廠類不再負責所有產(chǎn)品的創(chuàng)建，而是將具體創(chuàng)建的工作交給子類去做，成為一個抽象工廠角色（一般是抽象類），僅負責給出具體工廠類必須實現(xiàn)的接口，而不接觸哪一個產(chǎn)品類應當被實例化這種細節(jié)。具體做法是，按照產(chǎn)品的等級結(jié)構(gòu)設計一個同結(jié)構(gòu)的工廠等級結(jié)構(gòu)，然后由相應的工廠角色創(chuàng)建其商品角色?？蛻舳私巧珓?chuàng)建工廠對象，使用工廠對象的方法從而創(chuàng)建產(chǎn)品對象（工廠方法創(chuàng)建對象）。
2． 如果需要加入一個新的產(chǎn)品，只需加入一個工廠類和一個產(chǎn)品類，它支持“開閉”原則。
3． 工廠方法所返還的產(chǎn)品類型應當是抽象類型，而不是具體類型。
4． 聚集：多個對象聚集在一起；聚集對象是能夠包容一組對象的容器對象。聚集都實現(xiàn)了
Collection接口，都提供iterator（）方法返回一個Iterator對象。Iterator()就是一個工廠方法，它返回了對象集合。
5． 所有java都實現(xiàn)了Collection接口和List接口。其中List接口給出兩個工廠方法：iterator()和listIterator()；分別返回Iterator對象和ListIterator對象。而后者是前者的子接口。
6． 工廠方法模式是關于對象的創(chuàng)建；模版方法模式是關于對象的行為。
**************************************************************
第十四章 抽象工廠模式
請MM吃麥當勞，我是真記不起她吃啥口味來著了。MM這回生氣了，沒等我?guī)椒諉T那，她要了一份麥當勞漢堡，跑肯德基那又要了一份漢堡?？课矣侄嗷ㄒ环蒎X。
1． 抽象工廠模式可以向客戶端提供一個接口，使客戶端在不必指定產(chǎn)品的具體類型的情況下，創(chuàng)建多個產(chǎn)品族中的產(chǎn)品對象。這時候，一個具體工廠可以對應多個抽象產(chǎn)品的具體產(chǎn)品了。抽象工廠模式面對的是多個產(chǎn)品等級結(jié)構(gòu)的系統(tǒng)設計。
上圖相同顏色為一個產(chǎn)品族。產(chǎn)品族指：麥當勞和肯德基的同類食品，比如漢堡。
如圖我們沒有創(chuàng)建多個抽象工廠來對應對個抽象產(chǎn)品。而采用一個抽象工廠和產(chǎn)品族的概念來解決問題的。這樣，產(chǎn)品族和產(chǎn)品等級結(jié)構(gòu)的關系是二維的。
*******************************************************************************
第十五章 單例模式（SINGLETON）
1． 它是對象的創(chuàng)建模式（非類的創(chuàng)建模式），單例模式確保一個類只有一個實例，而且自行實例化并向整個系統(tǒng)提供這個實例。這個類叫做單例類。
2．不要使用單例類來管理共享資源的生命周期，只有確定它只有一個實例的時候才可使用。
*****************************************************************************
第十六章 單例模式與MX記錄
最常見的目錄服務包括LDAP 和DNS。
1． DNS：即域名服務（Domain Name Service）,電腦用戶在網(wǎng)絡上通過IP找到其它電腦就是用DNS服務器。
2． LDAP：Lightweight Directory access Protocol
3． MX記錄：MX（Mail Exchange）記錄就是郵件交換記錄。
4． JNDI架構(gòu)：java命名和地址界面（Java Naming and Directory Interface）,由SUN引進的，為java系統(tǒng)提供支持各種目錄類型的一個一般性的訪問界面。它提供命名和目錄服務，以對應用程序透明的方式插入到系統(tǒng)里。(實質(zhì)上是java application與其它目錄類型的一個訪問接口)
*******************************************************************************
第十七章 多例模式與多語言支持
1． 它與單例模式的唯一不同是它可以有多個實例對象。它實際是單例模式的自然推廣。
2． 有上限數(shù)目實例對象的多例叫上限多例模式，如果上限為1，那它就是單例模式。也有無上限多例模式。
*******************************************************************************
第十九章 建造（BUILDER）模式
MM最愛聽的就是“我愛你”這句話了，見到不同地方的MM,要能夠用她們的方言跟她說這句話哦，我有一個多種語言翻譯機，上面每種語言都有一個按鍵，見到MM我只要按對應的鍵，它就能夠用相應的語言說出“我愛你”這句話了，國外的MM也可以輕松搞掂，這就是我的“我愛你”builder。（這一定比美軍在伊拉克用的翻譯機好賣）
1。建造模式：將產(chǎn)品的內(nèi)部表象和產(chǎn)品的生成過程分割開來，從而使一個建造過程生成具有不同的內(nèi)部表象的產(chǎn)品對象。建造模式使得產(chǎn)品內(nèi)部表象可以獨立的變化，客戶不必知道產(chǎn)品內(nèi)部組成的細節(jié)。建造模式可以強制實行一種分步驟進行的建造過程。
3． 它實際是在工廠的基礎上，在客戶和抽象工廠中間加了一層director（導演），用導演提供方法來建造產(chǎn)品零件，從而實現(xiàn)讓客戶不必關心產(chǎn)品內(nèi)部由什么零件組成。建造模式用來解決具體產(chǎn)品有多個復雜零件的情況，并且具體產(chǎn)品之間沒有任何聯(lián)系，具體產(chǎn)品共同實現(xiàn)一個標識接口。另外，建造模式要求具體建造者必須提供返還類型方法。
*******************************************************************************
第２０章 原始模型（Prototype）模式
跟MM用QQ聊天，一定要說些深情的話語了，我搜集了好多肉麻的情話，需要時只要copy出來放到QQ里面就行了，這就是我的情話prototype了。
原始模型模式：通過給出一個原型對象來指明所要創(chuàng)建的對象的類型，然后用復制這個原型對象的方法創(chuàng)建出更多同類型的對象。原始模型模式允許動態(tài)的增加或減少產(chǎn)品類，產(chǎn)品類不需要非得有任何事先確定的等級結(jié)構(gòu)，原始模型模式適用于任何的等級結(jié)構(gòu)。缺點是每一個類都必須配備一個克隆方法。
１． 與工廠和建造模式都類似，它適用于產(chǎn)品的等級結(jié)構(gòu)經(jīng)常變化的情況。
*******************************************************************************
第２１章 JavaBean的“冷藏”和“解凍”
１． 串行化：串行化使得一個程序可以把一個完整的對象寫在一個Byte流里面，或者從一個Byte流里面讀出一個事先存儲在里面的完整的對象；串行化可以把Java對象和原始數(shù)據(jù)類型轉(zhuǎn)換成一個適合于某種網(wǎng)絡或文件系統(tǒng)的Byte流。串行化處理可以很容易地將一個Java對象和一個二進制流之間相互轉(zhuǎn)換。
*******************************************************************************
第四部分 結(jié)構(gòu)模式
上一部分描述了怎樣創(chuàng)建對象，這一部分來描述對象（類）之間怎樣來通信,來體現(xiàn)對象的作用。
基本套路都是使兩個類都實現(xiàn)一個接口，這個接口可以是具體類或抽象類或Java接口，從而實現(xiàn)這兩個類的通信。
結(jié)構(gòu)模式描述如何將類或者對象結(jié)合在一起形成更大的結(jié)構(gòu)。分為類的結(jié)構(gòu)模式和對象的結(jié)構(gòu)模式兩種。
類的結(jié)構(gòu)模式：它使用繼承來把類，接口等組合在一起，以形成更大的結(jié)構(gòu)。類的結(jié)構(gòu)模式是靜態(tài)的。
對象的結(jié)構(gòu)模式：它描述怎樣把不同類型的對象組織在一起，以實現(xiàn)新的功能的方法。對象的結(jié)構(gòu)模式是動態(tài)的。
第２２章 適配器（Adapter）模式
在朋友聚會上碰到了一個美女Sarah，從香港來的，可我不會說粵語，她不會說普通話，只好求助于我的朋友kent了，他作為我和Sarah之間的Adapter，讓我和Sarah可以相互交談了(也不知道他會不會耍我)
適配器（變壓器）模式：把一個類的接口變換成客戶端所期待的另一種接口，從而使原本因接口原因不匹配而無法一起工作的兩個類能夠一起工作。適配類可以根據(jù)參數(shù)返還一個合適的實例給客戶端。
１． 類的適配器模式：adapter繼承源類并實現(xiàn)目標接口。Adapter為具體類。
對象的適配器模式：adapter實現(xiàn)目標接口。源類沒有的方法在adapter里補充。
２． 它實際是連接源與目標的一個“接口”，適配器可以是抽象類或具體類。
第23章 缺省適配模式
１． 在任何時候，如果不準備實現(xiàn)一個接口的所有方法時，就可以寫一個繼承該接口的抽象類，給出所有方法的平庸的具體實現(xiàn)。這樣，從這個抽象類再繼承下去的子類就不必實現(xiàn)所有的方法了。這時候，新的類就是Adapter類，而給出平庸實現(xiàn)的抽象類就可以被當做源？
第24章 XMLProperties與適配器模式
1．SAX：Simple API for XML .它是一個通用的為各種不同的XML瀏覽器而設計的接口，正如JDBC是為各種不同的關系數(shù)據(jù)庫而設計的接口一樣。使XML不必局限于某一個瀏覽器。
第25章 合成(Composite)模式
Mary今天過生日。“我過生日，你要送我一件禮物。”“嗯，好吧，去商店，你自己挑。”“這件T恤挺漂亮，買，這條裙子好看，買，這個包也不錯，買。”“喂，買了三件了呀，我只答應送一件禮物的哦。”“什么呀，T恤加裙子加包包，正好配成一套呀，小姐，麻煩你包起來。”“……”，MM都會用Composite模式了，你會了沒有？
合成模式：合成模式將對象組織到樹結(jié)構(gòu)中，可以用來描述整體與部分的關系。合成模式就是一個處理對象的樹結(jié)構(gòu)的模式。合成模式把部分與整體的關系用樹結(jié)構(gòu)表示出來。合成模式使得客戶端把一個個單獨的成分對象和由他們復合而成的合成對象同等看待。
１． 無論繼承還是合成，都通過“樹”結(jié)構(gòu)來組織對象，分為：從下向上，從上向下和雙向的。樹枝，葉子：）樹枝可以沒有葉子結(jié)點，但它仍是樹枝。樹枝是葉子的容器。
２． 透明式的合成模式結(jié)構(gòu)：所有樹枝和葉子共有同一個接口，此抽象接口定義了所有商業(yè)邏輯方法和聚集管理方法（比如getChild() remove()等）。
安全式的合成模式結(jié)構(gòu)：所有樹枝和葉子共用一個接口，接口只提供商業(yè)邏輯等方法，沒有處理聚集的方法。樹枝實現(xiàn)此接口自己再添加管理聚集（比如getChild() remove()等）的方法。葉子實現(xiàn)接口定義的商業(yè)邏輯的一些方法。
在這里可以看到面向接口編程的思想，兩個具體類不能直接進行作用，他們使用接口來進行通信。
第26章 裝飾(Decorator)模式
Mary過完輪到Sarly過生日，還是不要叫她自己挑了，不然這個月伙食費肯定玩完，拿出我去年在華山頂上照的照片，在背面寫上“最好的的禮物，就是愛你的Fita”，再到街上禮品店買了個像框（賣禮品的MM也很漂亮哦），再找隔壁搞美術(shù)設計的Mike設計了一個漂亮的盒子裝起來……，我們都是Decorator，最終都在修飾我這個人呀，怎么樣，看懂了嗎？
裝飾模式：裝飾模式以對客戶端透明（客戶并不會覺得裝飾前后對象有什么不同）的方式擴展對象的功能，是繼承關系的一個替代方案，提供比繼承更多的靈活性。動態(tài)給一個對象增加功能，這些功能可以再動態(tài)的撤消。增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能。
１． 在以下情況下應當使用裝飾模式：
１． 需要擴展一個類的功能，或給一個類增加附加責任。
２． 需要動態(tài)地給一個對象增加功能，這些功能可以再動態(tài)地撤消。
３． 需要增加由一些基本功能的排列組合而產(chǎn)生的非常大量的功能，從而使繼承關系變得不現(xiàn)實。
２． 如上圖，要把大圣本尊裝飾成花鳥魚蟲。定義一個齊天大圣接口，猢猻（大圣本尊）和大圣化身實現(xiàn)齊天大圣接口；大圣化身是個抽象的具體類，花鳥魚蟲再繼承它；大圣化身和它的子類都實現(xiàn)齊天大圣的（實例的）方法（即大圣本尊的方法）。使用如下：
齊天大圣 猴 = new 大圣本尊（）；
齊天大圣 bird = new 鳥（猴）；//把猴傳進來
這樣就把孫猴子裝飾成bird了
３． 為什么不用繼承？繼承是靜態(tài)的，它在系統(tǒng)運行前就決定了；而裝飾模式可以讓我們動態(tài)的決定把鳥“貼”給他還是把蟲“貼”給他。
4．
看上面的代碼，fly()是雀兒類自己的方法，如果bird引用的定義類型為齊天大圣，那么bird.fly()將報錯！因此C只能執(zhí)行齊天大圣和大圣本尊共有的方法，盡管它執(zhí)行的是大圣本尊定義的方法里的內(nèi)容。
４． 裝飾模式將一個東西的表皮換掉，而保持它的內(nèi)心，并提高（擴展）性能，是繼承的替代方案。策略模式是在保持接口不變的情況下，使具體算法可以互換。
５． 裝飾模式和適配器模式都是包裝（Wrapper）模式。他們的區(qū)別：適配器模式把一個API轉(zhuǎn)換成另一個API，而裝飾模式是保持被包裝的對象的API。
第28章 代理(Proxy)模式
跟MM在網(wǎng)上聊天，一開頭總是“hi,你好”,“你從哪兒來呀？”“你多大了？”“身高多少呀？”這些話，真煩人，寫個程序作為我的Proxy吧，凡是接收到這些話都設置好了自動的回答，接收到其他的話時再通知我回答，怎么樣，酷吧。
代理模式：代理模式給某一個對象提供一個代理對象，并由代理對象控制對源對象的引用。代理就是一個人或一個機構(gòu)代表另一個人或者一個機構(gòu)采取行動。某些情況下，客戶不想或者不能夠直接引用一個對象，代理對象可以在客戶和目標對象直接起到中介的作用?？蛻舳朔直娌怀龃碇黝}對象與真實主題對象。代理模式可以并不知道真正的被代理對象，而僅僅持有一個被代理對象的接口，這時候代理對象不能夠創(chuàng)建被代理對象，被代理對象必須有系統(tǒng)的其他角色代為創(chuàng)建并傳入。（例如：桌面快捷方式就是可執(zhí)行文件的代理）
１． 代理主題不改變主題的接口，因為模式的用意是不讓客戶端感覺到代理的存在；其次，代理使用委派將客戶端的調(diào)用委派給真實的主題對象，換言之，代理起到的是傳遞請求的作用；最后，代理主題在傳遞請求之前和之后都可以執(zhí)行特定的操作，而不是單純的傳遞請求。
２． 代理模式強調(diào)代理對真實主題的使用施加控制。
第31章 享元(Flyweight Pattern)模式
每天跟MM發(fā)短信，手指都累死了，最近買了個新手機，可以把一些常用的句子存在手機里，要用的時候，直接拿出來，在前面加上MM的名字就可以發(fā)送了，再不用一個字一個字敲了。共享的句子就是Flyweight，MM的名字就是提取出來的外部特征，根據(jù)上下文情況使用。
享元模式：FLYWEIGHT在拳擊比賽中指最輕量級。享元模式以共享的方式高效的支持大量的細粒度對象。享元模式能做到共享的關鍵是區(qū)分內(nèi)蘊狀態(tài)和外蘊狀態(tài)。內(nèi)蘊狀態(tài)存儲在享元內(nèi)部，不會隨環(huán)境的改變而有所不同。外蘊狀態(tài)是隨環(huán)境的改變而改變的。外蘊狀態(tài)不能影響內(nèi)蘊狀態(tài)，它們是相互獨立的。將可以共享的狀態(tài)和不可以共享的狀態(tài)從常規(guī)類中區(qū)分開來，將不可以共享的狀態(tài)從類里剔除出去?？蛻舳瞬豢梢灾苯觿?chuàng)建被共享的對象，而應當使用一個工廠對象負責創(chuàng)建被共享的對象。享元模式大幅度的降低內(nèi)存中對象的數(shù)量。
１． 分為單純享元模式和復合享元模式，復合享元模式實際是單純享元模式與合成模式的組合。
２． 系統(tǒng)內(nèi)有大量可共享的對象才可以使用享元模式。
第32章 門面(Facade)模式
我有一個專業(yè)的Nikon相機，我就喜歡自己手動調(diào)光圈、快門，這樣照出來的照片才專業(yè)，但MM可不懂這些，教了半天也不會。幸好相機有Facade設計模式，把相機調(diào)整到自動檔，只要對準目標按快門就行了，一切由相機自動調(diào)整，這樣MM也可以用這個相機給我拍張照片了。
門面模式：外部與一個子系統(tǒng)的通信必須通過一個統(tǒng)一的門面對象進行。門面模式提供一個高層次的接口，使得子系統(tǒng)更易于使用。每一個子系統(tǒng)只有一個門面類，而且此門面類只有一個實例，也就是說它是一個單例模式。但整個系統(tǒng)可以有多個門面類。
第33章 橋梁(Bridge)模式
早上碰到MM，要說早上好，晚上碰到MM，要說晚上好；碰到MM穿了件新衣服，要說你的衣服好漂亮哦，碰到MM新做的發(fā)型，要說你的頭發(fā)好漂亮哦。不要問我“早上碰到MM新做了個發(fā)型怎么說”這種問題，自己用BRIDGE組合一下不就行了
橋梁模式：將抽象化與實現(xiàn)化脫耦，使得二者可以獨立的變化，也就是說將他們之間的強關聯(lián)變成弱關聯(lián)，也就是指在一個軟件系統(tǒng)的抽象化和實現(xiàn)化之間使用組合/聚合關系而不是繼承關系，從而使兩者可以獨立的變化。
１． 繼承是強耦合，聚合是弱耦合，所以盡量使用聚合編程，在橋梁模式中，就是使用聚合來代替抽象與具體的強耦合的。
2．抽象化角色（抽象類）：它持有實現(xiàn)化角色（抽象類）的引用，并將（某些）聲明方法的實現(xiàn)委派給實現(xiàn)化角色。
修正抽象化角色：它繼承抽象化角色，它將繼承來的方法的實現(xiàn)修正成別的實現(xiàn)了。
實現(xiàn)化角色（抽象類）：它聲明了抽象方法。
具體實現(xiàn)化角色：它實現(xiàn)了實現(xiàn)化角色聲明的抽象方法。
第五部分 行為模式
行為模式（Behavioral Pattern）是對在不同對象之間劃分責任和算法的抽象化。行為模式不僅僅是關于類和對象的，而且是關于他們之間的相互作用的。
分為：
類的行為模式：類的行為模式使用繼承關系在幾個類之間分配行為。
對象的行為模式：對象的行為模式則使用對象的聚合來分配行為。
第34章 不變(Immutable)模式
１． 不變模式：一個對象的狀態(tài)在對象被創(chuàng)建之后就不再變化。
２． 不變模式只涉及一個類。它又分為：
弱不變模式：其子類可以是可變的類
強不變模式：類以及它的方法都是final的，因此它沒有子類。（String類是）
第35章 策略(Strategy)模式
跟不同類型的MM約會，要用不同的策略，有的請電影比較好，有的則去吃小吃效果不錯，有的去海邊浪漫最合適，目的都是為了得到MM的芳心，我的追MM錦囊中有好多Strategy哦。
策略模式：策略模式針對一組算法，將每一個算法封裝到具有共同接口的獨立的類中，從而使得它們可以相互替換。策略模式使得算法可以在不影響到客戶端的情況下發(fā)生變化。策略模式把行為和環(huán)境分開。環(huán)境類負責維持和查詢行為類，各種算法在具體的策略類中提供。由于算法和環(huán)境獨立開來，算法的增減，修改都不會影響到環(huán)境和客戶端。
１． 角色：環(huán)境角色?---持有一個抽象策略角色的引用
抽象策略角色-----由一個接口或抽象類實現(xiàn)
具體策略角色-----包裝了相關的算法或行為
第36章 模版方法(Template Method)模式
看過《如何說服女生上床》這部經(jīng)典文章嗎？女生從認識到上床的不變的步驟分為巧遇、打破僵局、展開追求、接吻、前戲、動手、愛撫、進去八大步驟(Template method)，但每個步驟針對不同的情況，都有不一樣的做法，這就要看你隨機應變啦(具體實現(xiàn))；
模板方法模式：模板方法模式準備一個抽象類，將部分邏輯以具體方法以及具體構(gòu)造子的形式實現(xiàn)，然后聲明一些抽象方法來迫使子類實現(xiàn)剩余的邏輯。不同的子類可以以不同的方式實現(xiàn)這些抽象方法，從而對剩余的邏輯有不同的實現(xiàn)。先制定一個頂級邏輯框架，而將邏輯的細節(jié)留給具體的子類去實現(xiàn)。
它有兩種角色，如下：（其中抽象模版具備一個模版方法）
第38章 觀察者(Observer)模式
想知道咱們公司最新MM情報嗎？加入公司的MM情報郵件組就行了，tom負責搜集情報，他發(fā)現(xiàn)的新情報不用一個一個通知我們，直接發(fā)布給郵件組，我們作為訂閱者（觀察者）就可以及時收到情報啦
觀察者模式：觀察者模式定義了一種一對多的依賴關系，讓多個觀察者對象同時監(jiān)聽某一個主題對象。這個主題對象在狀態(tài)上發(fā)生變化時，會通知所有觀察者對象，使他們能夠自動更新自己。
1．抽象主題角色：它把所有觀察者對象的引用保存在一個聚集中，每個主題可以有任意多的觀察者。它提供一個接口，可以增加或刪除觀察者對象。
抽象觀察者角色：為所有觀察者定義一個接口，在得到主題的通知時更新自己，提供一個update()方法。
具體主題角色：它保存狀態(tài)信息，當狀態(tài)信息改變時，會給所有登記過的觀察者發(fā)通知。
具體觀察者角色：存儲與主題的狀態(tài)自恰的狀態(tài)，它實現(xiàn)抽象觀察者接口。
第43章 迭代子(Iterator)模式
我愛上了Mary，不顧一切的向她求婚。
Mary：“想要我跟你結(jié)婚，得答應我的條件”
我：“什么條件我都答應，你說吧”
Mary：“我看上了那個一克拉的鉆石”
我：“我買，我買，還有嗎？”
Mary：“我看上了湖邊的那棟別墅”
我：“我買，我買，還有嗎？”
Mary：“我看上那輛法拉利跑車”
我腦袋嗡的一聲，坐在椅子上，一咬牙：“我買，我買，還有嗎？”
……
迭代子模式：迭代子模式可以順序訪問一個聚集中的元素而不必暴露聚集的內(nèi)部表象。多個對象聚在一起形成的總體稱之為聚集，聚集對象是能夠包容一組對象的容器對象。迭代子模式將迭代邏輯封裝到一個獨立的子對象中，從而與聚集本身隔開。迭代子模式簡化了聚集的界面。每一個聚集對象都可以有一個或一個以上的迭代子對象，每一個迭代子的迭代狀態(tài)可以是彼此獨立的。迭代算法可以獨立于聚集角色變化。
***********************************************************
13、CHAIN OF RESPONSIBLEITY?晚上去上英語課，為了好開溜坐到了最后一排，哇，前面坐了好幾個漂亮的MM哎，找張紙條，寫上“Hi,可以做我的女朋友嗎？如果不愿意請向前傳”，紙條就一個接一個的傳上去了，糟糕，傳到第一排的MM把紙條傳給老師了，聽說是個老處女呀，快跑!
責任鏈模式：在責任鏈模式中，很多對象由每一個對象對其下家的引用而接
起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求?？蛻舨⒉恢梨溕系哪囊粋€對象最終處理這個請求，系統(tǒng)可以在不影響客戶端的情況下動態(tài)的重新組織鏈和分配責任。處理者有兩個選擇：承擔責任或者把責任推給下家。一個請求可以最終不被任何接收端對象所接受。
14、COMMAND?俺有一個MM家里管得特別嚴，沒法見面，只好借助于她弟弟在我們倆之間傳送信息，她對我有什么指示，就寫一張紙條讓她弟弟帶給我。這不，她弟弟又傳送過來一個COMMAND，為了感謝他，我請他吃了碗雜醬面，哪知道他說：“我同時給我姐姐三個男朋友送COMMAND，就數(shù)你最小氣，才請我吃面。”，
命令模式：命令模式把一個請求或者操作封裝到一個對象中。命令模式把發(fā)出命令的責任和執(zhí)行命令的責任分割開，委派給不同的對象。命令模式允許請求的一方和發(fā)送的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否執(zhí)行，何時被執(zhí)行以及是怎么被執(zhí)行的。系統(tǒng)支持命令的撤消。
15、INTERPRETER?俺有一個《泡MM真經(jīng)》，上面有各種泡MM的攻略，比如說去吃西餐的步驟、去看電影的方法等等，跟MM約會時，只要做一個Interpreter，照著上面的腳本執(zhí)行就可以了。
解釋器模式：給定一個語言后，解釋器模式可以定義出其文法的一種表示，并同時提供一個解釋器?？蛻舳丝梢允褂眠@個解釋器來解釋這個語言中的句子。解釋器模式將描述怎樣在有了一個簡單的文法后，使用模式設計解釋這些語句。在解釋器模式里面提到的語言是指任何解釋器對象能夠解釋的任何組合。在解釋器模式中需要定義一個代表文法的命令類的等級結(jié)構(gòu)，也就是一系列的組合規(guī)則。每一個命令對象都有一個解釋方法，代表對命令對象的解釋。命令對象的等級結(jié)構(gòu)中的對象的任何排列組合都是一個語言。
17、MEDIATOR?四個MM打麻將，相互之間誰應該給誰多少錢算不清楚了，幸虧當時我在旁邊，按照各自的籌碼數(shù)算錢，賺了錢的從我這里拿，賠了錢的也付給我，一切就OK啦，俺得到了四個MM的電話。
調(diào)停者模式：調(diào)停者模式包裝了一系列對象相互作用的方式，使得這些對象不必相互明顯作用。從而使他們可以松散偶合。當某些對象之間的作用發(fā)生改變時，不會立即影響其他的一些對象之間的作用。保證這些作用可以彼此獨立的變化。調(diào)停者模式將多對多的相互作用轉(zhuǎn)化為一對多的相互作用。調(diào)停者模式將對象的行為和協(xié)作抽象化，把對象在小尺度的行為上與其他對象的相互作用分開處理。
18、MEMENTO?同時跟幾個MM聊天時，一定要記清楚剛才跟MM說了些什么話，不然MM發(fā)現(xiàn)了會不高興的哦，幸虧我有個備忘錄，剛才與哪個MM說了什么話我都拷貝一份放到備忘錄里面保存，這樣可以隨時察看以前的記錄啦。
備忘錄模式：備忘錄對象是一個用來存儲另外一個對象內(nèi)部狀態(tài)的快照的對象。備忘錄模式的用意是在不破壞封裝的條件下，將一個對象的狀態(tài)捉住，并外部化，存儲起來，從而可以在將來合適的時候把這個對象還原到存儲起來的狀態(tài)。
20、STATE?跟MM交往時，一定要注意她的狀態(tài)哦，在不同的狀態(tài)時她的行為會有不同，比如你約她今天晚上去看電影，對你沒興趣的MM就會說“有事情啦”，對你不討厭但還沒喜歡上的MM就會說“好啊，不過可以帶上我同事么？”，已經(jīng)喜歡上你的MM就會說“幾點鐘？看完電影再去泡吧怎么樣？”，當然你看電影過程中表現(xiàn)良好的話，也可以把MM的狀態(tài)從不討厭不喜歡變成喜歡哦。
狀態(tài)模式：狀態(tài)模式允許一個對象在其內(nèi)部狀態(tài)改變的時候改變行為。這個對象看上去象是改變了它的類一樣。狀態(tài)模式把所研究的對象的行為包裝在不同的狀態(tài)對象里，每一個狀態(tài)對象都屬于一個抽象狀態(tài)類的一個子類。狀態(tài)模式的意圖是讓一個對象在其內(nèi)部狀態(tài)改變的時候，其行為也隨之改變。狀態(tài)模式需要對每一個系統(tǒng)可能取得的狀態(tài)創(chuàng)立一個狀態(tài)類的子類。當系統(tǒng)的狀態(tài)變化時，系統(tǒng)便改變所選的子類。
23、VISITOR?情人節(jié)到了，要給每個MM送一束鮮花和一張卡片，可是每個MM送的花都要針對她個人的特點，每張卡片也要根據(jù)個人的特點來挑，我一個人哪搞得清楚，還是找花店老板和禮品店老板做一下Visitor，讓花店老板根據(jù)MM的特點選一束花，讓禮品店老板也根據(jù)每個人特點選一張卡，這樣就輕松多了；
訪問者模式：訪問者模式的目的是封裝一些施加于某種數(shù)據(jù)結(jié)構(gòu)元素之上的操作。一旦這些操作需要修改的話，接受這個操作的數(shù)據(jù)結(jié)構(gòu)可以保持不變。訪問者模式適用于數(shù)據(jù)結(jié)構(gòu)相對未定的系統(tǒng)，它把數(shù)據(jù)結(jié)構(gòu)和作用于結(jié)構(gòu)上的操作之間的耦合解脫開，使得操作集合可以相對自由的演化。訪問者模式使得增加新的操作變的很容易，就是增加一個新的訪問者類。訪問者模式將有關的行為集中到一個訪問者對象中，而不是分散到一個個的節(jié)點類中。當使用訪問者模式時，要將盡可能多的對象瀏覽邏輯放在訪問者類中，而不是放到它的子類中。訪問者模式可以跨過幾個類的等級結(jié)構(gòu)訪問屬于不同的等級結(jié)構(gòu)的成員類。 |
|
