2010-04-14
文章分類(lèi):Java編程 1、模式（Pattern）定義
策略（Strategy）模式：定義一組算法族，分別封裝起來(lái)，讓各個(gè)算法之間可以相互替換。此模式讓算法的變化獨(dú)立于使用算法的客戶。
觀察者模式：定義了對(duì)象之間的一對(duì)多依賴(lài)關(guān)系，當(dāng)一個(gè)對(duì)象（主題對(duì)象）的狀態(tài)改變時(shí)，它的所有依賴(lài)者（觀察者對(duì)象）都會(huì)收到通知并自動(dòng)更新。
裝飾者模式：動(dòng)態(tài)地將責(zé)任加到對(duì)象身上。如果要擴(kuò)展功能，裝飾者模式提供了比繼承更有彈性的替代方案。
*用靜態(tài)方法定義的工廠被成為靜態(tài)工廠，這樣就不用使用創(chuàng)建對(duì)象的方法來(lái)實(shí)例化對(duì)象，使用方便。但是這樣做的缺點(diǎn)是無(wú)法通過(guò)繼承來(lái)改變創(chuàng)建方法的行為。
*簡(jiǎn)單工廠不是一種設(shè)計(jì)模式，但是它比較常用。
*工廠方法用來(lái)處理對(duì)象的創(chuàng)建，并將這樣的行為封裝在子類(lèi)中。這樣，客戶程序中關(guān)于超類(lèi)的代碼就和子類(lèi)對(duì)象的創(chuàng)建代碼解耦（Decouple）了。
工廠方法的定義：abstract Product factoryMethod(String type);
工廠（Factory Method Pattern）方法模式：定義了一個(gè)創(chuàng)建對(duì)象的接口，但是由子類(lèi)來(lái)決定要實(shí)例化的類(lèi)是哪一個(gè)。它讓類(lèi)把實(shí)例化推遲到了子類(lèi)。
抽象工廠模式：提供一個(gè)接口，用于創(chuàng)建相關(guān)或者依賴(lài)對(duì)象的家族，而不需要明確指定具體類(lèi)。
單件（Singleton）模式：確保一個(gè)類(lèi)只有一個(gè)實(shí)例，并提供一個(gè)全局訪問(wèn)點(diǎn)。
命令（Command）模式：將“請(qǐng)求”封裝成對(duì)象，以便使用請(qǐng)求、隊(duì)列或日志來(lái)參數(shù)化其它對(duì)象。命令模式也支持可撤銷(xiāo)的操作。
適配器模式：將一個(gè)類(lèi)的接口，轉(zhuǎn)換成客戶希望的另一個(gè)接口。適配器讓原本接口不兼容的類(lèi)合作無(wú)間。
外觀模式：提供了一個(gè)統(tǒng)一的接口，用來(lái)訪問(wèn)子系統(tǒng)中的一群接口。外觀模式定義了一個(gè)高層接口，讓子系統(tǒng)更容易使用。
迭代器模式：提供一種順序訪問(wèn)集合對(duì)象中各個(gè)元素的方法，而又不暴露其內(nèi)部的表示（也就是數(shù)據(jù)結(jié)構(gòu)）。
組合模式：將對(duì)象組合成樹(shù)狀結(jié)構(gòu)來(lái)表現(xiàn)“整體/部分”的層級(jí)結(jié)構(gòu)，讓客戶以一致的方式來(lái)處理個(gè)別對(duì)象以及對(duì)象組合。
模板方法模式：在一個(gè)方法中定義了一個(gè)算法的骨架，而將一些步驟延遲到子類(lèi)中。模板方法可以讓子類(lèi)在不改變算法結(jié)構(gòu)的情況下，重新定義算法中的某些步驟。
狀態(tài)（State）模式：允許對(duì)象在內(nèi)部狀態(tài)改變時(shí)改變它的行為，對(duì)象看起來(lái)好像修改了它的類(lèi)。
代理模式：為另一個(gè)對(duì)象提供替身或占位符以控制對(duì)這個(gè)對(duì)象的訪問(wèn)。
*復(fù)合模式在一個(gè)解決方案中結(jié)合兩個(gè)或多個(gè)模式，以解決一般或重復(fù)發(fā)生的問(wèn)題。
*視圖（View）：用來(lái)呈現(xiàn)模型。視圖通常直接從模型中取得它需要顯示的數(shù)據(jù)和狀態(tài)。
*控制器（Controller）：取得用戶的輸入并解讀其對(duì)模型的含義。
*模型（Model）：模型持有所有的數(shù)據(jù)、狀態(tài)和程序邏輯。模型沒(méi)有注意到視圖和控制器，雖然它提供了操縱和檢索狀態(tài)的接口，并發(fā)送狀態(tài)改變通知給觀察者。
模式：是在某種情境下（Context），針對(duì)某個(gè)問(wèn)題的某種解決方案。
反模式：告訴你如何采用一個(gè)不好的解決方案解決一個(gè)問(wèn)題。
2、面向?qū)ο笤O(shè)計(jì)原則
封裝變化--把軟件中那些在將來(lái)可能產(chǎn)生變化的地方獨(dú)立出來(lái)，與其他部分分割以減少變化時(shí)對(duì)它們的影響。這樣的設(shè)計(jì)可以使系統(tǒng)變得有彈性，更好地應(yīng)對(duì)變化。
針對(duì)接口編程，而不針對(duì)實(shí)現(xiàn)編程。依據(jù)該原則，聲明一個(gè)變量時(shí)要把它聲明為超類(lèi)型（接口或抽象類(lèi)），而不是實(shí)現(xiàn)類(lèi)。
多用組合，少用繼承。使用組合的方式可以實(shí)現(xiàn)代碼的分割，使代碼有更大的彈性，更好地提高了復(fù)用性。
努力在交互對(duì)象之間實(shí)現(xiàn)松耦合，使它們之間的互相依賴(lài)降到最低，從而提高可復(fù)用性。
類(lèi)應(yīng)該對(duì)擴(kuò)展開(kāi)放，對(duì)修改關(guān)閉。這就是我們常說(shuō)的開(kāi)放-關(guān)閉原則。
要依賴(lài)抽象，不要依賴(lài)具體類(lèi)。這個(gè)原則又被稱(chēng)為“依賴(lài)倒置原則（Dependency Inversion Principle）”。
*遵循依賴(lài)倒置原則的三個(gè)指導(dǎo)方針：
（1）變量不可以持有具體類(lèi)的引用。這可以通過(guò)使用工廠避開(kāi)。
（2）不要讓類(lèi)派生自具體類(lèi)。否則就會(huì)依賴(lài)具體類(lèi)，違反了“針對(duì)接口編程，而不是針對(duì)現(xiàn)實(shí)編程”的軟件設(shè)計(jì)原則。
（3）不要覆蓋基類(lèi)中已實(shí)現(xiàn)的方法。出現(xiàn)這樣的情況就說(shuō)明基類(lèi)設(shè)計(jì)的有問(wèn)題。
要減少對(duì)象之間的交互，只留下幾個(gè)“密友”。這個(gè)原則被稱(chēng)為“最少知識(shí)（Least Knowledge）原則”，它告訴我們只和自己的密友談話。
*通過(guò)只調(diào)用以下幾種范圍內(nèi)的方法可以做到盡量遵循“最少知識(shí)原則”：
（1）該對(duì)象本身
（2）被當(dāng)做方法的參數(shù)而傳遞進(jìn)來(lái)的對(duì)象
（3）此方法所創(chuàng)建或?qū)嵗娜魏螌?duì)象
（4）對(duì)象的任何組件，比如類(lèi)或?qū)ο蟊旧淼淖兞浚虺Ａ?
*最少知識(shí)原則的不同名稱(chēng)：(Principal of) Least Knowledge，(The) Law of Demeter，迪米特法則，得墨忒耳法則
一個(gè)類(lèi)應(yīng)該只有一個(gè)引起變化的原因。
別調(diào)用（打電話給）我們，我們會(huì)調(diào)用（打電話給）你。這個(gè)原則被成為好萊塢原則。
3、模式使用事項(xiàng)
*裝飾者模式的幾個(gè)缺點(diǎn)：
（1）有時(shí)在設(shè)計(jì)中加入大量的小類(lèi)，變得不容易理解。
（2）有的客戶端代碼依賴(lài)于特定的類(lèi)型（這是個(gè)比較糟糕的習(xí)慣，違反了“針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程”的設(shè)計(jì)原則），當(dāng)服務(wù)器端引入裝飾者模式時(shí)，客戶端就會(huì)出現(xiàn)狀況。
（3）裝飾者模式使得實(shí)例化組件的復(fù)雜度提升。
PS：工廠（Factory）模式和生成器（Builder）模式對(duì)于裝飾者（Decorator）模式的這些缺點(diǎn)會(huì)有所幫助。
*空對(duì)象（null object）可以用于返回?zé)o意義的對(duì)象時(shí)，它可以承擔(dān)處理null的責(zé)任。有時(shí)候空對(duì)象也被視為一種設(shè)計(jì)模式。
*宏命令（Macro Command）是一個(gè)命令隊(duì)列，它包含了一組實(shí)現(xiàn)了同一個(gè)命令接口的類(lèi)。
*在調(diào)用者中用一個(gè)堆棧記錄連續(xù)執(zhí)行的命令，這樣就可以實(shí)現(xiàn)每按一次按鈕就執(zhí)行一次撤銷(xiāo)操作的連續(xù)撤銷(xiāo)功能。
*適配器（Adapter）類(lèi)看起來(lái)很像命令（Command）模式中命令接口的實(shí)現(xiàn)類(lèi)，只不過(guò)它不被作為參數(shù)傳遞。
*類(lèi)適配器是基于多重繼承實(shí)現(xiàn)的，因?yàn)镴ava不支持多重繼承，因此無(wú)法做到。
*裝飾者（Decorator）模式與適配器（Adapter）模式的區(qū)別
（1）裝飾者模式與“責(zé)任”相關(guān)，當(dāng)涉及到裝飾者時(shí)，就表示有一些新的行為或責(zé)任要加到設(shè)計(jì)中。
（2）適配器允許客戶使用新的庫(kù)和子集合，無(wú)須改變“任何”已存在的代碼，由適配器負(fù)責(zé)轉(zhuǎn)換即可。
（3）裝飾者不會(huì)改變接口，而適配器會(huì)改變接口。
（4）裝飾者的工作是擴(kuò)展被包裝對(duì)象的行為或責(zé)任，并不是“簡(jiǎn)單傳遞”就算了。
（5）裝飾者（Decorator）模式與適配器（Adapter）模式的最大不同在于使用它們的意圖（或目的）。
*使用最少知識(shí)原則的缺點(diǎn)是：更多的“包裝類(lèi)”被創(chuàng)造出來(lái)，以處理和其它組件的溝通。這可能導(dǎo)致復(fù)雜度和開(kāi)發(fā)時(shí)間的增加，并減低運(yùn)行時(shí)的性能。
*組合（Composite）模式犧牲了單一責(zé)任設(shè)計(jì)原則，換取了透明性（Transprency）。
*空迭代器（Iterator）是空對(duì)象（null object）“設(shè)計(jì)模式”的又一個(gè)例子，之前的例子是“空命令（NullCommand）”。
*為了保證模板方法定義的算法步驟不被改變，模板方法被聲明為final的。
*鉤子（hook）就是回調(diào)函數(shù)，它可以作為條件影響模板方法類(lèi)中算法的流程。
代理模式有很多變種，幾乎都與控制訪問(wèn)有關(guān)，它控制訪問(wèn)的幾種方式：
一、遠(yuǎn)程代理控制遠(yuǎn)程對(duì)象的訪問(wèn)。
二、虛擬代理控制創(chuàng)建開(kāi)銷(xiāo)大的資源的訪問(wèn)。
三、保護(hù)代理基于權(quán)限控制對(duì)資源的訪問(wèn)。
*不把控制器的代碼（解讀視圖的輸入并操縱模型）放到模型中的原因有兩個(gè)：
一、會(huì)讓模型的代碼更復(fù)雜。模型將具有兩個(gè)責(zé)任，不但要管理用戶界面，還要處理如何控制模型的邏輯。
二、會(huì)造成模型和視圖之間的緊耦合，降低了可復(fù)用性。通過(guò)模型和視圖之間的解耦，使設(shè)計(jì)更有彈性和容易擴(kuò)展，能容納改變。
4、其他重要知識(shí)
*面向?qū)ο螅∣O）的四個(gè)基本概念是：抽象、封裝、繼承、多態(tài)。
*繼承的好處是實(shí)現(xiàn)了代碼的復(fù)用。
*良好的OO設(shè)計(jì)必須具備可復(fù)用、可擴(kuò)展、可維護(hù)三個(gè)特性。
*引起代碼修改的幾種情況：
1）客戶要求不同的做法或新功能。
2）數(shù)據(jù)庫(kù)產(chǎn)品發(fā)生改變導(dǎo)致數(shù)據(jù)格式不兼容。
3）協(xié)議有了新版本。
4）開(kāi)發(fā)人員水平有了提升，重新實(shí)現(xiàn)。
*觀察者模式實(shí)現(xiàn)了主題對(duì)象與觀察者對(duì)象之間的松耦合，當(dāng)有新的觀察者時(shí)，無(wú)需修改主題對(duì)象的代碼，只需要新的觀察者對(duì)象實(shí)現(xiàn)接口。在程序運(yùn)行的過(guò)程中，可以隨時(shí)注冊(cè)和刪除觀察者而不影響主題對(duì)象。
*Java內(nèi)置了對(duì)觀察者模式的支持：java.util.Observable類(lèi)和java.util.Observer接口。
*java.util.Observable類(lèi)的局限：
一、它是一個(gè)類(lèi)，而不是接口，由于Java不支持多重繼承，所以主題類(lèi)無(wú)法同時(shí)擁有它和另一個(gè)超類(lèi)的行為，這限制了Observable類(lèi)的復(fù)用潛力。違反了“針對(duì)接口編程，而不是針對(duì)實(shí)現(xiàn)編程”的軟件設(shè)計(jì)原則。
二、它的某些如setChanged()這樣的方法被定義為protected，要使用它們就必須繼承Observable類(lèi)，這違反了“多用組合，少用繼承”的軟件設(shè)計(jì)原則。
如果上面兩條限制妨礙了你的使用，就應(yīng)該考慮自己設(shè)計(jì)實(shí)現(xiàn)觀察者模式。
*在觀察者模式中，傳遞數(shù)據(jù)的方式有“推”和“拉”兩種，Java內(nèi)置的實(shí)現(xiàn)支持這兩種方式，然而較常用的為“推”數(shù)據(jù)。
*觀察者模式以松耦合的方式在對(duì)象之間傳遞狀態(tài)，MVC是其代表。
*利用組合（composition）和委托（delegation）可以在運(yùn)行時(shí)實(shí)現(xiàn)繼承行為的效果，動(dòng)態(tài)地給對(duì)象加上新的行為。
*利用繼承擴(kuò)展子類(lèi)的行為，是在編譯時(shí)靜態(tài)決定的；利用組合的做法，可以在運(yùn)行時(shí)動(dòng)態(tài)地?cái)U(kuò)展對(duì)象的行為。
*裝飾者模式中，裝飾者可以在被裝飾者的行為之前或之后，加上自己的行為，以實(shí)現(xiàn)特性的目的。
*針對(duì)接口編程可以隔離掉系統(tǒng)以后可能發(fā)生的一大堆改變。
*所有工廠模式都用來(lái)封裝對(duì)象的創(chuàng)建。
*工廠方法模式（Factory Method Pattern）通過(guò)讓子類(lèi)來(lái)決定該創(chuàng)建的對(duì)象是什么，來(lái)達(dá)到將對(duì)象的創(chuàng)建過(guò)程封裝的目的。
*在工廠方法模式中包括創(chuàng)建者（Creator）類(lèi)和產(chǎn)品（Product）類(lèi)兩種類(lèi)型的類(lèi)。
*工廠方法模式可以和策略（Strategy）模式結(jié)合起來(lái)，在運(yùn)行時(shí)動(dòng)態(tài)地更換工廠類(lèi)，從而創(chuàng)建不同的產(chǎn)品對(duì)象，這是簡(jiǎn)單工廠所不具有的彈性。
*依賴(lài)倒置原則說(shuō)明不能讓高層組件依賴(lài)于底層組件，而是它們都應(yīng)該依賴(lài)于抽象。
*抽象工廠模式是工廠方法模式的演變。工廠方法模式中，創(chuàng)建者只生產(chǎn)一種類(lèi)型的產(chǎn)品，而抽象工廠模式中，創(chuàng)建者生產(chǎn)一組不同類(lèi)型的產(chǎn)品。
*所有工廠模式都通過(guò)減少應(yīng)用程序和具體類(lèi)之間的依賴(lài)來(lái)促進(jìn)松耦合，即解耦（Decouple）。
*有些對(duì)象我們只需要一個(gè)，比如說(shuō)：線程池（threadpool）、緩存（cache）、對(duì)話框（Dialog）、處理偏好設(shè)置的對(duì)象、處理注冊(cè)表（register）的對(duì)象、日志對(duì)象，以及充當(dāng)打印機(jī)、顯卡等設(shè)備的驅(qū)動(dòng)程序?qū)ο?。這些對(duì)象只能有一個(gè)實(shí)例，如果出現(xiàn)多個(gè)實(shí)例就會(huì)導(dǎo)致程序的行為異常、資源使用過(guò)量，或者產(chǎn)生的結(jié)果不一致等等問(wèn)題。
*單件模式與全局靜態(tài)變量的區(qū)別：
（1）使用全局靜態(tài)變量需要程序員之間的約定才能保證只有一個(gè)實(shí)例，而單件模式無(wú)需這樣的約定就可以確保只有一個(gè)實(shí)例被創(chuàng)建。
（2）靜態(tài)變量在程序一開(kāi)始就被創(chuàng)建（這取決于JVM的實(shí)現(xiàn)），而單件模式只是在使用時(shí)才創(chuàng)建對(duì)象。如果這個(gè)被創(chuàng)建的對(duì)象非常消耗資源，而在程序運(yùn)行的過(guò)程中沒(méi)有用到它，就會(huì)造成很大的浪費(fèi)，這是靜態(tài)變量的缺點(diǎn)。
*在單態(tài)模式中，如果不需要這個(gè)實(shí)例，它就永遠(yuǎn)不會(huì)被創(chuàng)建。這就是“延遲實(shí)例化（Lazy Instance）”。
*單件常用來(lái)管理共享的資源，比如數(shù)據(jù)庫(kù)連接池或線程池。
*多線程會(huì)影響到單件模式，如果不對(duì)它進(jìn)行處理就會(huì)在單件模式下仍然創(chuàng)建多于一個(gè)實(shí)例。
在這個(gè)方法里使用到了volatile這個(gè)關(guān)鍵字，下面對(duì)這個(gè)“關(guān)鍵的”關(guān)鍵字進(jìn)行說(shuō)明：
Java語(yǔ)言規(guī)范指出，為了獲得最佳速度，允許線程保存共享成員變量的私有拷貝，而且只當(dāng)線程進(jìn)入和離開(kāi)同步代碼塊時(shí)才與共享成員變量的原始值進(jìn)行對(duì)比。
而被volatile修飾的成員變量在線程中的私有拷貝每次被線程訪問(wèn)時(shí)，都強(qiáng)迫從共享內(nèi)存中重讀該成員變量的值。而且，當(dāng)成員變量的私有拷貝發(fā)生變化時(shí)，強(qiáng)迫線程將變化值回寫(xiě)到共享內(nèi)存。這樣在任何時(shí)刻，兩個(gè)不同的線程總是看到某個(gè)成員變量的同一個(gè)值。
因此volatile關(guān)鍵字是使“雙重檢查加鎖（Double-Checked Locking）”有效的前提。
但是需要注意，在1.4及以前版本的JDK中，JVM對(duì)volatile關(guān)鍵字的實(shí)現(xiàn)會(huì)導(dǎo)致雙重檢查加鎖失效，所以這個(gè)方法只適用于1.5（包含）以后版本。
*可以通過(guò)把一個(gè)類(lèi)中的全部方法都定義為靜態(tài)方法的方式來(lái)達(dá)到和單件模式同樣的效果，但是由于類(lèi)的初始化順序由JVM控制，所以可能導(dǎo)致與初始化順序有關(guān)的BUG，而這樣的BUG常常難于被發(fā)現(xiàn)。當(dāng)類(lèi)的初始化比較簡(jiǎn)單時(shí)，可以使用此方法。
*類(lèi)加載器會(huì)破壞單件模式，因?yàn)椴煌念?lèi)加載器可以分別創(chuàng)建同一個(gè)單件的對(duì)象，單件對(duì)象就有了多個(gè)實(shí)例。解決辦法是：自行指定類(lèi)加載器，并且指定同一個(gè)類(lèi)加載器。
*在Java 1.2及以前版本中，垃圾收集器有一個(gè)BUG，會(huì)造成單件在沒(méi)有全局引用時(shí)，被當(dāng)做垃圾清理掉。在1.2以后的版本中，這個(gè)BUG已經(jīng)得到了修復(fù)，因此不用擔(dān)心了。
如果使用的是1.2及以前的版本，可以建立一個(gè)單件注冊(cè)表（Register），從而避免單件被垃圾收集器回收。
*命令（Command）模式通過(guò)把接受者當(dāng)作參數(shù)來(lái)傳遞，并且讓所有的命令對(duì)象都實(shí)現(xiàn)一個(gè)命令接口的方式，實(shí)現(xiàn)了針對(duì)接口編程，從而在調(diào)用者和接受者之間實(shí)現(xiàn)了解耦。
*適配器（Adapter）模式充滿著良好的OO設(shè)計(jì)原則：使用對(duì)象組合，以修改的接口包裝被適配者；這種做法還有額外的優(yōu)點(diǎn)，那就是被適配者的任何子類(lèi)都可以搭配著適配器使用。
*外觀模式在簡(jiǎn)化接口的同時(shí)，依然將系統(tǒng)完整的功能暴露出來(lái)，一共需要的人使用。
*外觀模式不僅簡(jiǎn)化了接口，也將客戶從組件的子系統(tǒng)中解耦。
*適配器（Adapter）模式和外觀（Facade）模式都可以包裝多個(gè)類(lèi)，前者的目的是將接口重新組織后提供新接口，后者的目的是簡(jiǎn)化接口。由于它們的差異很細(xì)微，所以兩者常常同時(shí)出現(xiàn)。
*適配器（Adapter）將一個(gè)對(duì)象包裝起來(lái)以改變其接口；裝飾者（Decorator）將一個(gè)對(duì)象包裝起來(lái)以增加新的行為和責(zé)任；而外觀（Facade）將一群對(duì)象包裝起來(lái)以簡(jiǎn)化其接口。
*當(dāng)我們說(shuō)“集合（Collection）”的時(shí)候，我們指的是一群對(duì)象。其存儲(chǔ)方式可以是各式各樣的數(shù)據(jù)結(jié)構(gòu)，例如：列表、數(shù)組、散列表，無(wú)論用什么方式存儲(chǔ)，一律可以視為集合。有時(shí)候也被稱(chēng)為聚合（aggregate）。
*迭代器（Iterator）模式把元素之間游走的任務(wù)交給了迭代器，而不是聚合對(duì)象。這不僅讓聚合的接口和實(shí)現(xiàn)變得更簡(jiǎn)潔，也讓它專(zhuān)注于管理對(duì)象，而不必理會(huì)遍歷的事情。
*類(lèi)的每個(gè)責(zé)任都有一個(gè)潛在的改變區(qū)域，多一個(gè)責(zé)任就意味著多一個(gè)改變的區(qū)域。要盡量讓每個(gè)類(lèi)保持單一責(zé)任。
*既要讓每個(gè)類(lèi)都保持單一的責(zé)任，也要保證一個(gè)責(zé)任只指派給一個(gè)類(lèi)。
*內(nèi)聚（Cohesion）用來(lái)度量一個(gè)類(lèi)或模塊緊密地達(dá)到單一目的或責(zé)任的程度。
*當(dāng)一個(gè)類(lèi)或模塊被設(shè)計(jì)成只支持一組相關(guān)功能時(shí)，我們說(shuō)它具有高內(nèi)聚；反之，當(dāng)被設(shè)計(jì)成支持一組不相關(guān)的功能時(shí)，我們說(shuō)它具有低內(nèi)聚。
*“空對(duì)象設(shè)計(jì)模式”帶來(lái)的好處是客戶不用處理null，因此不必?fù)?dān)心系統(tǒng)會(huì)跑出NullPointerException。
*當(dāng)多個(gè)對(duì)象彼此之間有“整體/部分”的關(guān)系，并且你想用一致的方式處理這些對(duì)象時(shí)（就是讓它們看起來(lái)一樣，有共同的方法可以調(diào)用），就需要用組合（Composite）模式。
*在組合中加入緩存可以提高遍歷的性能。
*模板方法定義了一個(gè)算法的步驟，并允許子類(lèi)為一個(gè)或多個(gè)步驟提供實(shí)現(xiàn)。
*好萊塢原則可以盡量減少類(lèi)之間的過(guò)分依賴(lài)，防止“依賴(lài)腐.敗”。
*策略（Strategy）模式與模板方法（Template Method）模式的區(qū)別：策略模式實(shí)現(xiàn)了完整的算法，各個(gè)算法之間可以互相替換；而模板方法只定義了算法的骨架，其中一部分步驟需要子類(lèi)來(lái)實(shí)現(xiàn)。
*使用狀態(tài)模式通常會(huì)導(dǎo)致設(shè)計(jì)中類(lèi)的數(shù)目大量增加。
*狀態(tài)可以被多個(gè)Context實(shí)例共享。
*遠(yuǎn)程代理（Remote Proxy）模式：可以作為另一個(gè)JVM上對(duì)象的本地代表。調(diào)用代理的方法會(huì)被代理利用網(wǎng)絡(luò)轉(zhuǎn)發(fā)到遠(yuǎn)程執(zhí)行，并且結(jié)果會(huì)通過(guò)網(wǎng)絡(luò)返回給代理，再由代理將結(jié)果轉(zhuǎn)給客戶。
*虛擬代理（Virtual Proxy）模式：作為創(chuàng)建開(kāi)銷(xiāo)大的對(duì)象的代表。虛擬代理經(jīng)常在我們真正需要一個(gè)對(duì)象的時(shí)候才創(chuàng)建它。當(dāng)對(duì)象在創(chuàng)建前和創(chuàng)建中時(shí)，由代理來(lái)扮演它的替身。對(duì)象創(chuàng)建后，代理就會(huì)將請(qǐng)求直接委托給對(duì)象。
*動(dòng)態(tài)代理：Java在java.lang.reflect包中有自己的代理支持。利用這個(gè)包你可以在運(yùn)行時(shí)動(dòng)態(tài)地創(chuàng)建代理類(lèi)，實(shí)現(xiàn)一個(gè)或多個(gè)接口，并將方法的調(diào)用轉(zhuǎn)發(fā)到你所指定的類(lèi)。因?yàn)閷?shí)際的代理類(lèi)是在運(yùn)行時(shí)創(chuàng)建的，因此稱(chēng)這項(xiàng)Java技術(shù)為動(dòng)態(tài)代理。
其他種類(lèi)的代理：
一、防火墻代理（Firewall Proxy）：控制網(wǎng)絡(luò)資源的訪問(wèn)，保護(hù)資源免受“壞客戶”的侵害。
二、智能引用代理（Smart Reference Proxy）：當(dāng)主題被引用時(shí)，進(jìn)行額外的動(dòng)作，例如計(jì)算一個(gè)對(duì)象被引用的次數(shù)。
三、緩存代理（Caching Proxy）：為開(kāi)銷(xiāo)大的計(jì)算結(jié)果提供暫時(shí)存儲(chǔ)。它允許多個(gè)客戶共享結(jié)果以減少計(jì)算或網(wǎng)絡(luò)延遲。
四、同步代理（Synchronization Proxy）：在多線程的情況下為主題提供安全的訪問(wèn)。
五、復(fù)雜隱藏代理（Complexity Hiding Proxy）：用來(lái)隱藏一個(gè)類(lèi)的復(fù)雜集合的復(fù)雜度，并進(jìn)行訪問(wèn)控制。有時(shí)候也成為外觀代理（Facade Proxy）。復(fù)雜隱藏代理和外觀模式是不一樣的，因?yàn)榇砜刂圃L問(wèn)，而外觀模式只提供另一組接口。
六、寫(xiě)入時(shí)復(fù)制代理（Copy-On-Write Proxy）：用來(lái)控制對(duì)象的復(fù)制，方法是延遲對(duì)象的復(fù)制，直到客戶真的需要為止，這是虛擬代理的變體。
模式的分類(lèi)：
創(chuàng)建型：工廠方法（Factory Method）、抽象工廠（Abstract Factory）、單態(tài)/單件（Singleton）。
行為型：狀態(tài)（State）、策略（Strategy）、觀察者（Observer）、模板方法（Template Method）、命令（Command）、迭代器（Iterator）。
結(jié)構(gòu)型：裝飾者（Decorator）、外觀（Facade）、代理（Proxy）、適配器（Adapter）、組合（Composite）。
*設(shè)計(jì)的原則是用最簡(jiǎn)單的方式解決問(wèn)題，而不是一定要用設(shè)計(jì)模式。
共享詞匯的五種方式：
一、在設(shè)計(jì)會(huì)議中?？梢员忝嫦萑雽?shí)現(xiàn)的細(xì)節(jié)和引起誤解。
二、和其他開(kāi)發(fā)人員。分享知識(shí)。
三、在架構(gòu)文檔中?？梢钥s減文檔的篇幅，并使閱讀者更清晰地理解設(shè)計(jì)。
四、在代碼注釋及命名習(xí)慣上。提高代碼的可讀性。
五、將志同道合的開(kāi)發(fā)人員集合在一起。
*為實(shí)際的擴(kuò)展使用模式，不要為了假想的需要而使用模式。
*簡(jiǎn)單才是王道。最好的設(shè)計(jì)是不使用設(shè)計(jì)模式就能設(shè)計(jì)出最簡(jiǎn)單的方案。
*模式是工具而不是規(guī)則，需要被簡(jiǎn)單地調(diào)整以符合你的需要。
*像模式一樣，有許多類(lèi)型的反模式。包括開(kāi)發(fā)反模式，OO反模式，組織反模式和領(lǐng)域特定反模式。
*反模式告訴你為何這個(gè)解決方案從長(zhǎng)遠(yuǎn)來(lái)看會(huì)造成不好的影響。
5、其他模式及其優(yōu)缺點(diǎn)。
請(qǐng)見(jiàn)附錄部分筆記。
