|
Android開發(fā)中使用到的一些設(shè)計(jì)者模式- http://blog.csdn.net/xiangzhihong8/article/details/28593827 引用： http://m.blog.csdn.net/blog/index?username=qq_17766199 http://blog.csdn.NET/stefzeus/article/details/7503749 書籍：何紅輝《android源碼設(shè)計(jì)模式解析與實(shí)戰(zhàn)》 引用：http://blog.csdn.net/column/details/mode.html?&page=2 >>> 1.單例模式單例模式應(yīng)該是日常使用最為廣泛的一種模式了,。他的作用是確保某個(gè)類只有一個(gè)實(shí)例，避免產(chǎn)生多個(gè)對(duì)象消耗過(guò)多的資源,。比如對(duì)數(shù)據(jù)庫(kù)的操作時(shí),，就可以使用單例模式。 Android源碼中的單例模式運(yùn)用:在Android系統(tǒng)中,，我們經(jīng)常會(huì)通過(guò)Context獲取系統(tǒng)級(jí)別的服務(wù),，如WindowsManagerService、ActivityManagerService等,，更常用的是一個(gè)LayoutInflater的類,，這些服務(wù)會(huì)在合適的時(shí)候以單例的形式注冊(cè)在系統(tǒng)中，在我們需要的時(shí)候就通過(guò)Context的getSystemService(String name)獲取,。 總結(jié): 優(yōu)點(diǎn)： （1）由于單例模式在內(nèi)存中只有一個(gè)實(shí)例,，減少了內(nèi)存開支，特別是一個(gè)對(duì)象需要頻繁的創(chuàng)建,、銷毀時(shí),，而且創(chuàng)建或銷毀時(shí)性能又無(wú)法優(yōu)化，單例模式的優(yōu)勢(shì)就非常明顯,。 （2）單例模式可以避免對(duì)資源的多重占用,，例如一個(gè)文件操作，由于只有一個(gè)實(shí)例存在內(nèi)存中,，避免對(duì)同一資源文件的同時(shí)操作,。 （3）單例模式可以在系統(tǒng)設(shè)置全局的訪問(wèn)點(diǎn)，優(yōu)化和共享資源訪問(wèn),，例如,，可以設(shè)計(jì)一個(gè)單例類，負(fù)責(zé)所有數(shù)據(jù)表的映射處理,。 缺點(diǎn)： （1）單例模式一般沒有接口,，擴(kuò)展很困難,，若要擴(kuò)展，只能修改代碼來(lái)實(shí)現(xiàn),。 （2）單例對(duì)象如果持有Context,，那么很容易引發(fā)內(nèi)存泄露。此時(shí)需要注意傳遞給單例對(duì)象的Context最好是Application Context,。
Android開發(fā)中單例模式寫法與可能遇到的坑- http://blog.csdn.net/chenkai19920410/article/details/54612505 1.定義 將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離,，使得同樣的構(gòu)建過(guò)程可以創(chuàng)建不同的表示。 2.使用場(chǎng)景 （1）相同的方法,，不同的執(zhí)行順序,，產(chǎn)生不同的事件結(jié)果時(shí)。 （2）多個(gè)部件或零件,，都可以裝配到一個(gè)對(duì)象中，但是產(chǎn)生的運(yùn)行結(jié)果又不相同時(shí),。 （3）產(chǎn)品類非常復(fù)雜,，或者產(chǎn)品類中的調(diào)用順序不同產(chǎn)生了不同的作用，這個(gè)使用建造者模式非常適合,。 （4）當(dāng)初始化一個(gè)對(duì)象特別復(fù)雜時(shí),，如參數(shù)多，且很多參數(shù)有默認(rèn)值,。 Android源碼中的Builder模式運(yùn)用：AlertDialog.Builder 總結(jié)： 優(yōu)點(diǎn)： （1）良好的封裝性,，使用建造者模式可以使客戶端不必知道產(chǎn)品內(nèi)部組成細(xì)節(jié)。 （2）建造者獨(dú)立,，容易擴(kuò)展,。 缺點(diǎn)： （1）會(huì)產(chǎn)生多余的Builder對(duì)象及Director對(duì)象，消耗內(nèi)存,。 >> 3. 原型模式 1,、定義 用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并通過(guò)拷貝這些原型創(chuàng)建新的對(duì)象,。被復(fù)制的實(shí)例就是“原型”,，這個(gè)原型是可定制的。 2,、使用場(chǎng)景 （1）類初始化需要消化非常多的資源,，這個(gè)資源包括數(shù)據(jù)、硬件資源等,，通過(guò)原型拷貝避免這些消耗,。 （2）通過(guò)new產(chǎn)生的一個(gè)對(duì)象需要非常繁瑣的數(shù)據(jù)準(zhǔn)備或者權(quán)限，這時(shí)可以使用原型模式,。 （3）一個(gè)對(duì)象需要提供給其他對(duì)象訪問(wèn),，而且各個(gè)調(diào)用者可能都需要修改其值時(shí),，可以考慮使用原型模式拷貝多個(gè)對(duì)象供調(diào)用者使用，即保護(hù)性拷貝,。 Android源碼中的原型模式：Intent 總結(jié)： 優(yōu)點(diǎn) （1）原型模式是在內(nèi)存中二進(jìn)制流的拷貝,，要比直接new一個(gè)對(duì)象性能好很多，特別是要在一個(gè)循環(huán)體內(nèi)產(chǎn)生大量對(duì)象時(shí),，原型模式可能更好的體現(xiàn)其優(yōu)點(diǎn),。（2）還有一個(gè)重要的用途就是保護(hù)性拷貝，也就是對(duì)某個(gè)對(duì)象對(duì)外可能是只讀的,，為了防止外部對(duì)這個(gè)只讀對(duì)象的修改,，通常可以通過(guò)返回一個(gè)對(duì)象拷貝的形式實(shí)現(xiàn)只讀的限制,。 缺點(diǎn)： （1）這既是它的優(yōu)點(diǎn)也是缺點(diǎn),，直接在內(nèi)存中拷貝，構(gòu)造函數(shù)是不會(huì)執(zhí)行的,，在實(shí)際開發(fā)中應(yīng)該注意這個(gè)潛在問(wèn)題,。優(yōu)點(diǎn)是減少了約束，缺點(diǎn)也是減少了約束,，需要大家在實(shí)際應(yīng)用時(shí)考慮,。 （2）通過(guò)實(shí)現(xiàn)Cloneable接口的原型模式在調(diào)用clone函數(shù)構(gòu)造實(shí)例時(shí)并不一定比通過(guò)new操作速度快，只有當(dāng)通過(guò)new構(gòu)造對(duì)象較為耗時(shí)或者說(shuō)成本較高時(shí),，通過(guò)clone方法才能夠獲得效率上的提升,。 >> 4.工廠方法模式 1.定義 定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定實(shí)例化那個(gè)類,。 2.使用場(chǎng)景 在任何需生成復(fù)雜對(duì)象的地方,，都可以使用工廠方法模式。復(fù)雜對(duì)象適合使用工廠模式,，用new就可以完成創(chuàng)建的對(duì)象無(wú)需使用工廠模式,。 Android源碼中的工廠方法模式：1.Activity的各種生命周期；2.ArrayList和HashSet 總結(jié) 優(yōu)點(diǎn)： 1.工廠方法模式完全符合設(shè)計(jì)原則,，降低了對(duì)象之間的耦合,。高層模塊只需要知道產(chǎn)品的抽象類，其他的實(shí)現(xiàn)都不需要關(guān)心,。 2.良好的封裝性,，代碼結(jié)構(gòu)清晰。擴(kuò)展性好,。 缺點(diǎn)： 每次我們?yōu)楣S方法模式添加新的產(chǎn)品時(shí)就要編寫一個(gè)新的產(chǎn)品類,。同時(shí)還要引入抽象層，這必然會(huì)導(dǎo)致類結(jié)構(gòu)的復(fù)雜化,，所以,，在某些情況比較簡(jiǎn)單時(shí),，是否要使用工廠模式，需要設(shè)計(jì)者權(quán)衡利弊了,。 >> 5. 抽象工廠模式 簡(jiǎn)單運(yùn)用：以車廠生產(chǎn)汽車零部件為例,A,、B兩家車廠分別生產(chǎn)不同的輪胎、發(fā)動(dòng)機(jī),、制動(dòng)系統(tǒng),。雖然生產(chǎn)的零件不同，型號(hào)不同,。但是根本上都有共同的約束,，就是輪胎、發(fā)動(dòng)機(jī),、制動(dòng)系統(tǒng),。 1.定義 為創(chuàng)建一組相關(guān)或者是相互依賴的對(duì)象提供一個(gè)接口，而不需要指定他們的具體實(shí)現(xiàn)類,。 2.使用場(chǎng)景 一個(gè)對(duì)象族（或是一組沒有任何關(guān)系的對(duì)象）都有相同的約束,，則可以使用抽象工廠模式。例如一個(gè)文本編輯器和一個(gè)圖片處理器,，都是軟件實(shí)體,，但是Linix下的文本編輯器和WINDOWS下的文本編輯器雖然功能和界面都相同,，但是代碼實(shí)現(xiàn)是不同的,，圖片處理器也是類似情況，也就是具有了共同的約束條件：操作系統(tǒng)類型,，于是我們可以使用抽象工廠模式,，產(chǎn)生不同操作系統(tǒng)下的編輯器和圖片處理器。 Android源碼中的實(shí)現(xiàn)： 抽象工廠模式在Android源碼中使用較少,，因?yàn)楹苌贂?huì)出現(xiàn)多個(gè)產(chǎn)品種類的情況,，大部分使用工廠方法模式即可解決。 1.MediaPlayer： MediaPlayer Factory分別會(huì)生成4個(gè)不同的MediaPlayer基類：StagefrightPlayer,、NuPlayerDriver,、MidiFile和TestPlayerStub，四者均繼承于MediaPlayerBase,。 總結(jié) 優(yōu)點(diǎn)： 分離接口與實(shí)現(xiàn),，客戶端使用抽象工廠來(lái)創(chuàng)建需要的對(duì)象，而客戶端根本就不知道具體的實(shí)現(xiàn)是誰(shuí),，客戶端只是面向產(chǎn)品的接口編程而已,，使其從具體的產(chǎn)品實(shí)現(xiàn)中解耦，同時(shí)基于接口與實(shí)現(xiàn)分離,，使抽象該工廠方法模式在切換產(chǎn)品類時(shí)更加靈活,、容易,。 缺點(diǎn)： 一是對(duì)類文件的爆炸性增加，二是不太容易擴(kuò)展新的產(chǎn)品類,。 >> 6. 策略模式 通常如果一個(gè)問(wèn)題有多個(gè)解決方案時(shí),，最簡(jiǎn)單的就是利用if-else或者switch-case方式根據(jù)不同的情景選擇不同的解決方案，但是這樣耦合性太高 ,、代碼臃腫,、難以維護(hù)等。這時(shí)就可以使用策略模式來(lái)解決,。 1.定義 策略模式定義了一系列的算法,，并將每一個(gè)算法封裝起來(lái)，而且使他們還可以相互替換,。策略模式讓算法獨(dú)立于使用它的客戶而獨(dú)立變化,。 2.使用場(chǎng)景 1.針對(duì)同一類型問(wèn)題的多種處理方式，僅僅是具體行為有差別時(shí),。 2.需要安全地封裝多種同一類型的操作時(shí),。 3.出現(xiàn)同一抽象類有多個(gè)子類，而又需要使用if-else或者switch-case來(lái)選擇具體子類時(shí),。 Android源碼中的策略模式實(shí)現(xiàn)：1.時(shí)間插值器（TimeInterpolator）,，LinearInterpolator、AccelerateInterpolator,、CycleInterpolator等實(shí)現(xiàn)Interpolator,，通過(guò)getInterpolator（float input）獲取當(dāng)前的時(shí)間百分比，以此來(lái)計(jì)算動(dòng)畫的屬性值,。 總結(jié) 策略模式主要用來(lái)分離算法,，在相同的行為抽象下有不同的具體實(shí)現(xiàn)策略。這個(gè)模式很好地演示了開閉原則,，也就是定義抽象,，注入不同的實(shí)現(xiàn)，從而達(dá)到很好的可擴(kuò)展性,。 優(yōu)點(diǎn)： 1.結(jié)構(gòu)清晰明了,、使用簡(jiǎn)單直觀。 2.耦合度相對(duì)而言較低,，擴(kuò)展方便,。 3.操作封裝也更為徹底，數(shù)據(jù)更為安全,。 缺點(diǎn)： 1.隨著策略的增加,，子類也會(huì)變得繁多。 >> 7.狀態(tài)模式 1.定義 狀態(tài)模式中的行為是由狀態(tài)來(lái)決定,，不同的狀態(tài)下有不同的行為,。當(dāng)一個(gè)對(duì)象的內(nèi)在狀態(tài)改變時(shí)允許改變其行為,，這個(gè)對(duì)象看起來(lái)像是改變了其類。 2.使用場(chǎng)景 1.一個(gè)對(duì)象的行為取決于它的狀態(tài),，并且它必須在運(yùn)行時(shí)根據(jù)狀態(tài)改變它的行為,。 2.代碼中包含大量與對(duì)象狀態(tài)有關(guān)的條件語(yǔ)句，例如,，一個(gè)操作中含有大量的多分支語(yǔ)句,，且這些分支依賴于該對(duì)象的狀態(tài)。 3簡(jiǎn)單實(shí)現(xiàn) 實(shí)現(xiàn)效果：首先將電視的狀態(tài)分為開機(jī)與關(guān)機(jī)狀態(tài),，開機(jī)時(shí)可以通過(guò)遙控器實(shí)現(xiàn)頻道切換和調(diào)節(jié)音量,，但是關(guān)機(jī)時(shí)，這些操作都會(huì)失效,。 4.與策略模式的區(qū)別 狀態(tài)模式與策略模式的結(jié)構(gòu)幾乎是一樣的,，就像是孿生兄弟。但是他們的目地,、本質(zhì)不一樣,。狀態(tài)模式的行為是平行的、不可替換的,，策略模式的行為是彼此獨(dú)立的,、可相互替換的。狀態(tài)模式,，通常是自我控制狀態(tài)的改變,。而策略模式，是由外部指定使用什么樣的策略,。 5.Android實(shí)戰(zhàn)中的使用： 1.登錄系統(tǒng),，根據(jù)用戶是否登錄,，判斷事件的處理方式,。 2.Wi-Fi管理，在不同的狀態(tài)下,，WiFi的掃描請(qǐng)求處理不一,。 6.總結(jié) 1.優(yōu)點(diǎn) 將所有與一個(gè)特定的狀態(tài)相關(guān)的行為都放入一個(gè)狀態(tài)對(duì)象中，它提供了一個(gè)更好的方法來(lái)組織與特定狀態(tài)相關(guān)的代碼,，將繁瑣的狀態(tài)判斷轉(zhuǎn)換成結(jié)構(gòu)清晰的狀態(tài)類族,，在避免代碼膨脹的同時(shí)也保證了可擴(kuò)展性與可維護(hù)性。 2.缺點(diǎn) 狀態(tài)模式的使用必然會(huì)增加系統(tǒng)類和對(duì)象的個(gè)數(shù),。 >> 8.責(zé)任鏈模式 1.定義 責(zé)任鏈模式是行為型設(shè)計(jì)模式之一,，它使多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求，從而避免了請(qǐng)求的發(fā)送者和接受者之間的耦合關(guān)系,。將這些對(duì)象連成一條鏈,，并沿著這條鏈傳遞該請(qǐng)求,，直到有對(duì)象處理它為止。 2.使用場(chǎng)景 1.多個(gè)對(duì)象可以處理同一請(qǐng)求,，但具體由哪個(gè)對(duì)象處理則在運(yùn)行時(shí)動(dòng)態(tài)決定,。 2.在請(qǐng)求處理者不明確的情況下向多個(gè)對(duì)象中的一個(gè)提交請(qǐng)求。 3.需要?jiǎng)討B(tài)指定一組對(duì)象處理請(qǐng)求,。 3.簡(jiǎn)單實(shí)現(xiàn) 我們?cè)诠居懈鞣N原因需要報(bào)銷費(fèi)用,，首先我們要找我們的上級(jí)領(lǐng)導(dǎo)去審批，報(bào)銷額度如果在領(lǐng)導(dǎo)的權(quán)限范圍內(nèi),，那就審批通過(guò),，否則領(lǐng)導(dǎo)在找自己的上級(jí)去審批，以此類推,。 對(duì)于責(zé)任鏈中的一個(gè)處理者對(duì)象,，有兩個(gè)行為。一是處理請(qǐng)求,，二是將請(qǐng)求傳遞到下一節(jié)點(diǎn),，不允許某個(gè)處理者對(duì)象在處理了請(qǐng)求后又將請(qǐng)求傳送給上一個(gè)節(jié)點(diǎn)的情況。 對(duì)于一條責(zé)任鏈來(lái)說(shuō),，一個(gè)請(qǐng)求最終只有兩種情況,。一是被某個(gè)處理對(duì)象所處理，另一個(gè)是所有對(duì)象均未對(duì)其處理,，對(duì)于前一種情況我們稱為純的責(zé)任鏈模式,，后一種為不純的責(zé)任鏈。實(shí)際中大多為不純的責(zé)任鏈,。 4.Android源碼中的責(zé)任鏈模式：1.View事件的分發(fā)處理 ViewGroup事件投遞的遞歸調(diào)用就類似于一條責(zé)任鏈,，一旦其尋找到責(zé)任者，那么將由責(zé)任者持有并消費(fèi)掉該次事件,，具體體現(xiàn)在View的onTouchEvent方法中返回值的設(shè)置,，如果返回false，那么意味著當(dāng)前的View不會(huì)是該次的責(zé)任人,，將不會(huì)對(duì)其持有,；如果返回true，此時(shí)View會(huì)持有該事件并不再向外傳遞,。 5.總結(jié) 1.優(yōu)點(diǎn) 可以對(duì)請(qǐng)求者和處理者的關(guān)系解耦,，提高代碼的靈活性。 2.缺點(diǎn) 每次都需要對(duì)鏈中請(qǐng)求處理者遍歷,，如果處理者太多那么遍歷必定會(huì)影響性能,，特別是在一些遞歸調(diào)用者中，要慎用。 >>> 9.解釋器模式 解釋器模式是一種用的比較少的行為型模式,，其提供了一種解釋語(yǔ)言的語(yǔ)法或表達(dá)式的方式,。但是它的使用場(chǎng)景確實(shí)很廣泛，只是因?yàn)槲覀冏约汉苌倩厝?gòu)造一個(gè)語(yǔ)言的文法,，所以使用較少,。 1.定義 給定一個(gè)語(yǔ)言，定義它的文法的一種表示,，并定義一個(gè)解釋器,，該解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。（其中語(yǔ)言就是我們需要解釋的對(duì)象,，文法就是這個(gè)語(yǔ)言的規(guī)律,，解 釋器就是翻譯機(jī)，通過(guò)文法來(lái)翻譯語(yǔ)言,。） 2.使用場(chǎng)景 1.如果某個(gè)簡(jiǎn)單的語(yǔ)言需要解釋執(zhí)行而且可以將該語(yǔ)言中的語(yǔ)句表示為一個(gè)抽象的語(yǔ)法樹時(shí)可以考慮使用解釋器模式,。 2.在某些特定的領(lǐng)域出現(xiàn)不斷重復(fù)的問(wèn)題時(shí)，可以將該領(lǐng)域的問(wèn)題轉(zhuǎn)化為一種語(yǔ)法規(guī)則下的語(yǔ)句,，然后構(gòu)建解釋器來(lái)解釋該語(yǔ)句,。 3.簡(jiǎn)單實(shí)現(xiàn) 我們使用解釋器模式對(duì)“m+n+p”這個(gè)表達(dá)式進(jìn)行解釋，那么代表數(shù)字的m,、n和p就可以看成終結(jié)符號(hào),，而“+”這個(gè)運(yùn)算符號(hào)可以當(dāng)做非終結(jié)符號(hào)。 TerminalExpression：終結(jié)符表達(dá)式,，實(shí)現(xiàn)文法中與終結(jié)符有關(guān)的解釋操作,。文法中每個(gè)終結(jié)符都有一個(gè)具體的終結(jié)表達(dá)式與之對(duì)應(yīng)。 NonterminalExpression ：非終結(jié)符表達(dá)式,，實(shí)現(xiàn)文法中與非終結(jié)符有關(guān)的解釋操作,。非終結(jié)符表達(dá)式根據(jù)邏輯的復(fù)雜程度而增加，原則上每個(gè)文法規(guī)則都對(duì)應(yīng)一個(gè)非終結(jié)符表達(dá)式,。 Android源碼中的模式實(shí)現(xiàn)：1.PackageParser PackageParser是對(duì)AndroidManifest.xml配置文件進(jìn)行讀取的,，具體原理參考：解析AndroidManifest原理 5.總結(jié) 1.優(yōu)點(diǎn) 最大的優(yōu)點(diǎn)使其靈活的擴(kuò)展性，當(dāng)我們想對(duì)文法規(guī)則進(jìn)行擴(kuò)展延伸時(shí),，只需要增加相應(yīng)的非終結(jié)符解釋器,，并在構(gòu)建抽象語(yǔ)法樹時(shí),，使用到新增的解釋器對(duì)象進(jìn)行具體的解釋即可,，非常方便。 2.缺點(diǎn) 1.每個(gè)語(yǔ)法都要產(chǎn)生一個(gè)非終結(jié)符表達(dá)式,，語(yǔ)法規(guī)則比較復(fù)雜時(shí),，就可能產(chǎn)生大量的類文件，為維護(hù)帶來(lái)了非常多的麻煩。 2.解釋器模式由于使用了大量的循環(huán)和遞歸,，效率是個(gè)問(wèn)題,，特別是用于解析復(fù)雜、冗長(zhǎng)的語(yǔ)法時(shí),，效率是難以忍受的,。 >> 10.命令模式 命令模式是行為型模式之一?？傮w來(lái)說(shuō)并不難理解,，只是比較繁瑣，他會(huì)將簡(jiǎn)單的調(diào)用關(guān)系解耦成多個(gè)部分,，增加類的復(fù)雜度,，但是即便如此，命令模式的結(jié)構(gòu)依然清晰,。 1.定義 將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象,，從而讓用戶使用不同的請(qǐng)求把客戶端參數(shù)化；對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志,，以及支持可撤銷的操作,。 2.使用場(chǎng)景 （1）需要抽出待執(zhí)行的動(dòng)作，然后以參數(shù)的形式提供出來(lái),。 （2）在不同的時(shí)刻指定,、排列和執(zhí)行請(qǐng)求。一個(gè)命令對(duì)象可以有與初始請(qǐng)求無(wú)關(guān)的生存期,。 （3）需要支持操作取消,。 （4）支持修改日志功能，這樣當(dāng)系統(tǒng)崩潰時(shí),，這些修改可以被重做一遍,。 （5）需要支持事務(wù)操作。 3.簡(jiǎn)單實(shí)現(xiàn) 以推箱子游戲?yàn)槔?，一般游戲中?huì)有五個(gè)按鈕,，分別是左移、右移,、下移,、上移和撤銷。那么玩游戲的人就是客戶端,，五個(gè)按鈕就是調(diào)用者,，執(zhí)行具體按鈕命令的方法是命令角色。 設(shè)計(jì)模式的使用之前也有提到,，主要是要看當(dāng)前場(chǎng)景的復(fù)雜度和以后的需求進(jìn)行擴(kuò)展,、維護(hù)等方面，完全使用設(shè)計(jì)模式也是不提倡的，這就需要設(shè)計(jì)者權(quán)衡利弊了,。 4.Android源碼中的命令模式實(shí)現(xiàn)：1.PackageHandler PackageManagerService中,，其對(duì)包的相關(guān)消息處理右其內(nèi)部類PackageHandler承擔(dān)，其將需要處理的請(qǐng)求作為對(duì)象通過(guò)消息傳遞給相關(guān)的方法,，而對(duì)于包的安裝,、移動(dòng)以及包大小的測(cè)量則分別封裝為HandlerParams的具體子類InstallParams、MoveParams和MeasureParams,。HandlerParams也是一個(gè)抽象命令者,。 5.總結(jié) 1.優(yōu)點(diǎn) 命令模式的封裝性很好，更弱的耦合性,，更靈活的控制性以及更好的擴(kuò)展性,。 2.缺點(diǎn) 類的膨脹，大量衍生類的創(chuàng)建,。 >> 11.觀察者模式 觀察者模式是一個(gè)使用率非常高的模式,，它最常用在GUI系統(tǒng)、訂閱–發(fā)布系統(tǒng),。因?yàn)檫@個(gè)模式的一個(gè)重要作用就是解耦,，將被觀察者和觀察者解耦，使得它們之間的依賴性更小,，甚至做到毫無(wú)依賴,。比如安卓的開源項(xiàng)目EventBus、Otto,、AndroidEventBus等事件總線類的和RxJava響應(yīng)式編程其核心都是使用觀察者模式,。 1.定義 觀察者模式是一種行為類模式，它定義對(duì)象間一種一對(duì)多的依賴關(guān)系,，使得每當(dāng)一個(gè)對(duì)象改變狀態(tài),，則所有依賴于它的對(duì)象都會(huì)得到通知并被自動(dòng)更新。 2.使用場(chǎng)景 （1）關(guān)聯(lián)行為場(chǎng)景,，需要注意的是,，關(guān)聯(lián)行為是可拆分的，而不是“組合”關(guān)系,。 （2）事件多級(jí)觸發(fā)場(chǎng)景,。 （3）跨系統(tǒng)的消息交換場(chǎng)景，如消息隊(duì)列,、事件總線的處理機(jī)制,。 3.簡(jiǎn)單實(shí)現(xiàn) 這里舉一個(gè)追劇的例子，平常為了不錯(cuò)過(guò)最新的電視劇我們會(huì)訂閱或關(guān)注這個(gè)電視劇,，當(dāng)電視劇更新后會(huì)第一時(shí)間推送給我們 Android源碼中的觀察者模式：1.BaseAdapter BaseAdapter我相信大家都不陌生,，在ListView的適配器中我們都是繼承它,。 5.總結(jié) 1.優(yōu)點(diǎn) （1）觀察者和被觀察者之間是抽象耦合,，應(yīng)對(duì)業(yè)務(wù)變化,。 （2）增強(qiáng)系統(tǒng)的靈活性和可擴(kuò)展性。 2.缺點(diǎn) 在應(yīng)用觀察者模式時(shí)需要考慮一下開發(fā)效率和運(yùn)行效率的問(wèn)題,，程序中包括一個(gè)被觀察者,、多個(gè)觀察者，開發(fā),、調(diào)試等內(nèi)容會(huì)比較復(fù)雜,，而且在Java中消息的通知一般是順序執(zhí)行，那么一個(gè)觀察者卡頓,，會(huì)影響整體的執(zhí)行效率,，在這種情況下，一般會(huì)采用異步實(shí)現(xiàn),。 >> 12.備忘錄模式 備忘錄模式是一種行為模式,，該模式用于保存對(duì)象當(dāng)前的狀態(tài)，并且在之后可以再次恢復(fù)到此狀態(tài),，有點(diǎn)像是我們平常說(shuō)的”后悔藥”,。 1.定義 在不破壞封閉的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài),，并在該對(duì)象之外保存這個(gè)狀態(tài),，這樣，以后就可將該對(duì)象恢復(fù)到原先保存的狀態(tài),。 2.使用場(chǎng)景 （1）需要保存一個(gè)對(duì)象在某一個(gè)時(shí)刻的狀態(tài)或部分狀態(tài),。 （2）如果用一個(gè)接口來(lái)讓其他對(duì)象得到這些狀態(tài)，將會(huì)暴露對(duì)象的實(shí)現(xiàn)細(xì)節(jié)并破壞對(duì)象的封裝性,，一個(gè)對(duì)象不希望外界直接訪問(wèn)其內(nèi)部狀態(tài),，通過(guò)中間對(duì)象可以間接訪問(wèn)其內(nèi)部狀態(tài)。 3.簡(jiǎn)單實(shí)現(xiàn) 書中例子：以”使命召喚”游戲?yàn)槔?，用游戲中的存檔功能來(lái)舉例,。 Android源碼中的備忘錄模式：1.onSaveInstanceState和onRestoreInstanceState 當(dāng)Activity不是正常方式退出，且Activity在隨后的時(shí)間內(nèi)被系統(tǒng)殺死之前會(huì)調(diào)用這兩個(gè)方法讓開發(fā)人員可以有機(jī)會(huì)存儲(chǔ)Activity相關(guān)信息,，且在下次返回Activity時(shí)恢復(fù)這些數(shù)據(jù),。通過(guò)這兩個(gè)函數(shù)。開發(fā)人員能夠在某些特殊場(chǎng)景下儲(chǔ)存與界面相關(guān)的信息,，提升用戶體驗(yàn),。 基本使用參考：鏈接 5.總結(jié) 1.優(yōu)點(diǎn) （1）給用戶提供了一種可以恢復(fù)狀態(tài)的機(jī)制，可以使用戶能夠比較方便地回到某個(gè)歷史狀態(tài),。 （2）實(shí)現(xiàn)了信息的封裝,，使用戶不需要關(guān)心狀態(tài)的保存細(xì)節(jié),。 2.缺點(diǎn) 消耗資源，如果類的成員變量過(guò)多,，勢(shì)必會(huì)占用比較大的資源,，而且每一次保存都會(huì)消耗一定的內(nèi)存。 >> 13.迭代器模式 迭代器模式,，又叫做游標(biāo)模式,，是行為型設(shè)計(jì)模式之一。我們知道對(duì)容器對(duì)象的訪問(wèn)必然會(huì)涉及遍歷算法,，我們可以將遍歷的方法封裝在容器中,，或者不提供遍歷方法，讓使用容器的人自己去實(shí)現(xiàn)去吧,。這兩種情況好像都能夠解決問(wèn)題,。 然而在前一種情況，容器承受了過(guò)多的功能,，它不僅要負(fù)責(zé)自己“容器”內(nèi)的元素維護(hù)（添加,、刪除等等），而且還要提供遍歷自身的接口,；而且由于遍歷狀態(tài)保存的問(wèn)題,，不能對(duì)同一個(gè)容器對(duì)象同時(shí)進(jìn)行多個(gè)遍歷。第二種方式倒是省事,，卻又將容器的內(nèi)部細(xì)節(jié)暴露無(wú)遺,。 正因于此，迭代器模式應(yīng)運(yùn)而生,，在客戶訪問(wèn)類與容器體之間插入一個(gè)第三者–迭代器,，很好的解決了上述弊端。 1.定義 提供一種方法順序訪問(wèn)一個(gè)容器對(duì)象中的各個(gè)元素,，而又不需要暴露該對(duì)象的內(nèi)部表示,。 2.使用場(chǎng)景 遍歷一個(gè)容器對(duì)象時(shí)。 3.簡(jiǎn)單實(shí)現(xiàn) 用書中的例子：小民和小輝分別在公司兩個(gè)事業(yè)部,，某天老板安排任務(wù)讓他們倆統(tǒng)計(jì)一下各自部門的員工數(shù)據(jù),。 Android源碼中的模式實(shí)現(xiàn)：1.Cursor 當(dāng)我們使用SQLiteDatabase的query方法查詢數(shù)據(jù)庫(kù)時(shí)，會(huì)返回一個(gè)Cursor游標(biāo)對(duì)象,，該游標(biāo)的實(shí)質(zhì)就是一個(gè)具體的迭代器,，我們可以使用它來(lái)遍歷數(shù)據(jù)庫(kù)查詢所得的結(jié)果集。 5.總結(jié) 迭代器模式發(fā)展至今,，幾乎所有的高級(jí)語(yǔ)言都有相應(yīng)的內(nèi)置實(shí)現(xiàn),，對(duì)于開發(fā)者而言，已經(jīng)極少會(huì)自己去實(shí)現(xiàn)迭代器了,，所以本章內(nèi)容更多的是了解而非應(yīng)用,。 1.優(yōu)點(diǎn) （1）符合面向?qū)ο笤O(shè)計(jì)原則中的單一職責(zé)原則,。 （2）支持對(duì)容器對(duì)象的多種遍歷。弱化了容器類與遍歷算法之間的關(guān)系,。 2.缺點(diǎn) （1）類文件的增加,。 （3）會(huì)出現(xiàn)ConcurrentModificationException異常。 （2）遍歷過(guò)程是一個(gè)單向且不可逆的遍歷,。 >> 14.模板方法模式 模板方法模式是結(jié)構(gòu)最簡(jiǎn)單的行為型設(shè)計(jì)模式,，也是所有模式中最為常見的幾個(gè)模式之一,，是基于繼承的代碼復(fù)用的基本技術(shù),。在其結(jié)構(gòu)中只存在父類與子類之間的繼承關(guān)系。 1.定義 定義一個(gè)操作中的算法的框架,，而將一些步驟延遲到子類中,，使得子類可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。 2.模板方法模式中的方法 1.模板方法 一個(gè)模板方法是定義在抽象類中的,，把基本操作方法組合在一起形成一個(gè)總算法或一個(gè)總行為的方法,。這個(gè)模板方法定義在抽象類中，并由子類不加以修改地完全繼承下來(lái),。所以模板方法大多會(huì)定義為final類型,，指明主要的邏輯功能在子類中不能被重寫。模板方法是一個(gè)具體方法,，它給出了一個(gè)頂層邏輯框架,，而邏輯的組成步驟在抽象類中可以是具體方法，也可以是抽象方法,。由于模板方法是具體方法,，因此模板方法模式中的抽象層只能是抽象類，而不是接口,。 2.基本方法 （1）抽象方法：一個(gè)抽象方法由抽象類聲明,，由具體子類實(shí)現(xiàn)。在Java語(yǔ)言里抽象方法以abstract關(guān)鍵字標(biāo)示,。 （2）鉤子方法：一個(gè)鉤子方法由抽象類聲明并實(shí)現(xiàn),，而子類會(huì)加以擴(kuò)展。子類可以通過(guò)擴(kuò)展鉤子方法來(lái)影響模板方法的邏輯,。 3.使用場(chǎng)景 （1）多個(gè)子類有公有的方法,，并且邏輯基本相同。 （2）重要,、復(fù)雜的算法,，可以把核心算法設(shè)計(jì)為模板方法，周邊的相關(guān)細(xì)節(jié)功能由各個(gè)子類實(shí)現(xiàn),。 （3）重構(gòu)時(shí),，模板方法是一個(gè)經(jīng)常使用的模式,，把相同的代碼抽取到父類中，然后通過(guò)鉤子方法約束其行為,。 4.簡(jiǎn)單實(shí)現(xiàn) 以電腦開機(jī)為例,，假設(shè)現(xiàn)在有兩臺(tái)電腦，一臺(tái)Windows系統(tǒng)電腦,，一臺(tái)Mac系統(tǒng)電腦,。但是開機(jī)流程基本一致：步驟為開啟電源、系統(tǒng)檢查,、加載系統(tǒng),、檢查是否需要登錄。 》Android源碼中的模板方法模式：AsyncTask,；Activity的生命周期 1.AsyncTask 在使用AsyncTask時(shí),，我們都知道把耗時(shí)操作放到doInBackground(Params… params)中，在doInBackground之前,，如果想做一些初始化操作,，可以把實(shí)現(xiàn)寫在onPreExecute中，當(dāng)doInBackground執(zhí)行完后會(huì)執(zhí)行onPostExecute方法,，而我們只需要構(gòu)建AsyncTask對(duì)象,，然后執(zhí)行execute方法。 2.Activity的生命周期 ActivityThread的main函數(shù)被調(diào)用后,，依次執(zhí)行Activity的onCreate,、onStart、onResume函數(shù),，用戶通常在Activity的子類中覆寫onCreate方法,，并且在該方法中調(diào)用setContentView來(lái)設(shè)置布局。 6.區(qū)別 （1）工廠方法是模板方法的一種特殊版本,。 （2）策略模式和模板方法模式都是封裝算法,，一個(gè)用組合，一個(gè)用繼承,。 （3）策略模式和模板模式通?？梢曰ハ嗵鎿Q。它們都像試卷,，策略模式是選擇題,，模板模式是填空題。 7.總結(jié) 模板方法模式用4個(gè)字概括就是：流程封裝,。也就是把某個(gè)固定的流程封裝到一個(gè)final方法中,，并且讓子類能夠定制這個(gè)流程中的某些或者所有步驟，這就要求父類提取公用的代碼,，提升代碼的復(fù)用率,，同時(shí)帶來(lái)了更好的可擴(kuò)展性,。 1.優(yōu)點(diǎn) （1）封裝不變部分，擴(kuò)展可變部分,。 （2）提取公共部分代碼,，便于維護(hù)。 2.缺點(diǎn) 需要為每一個(gè)基本方法的不同實(shí)現(xiàn)提供一個(gè)子類,，如果父類中可變的基本方法太多,，將會(huì)導(dǎo)致類的個(gè)數(shù)增加，系統(tǒng)更加龐大,，設(shè)計(jì)也更加抽象,，此時(shí)，可結(jié)合橋接模式來(lái)進(jìn)行設(shè)計(jì),。 >> 15.訪問(wèn)者模式 訪問(wèn)者模式是一種行為型模式,，它是23種設(shè)計(jì)模式中最復(fù)雜的一個(gè),，雖然使用頻率不高,，但是并不代表可以忽略，在合適的地方,，它會(huì)帶來(lái)意想不到的靈活性,。訪問(wèn)者模式，顧名思義使用了這個(gè)模式后就可以在不修改已有程序結(jié)構(gòu)的前提下,，通過(guò)添加額外的“訪問(wèn)者”來(lái)完成對(duì)已有代碼功能的提升,。 1.定義 封裝一些作用于某種數(shù)據(jù)結(jié)構(gòu)中的各元素的操作，它可以在不改變這個(gè)數(shù)據(jù)結(jié)構(gòu)的前提下定義作用于這些元素的新的操作,。 2.使用場(chǎng)景 （1）對(duì)象結(jié)構(gòu)比較穩(wěn)定,，但經(jīng)常需要在此對(duì)象結(jié)構(gòu)上定義新的操作。 （2）需要對(duì)一個(gè)對(duì)象結(jié)構(gòu)中的對(duì)象進(jìn)行很多不同的且不相關(guān)的操作,，而需要避免這些操作“污染”這些對(duì)象的類,，也不希望在增加新操作時(shí)修改這些類。 3.使用情景：年終了,，公司會(huì)給員工進(jìn)行業(yè)績(jī)考核,。但是，不同領(lǐng)域的管理人員對(duì)于員工的評(píng)定標(biāo)準(zhǔn)不一樣?，F(xiàn)在員工有攻城獅和經(jīng)理,，評(píng)定者有CEO和CTO，我們假定CTO只關(guān)注攻城獅的代碼量,、經(jīng)理的新產(chǎn)品數(shù)量,，而CEO關(guān)注的是攻城獅的KPI和經(jīng)理的KPI以及新產(chǎn)品數(shù)量。 安卓中的著名開源庫(kù)ButterKnife,、Dagger,、Retrofit都是基于APT（Annotation Processing Tools）實(shí)現(xiàn),。而編譯注解核心依賴APT。當(dāng)我們通過(guò)APT處理注解時(shí),，最終會(huì)將獲取到的元素轉(zhuǎn)換為相應(yīng)的Element元素,，以便獲取到它們對(duì)應(yīng)信息。 總結(jié) 1.優(yōu)點(diǎn) （1）各角色職責(zé)分離,，符合單一職責(zé)原則,。 （2）具有優(yōu)秀的擴(kuò)展性。 （3）使得數(shù)據(jù)結(jié)構(gòu)和作用于結(jié)構(gòu)上的操作解耦,，使得操作集合可以獨(dú)立變化,。 （4）靈活性。 2.缺點(diǎn) （1）具體元素對(duì)訪問(wèn)者公布細(xì)節(jié),，違反了迪米特原則,。 （2）具體元素變更時(shí)導(dǎo)致修改成本大。 （3）違反了依賴倒置原則,，為了達(dá)到“區(qū)別對(duì)待”而依賴了具體類,，沒有依賴抽象。 >> 16.中介者模式 中介者模式也稱為調(diào)解者模式或調(diào)停者模式,，是一種行為型模式,。 1.定義 中介者模式包裝了一系列對(duì)象相互作用的方式，使得這些對(duì)象不必相互明顯作用,。從而使它們可以松散耦合,。當(dāng)某些對(duì)象之間的作用發(fā)生改變時(shí)，不會(huì)立即影響其他的一些對(duì)象之間的作用,。保證這些作用可以彼此獨(dú)立的變化,。 2.使用場(chǎng)景 當(dāng)對(duì)象之間的交互操作很多且每個(gè)對(duì)象的行為操作都依賴彼此時(shí)，為防止在修改一個(gè)對(duì)象的行為時(shí),，同時(shí)涉及很多其他對(duì)象的行為,，可使用中介者模式。 4.簡(jiǎn)單實(shí)現(xiàn) 在電腦中,，主機(jī)部分主要分為：CPU,、內(nèi)存、顯卡,、IO設(shè)備,，而將它們整合起來(lái)的就是主板，這里主板就是一個(gè)中介者,。 Android源碼中的中介者模式: 1. Keyguard解鎖屏 詳細(xì)機(jī)制參考：Android4.0 Keyguard解鎖屏機(jī)制 總結(jié) 其實(shí)在Android開發(fā)中我們可能無(wú)意間就使用了中介者模式,，比如登錄注冊(cè)界面，我們使用EditText的addTextChangedListener監(jiān)聽輸入密碼的位數(shù)、用戶名是否為空,，密碼與確認(rèn)密碼是否一致等等判斷時(shí),，此時(shí)多個(gè)控件交互，就是由Activity充當(dāng)中介者來(lái)協(xié)調(diào),。 1.優(yōu)點(diǎn) （1）適當(dāng)?shù)厥褂弥薪檎吣Ｊ娇梢员苊馔骂愔g的過(guò)度耦合,，使得各同事類之間可以相對(duì)獨(dú)立地使用。 （2）使用中介者模式可以將對(duì)象的行為和協(xié)作進(jìn)行抽象,，能夠比較靈活的處理對(duì)象間的相互作用,。 （3）使用中介者模式可以將對(duì)象間多對(duì)多的關(guān)聯(lián)轉(zhuǎn)變?yōu)橐粚?duì)多的關(guān)聯(lián)，使對(duì)象間的關(guān)系易于理解和維護(hù),。 2.缺點(diǎn) 中介者模式是一種比較常用的模式,，也是一種比較容易被濫用的模式。對(duì)于大多數(shù)的情況,，同事類之間的關(guān)系不會(huì)復(fù)雜到混亂不堪的網(wǎng)狀結(jié)構(gòu),，因此，大多數(shù)情況下,，將對(duì)象間的依賴關(guān)系封裝的同事類內(nèi)部就可以的,，沒有必要非引入中介者模式。濫用中介者模式,，只會(huì)讓事情變的更復(fù)雜,。所以，我們決定使用中介者模式之前要多方考慮,、權(quán)衡利弊。 >> 17.代理模式 代理模式也稱委托模式,，是結(jié)構(gòu)型設(shè)計(jì)模式之一,。是應(yīng)用廣泛的模式之一。 1.定義 為其他對(duì)象提供一種代理以控制對(duì)這個(gè)對(duì)象的訪問(wèn),。 2.使用場(chǎng)景 當(dāng)無(wú)法或不想直接訪問(wèn)某個(gè)對(duì)象或訪問(wèn)某個(gè)對(duì)象存在困難時(shí)可以通過(guò)一個(gè)代理對(duì)象來(lái)間接訪問(wèn),，為了保證客戶端使用的透明性，委托對(duì)象與代理對(duì)象需要實(shí)現(xiàn)相同的接口,。 4.簡(jiǎn)單實(shí)現(xiàn) 書中例子：以小民訴訟的流程舉例,。那么需要代理律師代理，訴訟簡(jiǎn)單流程：提交申請(qǐng)–>進(jìn)行舉證–>開始辯護(hù)–>訴訟完成,。 Android源碼中的代理模式實(shí)現(xiàn)：1.ActivityManagerProxy代理類 ActivityManager是Android中管理和維護(hù)Activity的相關(guān)信息的類,，為了隔離它與ActivityManagerService，有效降低二者的耦合,，在這中間使用了ActivityManagerProxy代理類,，所有對(duì)ActivityManagerService的訪問(wèn)都轉(zhuǎn)換成對(duì)代理類的訪問(wèn)，這樣ActivityManager就與ActivityManagerService解耦了。 總結(jié) 1.優(yōu)點(diǎn) （1）對(duì)代理者與被代理者進(jìn)行解耦,。 （2）代理對(duì)象在客戶端和目標(biāo)對(duì)象之間起到一個(gè)中介的作用,，這樣可以起到對(duì)目標(biāo)對(duì)象的保護(hù)。 2.缺點(diǎn) 基本沒有缺點(diǎn),，真要說(shuō)缺點(diǎn)就是設(shè)計(jì)模式的通?。簩?duì)類的增加。 >> 18.組合模式 組合模式也稱為部分-整體模式,，結(jié)構(gòu)型設(shè)計(jì)模式之一,。 1.定義 將對(duì)象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)，使得用戶對(duì)單個(gè)對(duì)象和組合對(duì)象的使用具有一致性,。 2.使用場(chǎng)景 （1）表示對(duì)象的部分-整體層次結(jié)構(gòu)時(shí),。 （2）從一個(gè)整體中能夠獨(dú)立出部分模塊或功能的場(chǎng)景。 4.簡(jiǎn)單實(shí)現(xiàn) 以文件和文件夾這樣的文件系統(tǒng)為例 Android源碼中的模式實(shí)現(xiàn): 1.View和ViewGroup的嵌套組合 View和ViewGroup的結(jié)構(gòu)很像上面的UML類圖,，不過(guò)View的視圖層級(jí)使用的是安全的組合模式,。ViewGroup有對(duì)View的addView、removeView,、getChildAt等方法,，想必大家也很熟悉。 總結(jié) 1.優(yōu)點(diǎn) （1）組合模式可以清楚地定義分層次的復(fù)雜對(duì)象,，表示對(duì)象的全部或部分層次,，他讓高層模塊忽略了層次的差異，方便對(duì)整個(gè)層次結(jié)構(gòu)進(jìn)行控制,。 （2）簡(jiǎn)化了高層模塊的代碼,。 （3）在組合模式中增加新的枝干構(gòu)件和葉子構(gòu)件都很方便，無(wú)須對(duì)現(xiàn)有類庫(kù)進(jìn)行修改,，符合“開閉原則”,。 （4）對(duì)樹形結(jié)構(gòu)的控制變得簡(jiǎn)單。 2.缺點(diǎn) 組合模式不容易限制組合中的構(gòu)件,。因?yàn)榇蠖鄶?shù)情況下,，它們都來(lái)自于相同的抽象層，此時(shí),，必須進(jìn)行類型檢查來(lái)實(shí)現(xiàn),，這個(gè)實(shí)現(xiàn)過(guò)程較為復(fù)雜。 >> 19.適配器模式 適配器模式是結(jié)構(gòu)型設(shè)計(jì)模式之一,，它在我們的開發(fā)中使用率極高,，比如ListView、GridView以及RecyclerView都需要使用Adapter,。 1.定義 適配器模式把一個(gè)類的接口變換成客戶端所期待的另一種接口,，從而使原本因接口不匹配無(wú)法在一起工作的兩個(gè)類可以在一起工作,。 2.使用場(chǎng)景 （1）系統(tǒng)需要使用現(xiàn)有的類，但此類的接口不符合系統(tǒng)的需要,，即接口不兼容,。 （2）想要建立一個(gè)可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類,，包括一些可能在將來(lái)引進(jìn)的類一起工作,。 （3）需要一個(gè)統(tǒng)一的輸出接口，而輸入端的類型不可預(yù)知,。 以筆記本電源適配器為例,，電源適配器將220V的電壓轉(zhuǎn)換到5V。那么5V電壓就是Target接口,，220V電壓就是Adaptee類,，轉(zhuǎn)換就是Adapter。 Android源碼中的適配器模式：1.ListView的Adapter 這里L(fēng)istView的Adapter就是使用的對(duì)象適配器模式,，Target就是View,，Adapter角色就是將Item View輸出為View抽象的角色，Adaptee就是需要被處理的Item View,。 .總結(jié) 1.優(yōu)點(diǎn) （1）更好的復(fù)用性：系統(tǒng)需要使用現(xiàn)有的類,，而此類的接口不符合系統(tǒng)的需要。那么通過(guò)適配器模式就可以讓這些功能得到更好的復(fù)用,。 （2）更好的擴(kuò)展性：在實(shí)現(xiàn)適配器功能的時(shí)候,，可以調(diào)用自己開發(fā)的功能，從而自然地?cái)U(kuò)展系統(tǒng)的功能,。 2.缺點(diǎn) 過(guò)多的使用適配器,，會(huì)讓系統(tǒng)非常零亂，不易整體進(jìn)行把握,。比如,，明明看到調(diào)用的是A接口，其實(shí)內(nèi)部被適配成了B接口的實(shí)現(xiàn),，一個(gè)系統(tǒng)如果太多出現(xiàn)這種情況，無(wú)異于一場(chǎng)災(zāi)難,。因此如果不是很有必要,，可以不使用適配器，而是直接對(duì)系統(tǒng)進(jìn)行重構(gòu),。 >> 20.裝飾模式 裝飾模式也稱為包裝模式,，是結(jié)構(gòu)型設(shè)計(jì)模式之一。裝飾模式是一種用于替代繼承技術(shù)的一種方案,。 1.定義 動(dòng)態(tài)的給一個(gè)對(duì)象添加一些額外的職責(zé),。就增加功能來(lái)說(shuō)，裝飾模式相比生成子類更為靈活。 2.使用場(chǎng)景 （1）需要透明且動(dòng)態(tài)地?cái)U(kuò)展類的功能時(shí),。且在不影響其他對(duì)象的情況下,。 （2）當(dāng)不能采用繼承對(duì)系統(tǒng)進(jìn)行擴(kuò)展時(shí)可以使用裝飾模式。比如final類,。 4.簡(jiǎn)單實(shí)現(xiàn) 以一個(gè)男孩穿衣裝扮為例,。實(shí)現(xiàn)給男孩在家與出門的穿衣裝扮。 區(qū)別 1.與代理模式的區(qū)別 （1）裝飾模式是以對(duì)客戶端透明的方式擴(kuò)展對(duì)象的功能,，是繼承方案的一個(gè)替代,；而代理模式則是給一個(gè)對(duì)象提供一個(gè)代理對(duì)象，并有代理對(duì)象來(lái)控制對(duì)原有對(duì)象的引用,。 （2）裝飾模式應(yīng)該為所裝飾的對(duì)象增強(qiáng)功能,；代理模式是對(duì)代理對(duì)象施加控制，不對(duì)對(duì)象本身功能進(jìn)行增強(qiáng),。 2.與適配器模式的區(qū)別 適配器模式是用新接口來(lái)調(diào)用原接口,，原接口對(duì)新系統(tǒng)是不可見的；裝飾模式增強(qiáng)了其他對(duì)象的功能而同時(shí)又不改變它的接口,。 總結(jié)： 1.優(yōu)點(diǎn) （1）對(duì)于擴(kuò)展一個(gè)對(duì)象的功能,，裝飾模式比繼承更加靈活性，不會(huì)導(dǎo)致類的個(gè)數(shù)急劇增加,。 （2）可以通過(guò)一種動(dòng)態(tài)的方式在運(yùn)行時(shí)選擇不同的具體裝飾類,，從而實(shí)現(xiàn)不同的行為。 （3）可以對(duì)一個(gè)對(duì)象進(jìn)行多次裝飾,，通過(guò)使用不同的具體裝飾類以及這些裝飾類的排列組合,，可以創(chuàng)造出很多不同行為的組合，得到功能更為強(qiáng)大的對(duì)象,。 （4）具體構(gòu)件類與具體裝飾類可以獨(dú)立變化,，用戶可以根據(jù)需要增加新的具體構(gòu)件類和具體裝飾類，原有類庫(kù)代碼無(wú)須改變,，符合“開閉原則”,。 2.缺點(diǎn) （1）使用裝飾模式進(jìn)行系統(tǒng)設(shè)計(jì)時(shí)將產(chǎn)生很多小對(duì)象，這些對(duì)象的區(qū)別在于它們之間相互連接的方式有所不同,，而不是它們的類或者屬性值有所不同,，大量小對(duì)象的產(chǎn)生勢(shì)必會(huì)占用更多的系統(tǒng)資源，在一定程序上影響程序的性能,。 （2）對(duì)于多次裝飾的對(duì)象,，調(diào)試時(shí)尋找錯(cuò)誤可能需要逐級(jí)排查，較為繁瑣,。 >> 21.享元模式 享元模式是結(jié)構(gòu)型設(shè)計(jì)模式之一,，是對(duì)對(duì)象池的一種實(shí)現(xiàn),。就像它的名字一樣，共享對(duì)象,，避免重復(fù)的創(chuàng)建,。我們常用的String 就是使用了共享模式，所以String類型的對(duì)象創(chuàng)建后就不可改變,，如果當(dāng)兩個(gè)String對(duì)象所包含的內(nèi)容相同時(shí),，JVM只創(chuàng)建一個(gè)String對(duì)象對(duì)應(yīng)這兩個(gè)不同的對(duì)象引用。 1.定義 采用一個(gè)共享來(lái)避免大量擁有相同內(nèi)容對(duì)象的開銷,。使用享元模式可有效支持大量的細(xì)粒度對(duì)象,。 2.使用場(chǎng)景 （1）系統(tǒng)中存在大量的相似對(duì)象。 （2）細(xì)粒度的對(duì)象都具備較接近的外部狀態(tài),，而且內(nèi)部狀態(tài)與環(huán)境不關(guān),，也就是說(shuō)對(duì)象沒有特定身份。 （3）需要緩沖池的場(chǎng)景,。 PS：內(nèi)部狀態(tài)與外部狀態(tài)：在享元對(duì)象內(nèi)部并且不會(huì)隨著環(huán)境改變而改變的共享部分,，可以稱之為享元對(duì)象的內(nèi)部狀態(tài)，反之隨著環(huán)境改變而改變的,，不可共享的狀態(tài)稱之為外部狀態(tài),。 4.簡(jiǎn)單實(shí)現(xiàn) 情景：過(guò)年買火車票的時(shí)候，我們需要查詢車票的情況,，那么如果每次查詢車票時(shí)都創(chuàng)建一個(gè)結(jié)果,，那么必然會(huì)大量的創(chuàng)建出許多重復(fù)的對(duì)象，頻繁的去銷毀他們,，使得GC任務(wù)繁重,。那么這時(shí)我們可以使用享元模式，將這些對(duì)象緩存起來(lái),，查詢時(shí)優(yōu)先使用緩存,，沒有緩存在重新創(chuàng)建。 總結(jié) 1.優(yōu)點(diǎn) （1）大大減少應(yīng)用程序創(chuàng)建的對(duì)象,，降低程序內(nèi)存的占用,，增強(qiáng)程序的性能。 （2）使用享元模式,，可以讓享元對(duì)象可以在不同的環(huán)境中被共享,。 2.缺點(diǎn) （1）使得系統(tǒng)更加復(fù)雜。為了使對(duì)象可以共享,，需要將一些狀態(tài)外部化，這使得程序的邏輯復(fù)雜化,。 （2）享元模式將需,、享元對(duì)象的狀態(tài)外部化,，而讀取外部狀態(tài)使得運(yùn)行時(shí)間稍微變長(zhǎng)。 >> 22.外觀模式 外觀模式是結(jié)構(gòu)型設(shè)計(jì)模式之一,，它在開發(fā)中的運(yùn)用頻率非常高,，是我們封裝API的常用手段。我們經(jīng)常使用的三方SDK基本都使用的外觀模式,，這樣可以對(duì)用戶屏蔽很多實(shí)現(xiàn)細(xì)節(jié),，降低用戶使用成本。 1.定義 要求一個(gè)子系統(tǒng)的外部與其內(nèi)部的通信必須通過(guò)一個(gè)統(tǒng)一的對(duì)象進(jìn)行,。外觀模式提供一個(gè)高層次的接口,，使得子系統(tǒng)更易于使用。 2.使用場(chǎng)景 （1）為復(fù)雜子系統(tǒng)提供一個(gè)簡(jiǎn)單接口,，對(duì)外隱藏子系統(tǒng)的具體實(shí)現(xiàn),、隔離變化。 （2）當(dāng)你需要構(gòu)建一個(gè)層次結(jié)構(gòu)的子系統(tǒng)時(shí),，使用外觀模式定義子系統(tǒng)中每層的入口點(diǎn),。如果子系統(tǒng)之間是相互依賴的，你可以讓它們僅通過(guò)外觀接口進(jìn)行通信,，從而簡(jiǎn)化了它們之間的依賴關(guān)系,。 4.簡(jiǎn)單實(shí)例 手機(jī)集合了電話功能、短信功能,、拍照和GPS等功能,。那么以手機(jī)為例，簡(jiǎn)單的用外觀模式實(shí)現(xiàn)一下,。 Android源碼中的外觀模式：1.Context Context 是一個(gè)抽象類,，它的真正實(shí)現(xiàn)是ContextImpl 類，通過(guò)查看ContextImpl 源碼我們可以看到ContextImpl內(nèi)部封裝了很多不同子系統(tǒng)的操作,。例如：Activity的跳轉(zhuǎn),、發(fā)送廣播、啟動(dòng)服務(wù)和設(shè)置壁紙等,，這些工作不是在ContextImpl 中實(shí)現(xiàn),，而是交給了具體的子系統(tǒng)進(jìn)行處理。通過(guò)Context 這個(gè)抽象類定義了一組接口,，ContextImpl實(shí)現(xiàn),。這樣用戶通常情況下就不需要對(duì)每個(gè)子系統(tǒng)進(jìn)行了解。這樣對(duì)用戶屏蔽了具體的實(shí)現(xiàn)細(xì)節(jié),，降低了使用成本,。 總結(jié) 1.優(yōu)點(diǎn) （1）對(duì)客戶程序隱藏子系統(tǒng)的細(xì)節(jié)，因而減少了客戶對(duì)于子系統(tǒng)的耦合,，能夠擁抱變化,。 （2）外觀類對(duì)子系統(tǒng)的接口封裝,，使得系統(tǒng)更易于使用。 2.缺點(diǎn) （1）外觀類接口膨脹,。由于子系統(tǒng)的接口都有外觀類統(tǒng)一對(duì)外暴露,，使得外觀類的API接口較多，在一定程度上增加了用戶使用成本,。 （2）外觀類沒有遵循開閉原則,，當(dāng)業(yè)務(wù)出現(xiàn)變更時(shí)，可能需要直接修改外觀類,。 >> 23.橋接模式 橋接模式也稱為橋梁模式,，是結(jié)構(gòu)型設(shè)計(jì)模式之一。橋接模式中體現(xiàn)了“單一職責(zé)原則”,、“開閉原則”,、“里氏替換原則”、“依賴倒置原則”等,。同時(shí)它也是很實(shí)用的一種模式,。 1.定義 將抽象部分與現(xiàn)實(shí)部分分離，使它們都可以獨(dú)立地進(jìn)行變化,。 2.使用場(chǎng)景 （1）如果一個(gè)系統(tǒng)需要在構(gòu)建的抽象化角色和具體角色之間增加更多的靈活性,，避免在兩個(gè)層次之間建立靜態(tài)的繼承聯(lián)系。 （2）對(duì)于那些不希望使用繼承或因?yàn)槎鄬哟卫^承導(dǎo)致系統(tǒng)類的個(gè)數(shù)急劇增加的系統(tǒng),，也可以考慮使用橋接模式,。 （3）一個(gè)類存在兩個(gè)獨(dú)立變化的維度，且這兩個(gè)維度都需要擴(kuò)展,。 4.簡(jiǎn)單實(shí)現(xiàn) 以去咖啡店喝咖啡為例,，我們假定咖啡有大杯加糖、大杯不加糖,、小杯加糖和小杯不加糖四種,。 Android源碼中的橋接模式：1.Window與WindowManager 總結(jié) 1.優(yōu)點(diǎn) （1）分離抽象與現(xiàn)實(shí)、靈活的擴(kuò)展以及對(duì)客戶來(lái)說(shuō)透明的實(shí)現(xiàn),。 （2）橋接模式可以取代多層繼承,，大大減少了子類的個(gè)數(shù)。 2.缺點(diǎn) 不容易設(shè)計(jì),，對(duì)開發(fā)者來(lái)說(shuō)要有一定的經(jīng)驗(yàn)要求,。理解很容易，設(shè)計(jì)卻不容易,。 >>> 24.MVC的介紹與實(shí)戰(zhàn) 1.MVC的基本介紹 MVC全稱是Model - View - Controller,，是模型(model)－視圖(view)－控制器(controller)的縮寫。MVC是一種框架模式而非設(shè)計(jì)模式，GOF把MVC看作是3種設(shè)計(jì)模式：觀察者模式,、策略模式與組合模式的合體,，而核心是觀察者模式。簡(jiǎn)而言之,，框架是大智慧，用來(lái)對(duì)軟件設(shè)計(jì)進(jìn)行分工,；設(shè)計(jì)模式是小技巧,，對(duì)具體問(wèn)題提出解決方案，以提高代碼復(fù)用率,，降低耦合度,。 1.MVC的優(yōu)點(diǎn) （1）首先就是理解比較容易，技術(shù)含量不高,，這對(duì)開發(fā)和維護(hù)來(lái)說(shuō)成本較低也易于維護(hù)與修改,。 （2）耦合性不高，表現(xiàn)層與業(yè)務(wù)層分離各司其職,，對(duì)開發(fā)來(lái)說(shuō)很有利,。 2.MVC的缺點(diǎn) （1）完全理解MVC并不是很容易。使用MVC需要精心的計(jì)劃,，由于它的內(nèi)部原理比較復(fù)雜,，所以需要花費(fèi)一些時(shí)間去思考。同時(shí)由于模型和視圖要嚴(yán)格的分離,，這樣也給調(diào)試應(yīng)用程序帶來(lái)了一定的困難,。每個(gè)構(gòu)件在使用之前都需要經(jīng)過(guò)徹底的測(cè)試。 （2）對(duì)于小項(xiàng)目,，MVC反而會(huì)帶來(lái)更大的工作量以及復(fù)雜性,。 2.MVC在Android中的應(yīng)用 Android中對(duì)MVC的應(yīng)用很經(jīng)典，在Android中視圖View層一般采用XML文件進(jìn)行界面的描述,。 而對(duì)于模型Model部分則大多對(duì)應(yīng)于本地的數(shù)據(jù)文件或網(wǎng)絡(luò)獲取的數(shù)據(jù)體,，很多情況下我們對(duì)這些數(shù)據(jù)的處理也會(huì)在這一層中進(jìn)行。 最后的控制器Controller則當(dāng)之無(wú)愧的是右Activity承擔(dān),。 3.總結(jié) 雖說(shuō)上面的介紹中我們感受到Android在MVC方面的結(jié)構(gòu),，但是，這個(gè)框架并非我們自己完成的,，而是由framework給我們搭建好的并提供給我們,，在平時(shí)的開發(fā)中，特別是用Android開發(fā),，我們并不常用到MVC模式去脫離Android UI系統(tǒng)構(gòu)建自己的框架結(jié)構(gòu),。 >> 25.MVP應(yīng)用構(gòu)架模式 1.MVP介紹 MVP模式是MVC模式的一個(gè)演化版本，MVP全稱Model-View-Presenter,。目前MVP在Android應(yīng)用開發(fā)中越來(lái)越重要了,。 在Android中,，業(yè)務(wù)邏輯和數(shù)據(jù)存取是緊緊耦合的，很多缺乏經(jīng)驗(yàn)的開發(fā)者很可能會(huì)將各種各樣的業(yè)務(wù)邏輯塞進(jìn)某個(gè)Activity,、Fragment或者自定義View中,，這樣會(huì)使得這些組件的單個(gè)類型臃腫不堪。如果不將具體的業(yè)務(wù)邏輯抽離出來(lái),，當(dāng)UI變化時(shí),，你就需要去原來(lái)的View中抽離具體業(yè)務(wù)邏輯，這必然會(huì)很麻煩并且易出錯(cuò),。 2.使用MVP的好處 （1）MVP模式會(huì)解除View與Model的耦合,，有效的降低View的復(fù)雜性。同時(shí)又帶來(lái)了良好的可擴(kuò)展性,、可測(cè)試性,，保證系統(tǒng)的整潔性和靈活性。 （2）MVP模式可以分離顯示層與邏輯層,，它們之間通過(guò)接口進(jìn)行通信,，降低耦合。理想化的MVP模式可以實(shí)現(xiàn)同一份邏輯代碼搭配不同的顯示界面,，因?yàn)樗鼈冎g并不依賴與具體,，而是依賴于抽象。這使得Presenter可以運(yùn)用于任何實(shí)現(xiàn)了View邏輯接口的UI,，使之具有更廣泛的適用性,，保證了靈活度。 3.MVP模式的三個(gè)角色 （1）Presenter – 交互中間人：Presenter主要作為溝通View與Model的橋梁,，它從Model層檢索數(shù)據(jù)后,，返回給View層，使得View與Model之間沒有耦合,，也將業(yè)務(wù)邏輯從View角色上抽離出來(lái),。 （2）View – 用戶界面：View通常是指Activity、Fragment或者某個(gè)View控件,，它含有一個(gè)Presenter成員變量,。通常View需要實(shí)現(xiàn)一個(gè)邏輯接口，將View上的操作轉(zhuǎn)交給Presenter進(jìn)行實(shí)現(xiàn),，最后,，Presenter 調(diào)用View邏輯接口將結(jié)果返回給View元素。 （3）Model – 數(shù)據(jù)的存?。篗odel 角色主要是提供數(shù)據(jù)的存取功能,。Presenter 需要通過(guò)Model層存儲(chǔ)、獲取數(shù)據(jù)，Model就像一個(gè)數(shù)據(jù)倉(cāng)庫(kù),。更直白的說(shuō),，Model是封裝了數(shù)據(jù)庫(kù)DAO或者網(wǎng)絡(luò)獲取數(shù)據(jù)的角色，或者兩種數(shù)據(jù)方式獲取的集合,。 所以兩者的主要區(qū)別是,，MVP中View不能直接訪問(wèn)Model，需要通過(guò)Presenter發(fā)出請(qǐng)求,，View與Model不能直接通信,。 2.與MVVM（Model-View-ViewModel）的區(qū)別 MVVM與MVP非常相似，唯一區(qū)別是View和Model進(jìn)行雙向綁定,，兩者之間有一方發(fā)生變化則會(huì)反應(yīng)到另一方上。MVVM模式有點(diǎn)像ListView與Adapter,、數(shù)據(jù)集的關(guān)系,，當(dāng)數(shù)據(jù)集發(fā)生變化時(shí)，調(diào)用Adapter的notifyDataSetChanged之后View就直接更新,，同時(shí)它們之間又沒有耦合,，使得ListView變得更加靈活。 《Android源碼設(shè)計(jì)模式解析與實(shí)戰(zhàn)》讀書筆記中demo代碼:http://download.csdn.net/download/qq_17766199/9411032 |
|
|
