代理模式（PROXY）

介紹：

代理模式也叫委托模式，日常生活中我們接觸的最常見的就是代理上網(wǎng)。

定義：

為其他對像提供一種代理以控制對這個對象的訪問。?

使用場景：

當無法或者不想直接訪問某個對象或訪問某個對象存在困難時可以通過一個代理對象來間接訪問，為了保證客戶端透明性，委托對象與代理對象需要實現(xiàn)相同的接口。

Subject?:?抽象主題類。

RealSubject?:?真實主題類。

ProxySubject?:?代理類。

Client?:?客戶類。

Android源碼里的實現(xiàn)：

Android源碼里的ActivitManagerProxy代理類。

組合模式（COMPOSITE）

介紹：

組合模式也稱為部分整體模式，結(jié)構(gòu)型設(shè)計模式之一。?

定義：

將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)，使得用戶對單個對象和組合對象的實用具有一致性。?

使用場景：

當發(fā)現(xiàn)需求中是體現(xiàn)部分與整體層次結(jié)構(gòu)時，以及你希望用戶可以忽略組合對象與單個對象的不同，統(tǒng)一地使用組合結(jié)構(gòu)中的所有對象時，就應(yīng)該考慮組合模式了。

UML圖：

Component?:抽象根節(jié)點，為組合中的對象聲明接口。

Leaf?:組合中表示葉子節(jié)點對象。

輸出結(jié)果：?

Android源碼里的實現(xiàn)：

View和ViewGroup的嵌套組合。

優(yōu)點：

組合模式可以清楚的定義分層次的復雜對象，方便對整個層次結(jié)構(gòu)進行控制。

缺點：

新增構(gòu)件時不好對枝干的構(gòu)建類型進行限制，因為他們來自于相同的抽象層，因此，必須要時刻進行類型檢查來實現(xiàn)，這個過程較為復雜。

適配器模式（ADAPTER）

介紹：

適配器是將兩個不兼容的類融合在一起工作。?

定義：

適配器模式把一個類的接口編程客戶端所期待的另一種接口，從而使原本因接口不匹配而無法在一起工作的兩個類能夠在一起工作。?

使用場景：

1.系統(tǒng)需要使用現(xiàn)有的類，此類的接口不符合系統(tǒng)的需要，即接口不兼容。2.需要一個統(tǒng)一的輸出接口，?而輸入端的內(nèi)容不可預(yù)知。

3.建立一個可以重復引用的類，用于與一些沒有太大關(guān)聯(lián)的類，一些將來可能引進的類一起工作。

UML圖：

類的適配器：

對象的適配器：

兩者的區(qū)別：

類適配器是客戶類有一個接口規(guī)范的情況下可用，此時適配類只需作為功能類的子類，并實現(xiàn)接口并可，直接用功能類實現(xiàn)了客戶類的要求。

對象適配類是在客戶類沒有提供接口的情況下用的，適配類作為客戶類的子類，并在其中實例化一個功能類的對象，并調(diào)用此對象的方法實現(xiàn)適配，故稱對象適配。

Android源碼里的實現(xiàn)：

ListView里的Adapter，將數(shù)據(jù)和視圖適配到一起。

優(yōu)點：

1.更好的復用性，更好的擴展性

缺點：

1.過多使用了適配器，會讓系統(tǒng)很亂，不易整體把控。

????????????????????????????????????享元模式（FLYWEIGHT）

介紹：

對象池的一種實現(xiàn)，用來盡可能減少內(nèi)存使用量，適用于存在大量重復對象的場景。?

定義：

使用共享對象可有效支持大量細粒度的對象。?

使用場景：

1.系統(tǒng)中存在大量的相似對象。

2.細粒度的對象都具備比較接近的外部狀態(tài)，內(nèi)部狀態(tài)與環(huán)境無關(guān)，對象沒有特定身份。

3.需要緩沖池的場景。?

UML圖：

介紹：

對象池的一種實現(xiàn)，用來盡可能減少內(nèi)存使用量，適用于存在大量重復對象的場景。?

定義：

使用共享對象可有效支持大量細粒度的對象。?

使用場景：

1.系統(tǒng)中存在大量的相似對象。

2.細粒度的對象都具備比較接近的外部狀態(tài)，內(nèi)部狀態(tài)與環(huán)境無關(guān)，對象沒有特定身份。

3.需要緩沖池的場景。?

UML圖：

Flyweight?:?享元對象抽象基類或者接口。

ConcreteFlyweight?:?具體的享元對象。

FlyweightFactory?:?享元工廠，負責管理享元對象池和創(chuàng)建享元對象。

Android源碼里的實現(xiàn)：

Android中SQLiteCompiledSql的使用，是很多數(shù)據(jù)庫系統(tǒng)典型的實現(xiàn)。

SQLiteCompiledSql就是這樣的一個需要共享的享元對象

優(yōu)點：

1. 減少系統(tǒng)中對象的個數(shù)。

2. 使用了外部狀態(tài)，外部狀態(tài)相對獨立，不會影響內(nèi)部狀態(tài)，享元模式使得享元對象能夠在不同環(huán)境中被共享。

缺點：

1. 由于享元模式需要區(qū)分內(nèi)外狀態(tài)，所以程序更加復雜化了。

2. 為了使對象可共享，享元模式需要將享元對象狀態(tài)外部化，讀取外部狀態(tài)使運行時間變長。

外觀模式（FACADE）

介紹：

外觀模式是統(tǒng)一封裝接口，將子系統(tǒng)的邏輯、交互隱藏起來，位用戶提供一個高層次的接口，使系統(tǒng)更加易用，同時隱藏具體實現(xiàn)

定義：

要求子系統(tǒng)的外部和內(nèi)部的通信必須通過一個統(tǒng)一的對象進行，門面模式提供一個高層次接口，使子系統(tǒng)更易于使用。?

使用場景：

1.為復雜的子系統(tǒng)提供簡單的接口。

2.當你需要構(gòu)建一個層次結(jié)構(gòu)的子系統(tǒng)時，使用facade模式定義子系統(tǒng)中每層的入口點。

UML圖：

Facade：將所有從客戶端發(fā)來的請求委派到相應(yīng)的子系統(tǒng)去，傳遞給相應(yīng)的子系統(tǒng)對象處理。

SubSystem：每一個子系統(tǒng)都可以被客戶端直接調(diào)用，或者被外觀角色調(diào)用，它處理由外觀類傳過來的請求；子系統(tǒng)并不知道外觀的存在，對于子系統(tǒng)而言，外觀角色僅僅是另外一個客戶端而已。

Android源碼里的實現(xiàn)：

Android開發(fā)中的Context就是一個外觀模式，Context是一個很多接口的抽象類。

優(yōu)點：

1.?隱藏子系統(tǒng)細節(jié)，減少耦合，能夠擁抱變化。

2.?外觀類對子系統(tǒng)接口封裝，使系統(tǒng)更加易用。

缺點：

1.?外觀類接口膨脹，一定程序上增加了用戶的實用成本。

2.?外觀類沒有遵循開閉原則，業(yè)務(wù)變更時，可能需要直接修改外觀類。

橋接模式（BRIDGE）

介紹：

橋接模式也叫橋梁模式，是結(jié)構(gòu)型設(shè)計模式之一。承擔著連接2邊的作用。?

定義：

將抽象部分與現(xiàn)實部分分離，使他們可以獨立的進行變化。?

使用場景：

這里橋梁的作用就是連接“抽象部分”與“實現(xiàn)部分”，事實上，任何多維度的變化或者說多個樹狀類之間的耦合都可以用橋接模式來解耦。

UML圖：

Abstraction?:?抽象部分

Implementor?:?實現(xiàn)部分

ConcreteImplementorA?B?:?實現(xiàn)部分的具體實現(xiàn)

Android源碼里的實現(xiàn)：

View的視圖層級中，將button，textview等繪制到屏幕上的displayList和canvas,他們之間的關(guān)系就是一種橋接模式。

優(yōu)點：

分離抽象和實現(xiàn)，靈活的擴展和對客戶來說透明的實現(xiàn)

缺點：

不容易設(shè)計。

裝飾模式（DECORATOR）

介紹：

也稱為包裝模式，是繼承關(guān)系的替代方案之一。?

定義：

動態(tài)的給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。?

使用場景：

需要透明且動態(tài)的擴展類的功能時。?

UML圖：

Component?:?抽象組件。

ConcreteComponent?:?組件具體實現(xiàn)類。

Decorator?:?抽象裝飾者。

ConcreteDecoratorA?:?裝飾者具體實現(xiàn)類。

Android源碼里的實現(xiàn)：

在Android源碼中，其中使用到裝飾模式的就是由Context?,ContextWrapper等設(shè)計。