原以為自己已經(jīng)比較了解設(shè)計(jì)模式了，誰知面試官一問，我竟然緊張到只記得單例模式。。。囧，So 有了這篇文章
- 策略模式( Strategy )
定義個(gè)策略接口，不同的實(shí)現(xiàn)類提供不同的具體策略算法, 同時(shí)它們之間可以互相替換.
IStrategy 接口定義了策略方法，Strategy1 和 Strategy2 通過實(shí)現(xiàn) IStrategy 提供不同的策略，而 User 組合了 IStrategy ，可以通過給 User 對象設(shè)置不同具體實(shí)現(xiàn)類來讓其獲得不同的策略
策略模式.PNG
- 簡單工廠模式( Simple Factory )
定義一個(gè)用以創(chuàng)建對象的工廠, 根據(jù)不同的條件生成不同的對象
注意簡單工廠模式與策略模式是不同的，工廠模式是根據(jù)給定的條件返回相應(yīng)的對象，而策略模式是將不同的策略對象傳遞給使用者以實(shí)現(xiàn)不同策略,（好吧，我差點(diǎn)分不清了）詳細(xì)不同點(diǎn)分析可轉(zhuǎn)這里
簡單工廠模式.PNG
- 工廠模式( Factory )
針對每一種產(chǎn)品提供一個(gè)工廠類，通過不同的工廠實(shí)例來創(chuàng)建不同的產(chǎn)品實(shí)例
與簡單工廠模式不同點(diǎn)是它要為每一種產(chǎn)品提供一個(gè)工廠類，不同工廠類實(shí)現(xiàn)同一個(gè)工廠接口，返回不同產(chǎn)品，詳細(xì)分析可轉(zhuǎn)這里
工廠模式.PNG
- 抽象工廠模式( Abstract Factory )
應(yīng)對產(chǎn)品族概念而生
與工廠模式相比，抽象工廠模式是為了應(yīng)對產(chǎn)品族
抽象工廠模式.PNG
- 裝飾者模式( Decorator )
動(dòng)態(tài)的給一個(gè)對象添加一些額外的功能
ComponentImpl 和 Decorator 類都實(shí)現(xiàn)了 IComponent 接口，不同的是 ComponentImpl 提供了具體實(shí)現(xiàn)，而 Decorator 是先聚合 ComponentImpl 接著在自己的實(shí)現(xiàn)方法即
operation()方法中做些處理（即裝飾）后再調(diào)用 ComponentImpl 對象的具體實(shí)現(xiàn)
裝飾者模式.PNG
- 代理模式( Proxy )
封裝被代理對象并限制外界對被代理對象的訪問
注意區(qū)分裝飾者模式和代理模式的區(qū)別。在代理模式中，ComponentImpl 和 Proxy 類都實(shí)現(xiàn)了 IComponent 接口，Proxy 對象中雖然也維護(hù)著一個(gè) ComponentImpl 對象，但一般情況下它是代理類自己初始化的，不像裝飾者模式是通過
set進(jìn)去的，同時(shí)在接口方法即operation()中代理對象會(huì)限制外界對被代理對象的訪問，而裝飾者模式是裝飾者給被裝飾者添加額外的行為，詳細(xì)不同點(diǎn)分析可轉(zhuǎn)這里
代理模式.PNG
- 模板方法模式( Template )
定義一個(gè)操作的算法骨架, 并將一些步驟延遲到子類中
AbsTemplate 抽象類中定義了一系列的方法，其中外界唯一能調(diào)用的
operation()方法是 final 的（即不可重寫），在該方法中分別調(diào)用了first()、second()、third()方法（即搭好算法框架），子類通過繼承抽象類重寫不同的方法來添加各自的行為
模板方法模式.PNG
- 外觀模式( Facade )
為系統(tǒng)向外界提供一個(gè)統(tǒng)一的接口
Fracade 為 ComponentA 、ComponentB 、ComponentC 向外即 ClientA 、ClientB 提供統(tǒng)一的接口
外觀模式.PNG
- 適配器模式( Adapter )
將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另一個(gè)接口
比如項(xiàng)目引入第三方類庫后應(yīng)該先封裝起來轉(zhuǎn)換成自己需要的接口再使用，防止以后類庫出現(xiàn)變更。AdapterA 先將 LibraryClass 封裝起來，其對外提供的
operation()方法中調(diào)用 LibraryClass 對象的方法，若以后換類庫，只需改 AdapterA 類或者創(chuàng)建新的 Adapter 實(shí)現(xiàn)類即可
適配器模式.PNG
- 橋接模式( Bridge )
將抽象部分與實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立的變化
將原本要耦合的上下層抽象出來，上層和下層以組合的方式連接，然后上下層抽象可派生出許多不同方向的子類。AbsShape 封裝了 IDrawProgram 接口，這樣它的子類想從 DPA 切換到 DPB 或者別的，只需
set進(jìn)去就行啦（你看，這 UML 圖多像座橋）
橋接模式.PNG
注： 適配器、橋接與外觀三模式之間關(guān)系
- 建造者模式( Builder )
將一個(gè)復(fù)雜對象的構(gòu)建與它的表示分離.
作為 Product 的內(nèi)部類，Builder 統(tǒng)一了 Product 的整個(gè)構(gòu)建過程，同時(shí)在
build過程中，可以由于set值順序不同等原因產(chǎn)生不同的效果
建造者模式.PNG
- 觀察者模式( Observer )
定義了一種一對多的依賴關(guān)系,讓多個(gè)觀察者對象同時(shí)監(jiān)聽某一主題對象,在它的狀態(tài)發(fā)生變化時(shí),會(huì)通知所有的觀察者.
先將 Observer 注冊到 Observable ，那么當(dāng) Observable 狀態(tài)改變時(shí)會(huì)通知它持有的所有 Observer ,對了，最好 Observable 中的 mList 的泛型是
WeakReference<Observer>,防止內(nèi)存泄漏
觀察者模式.PNG
- 單例模式( Singleton )
保證一個(gè)類僅有一個(gè)實(shí)例,并提供一個(gè)訪問它的全局控制點(diǎn).
下圖是利用 Java 的語言特性實(shí)現(xiàn)的線程安全且能延遲初始化的單例模式，Singleton 中維護(hù)著靜態(tài)私有的 SingleHolder 類， SingleHolder 類中持有個(gè)靜態(tài)常量 sHolder ，Client 若通過 getSingleInstance 方法獲取 Singleton 對象則直接返回 SingleHolder 類的 sHolder ，詳細(xì)分析可轉(zhuǎn)這里
- 命令模式( Command )
將一個(gè)請求封裝成為一個(gè)對象, 使可以用不同的請求對客戶進(jìn)行參數(shù)化
Action 封裝了具體行為，Command 封裝了 Action 并提供空方法
execute()，它的子類通過重寫該方法可在方法里調(diào)用 mAction 不同行為達(dá)到封裝命令的目的，最后 Client 封裝了一系列的 Command 對象，并可以通過notify()方法一個(gè)接著一個(gè)調(diào)用所持有 Command 對象們的execute()方法達(dá)到給 Action 傳達(dá)命令的目的
命令模式.PNG
最后
第一次分享文章，難免有點(diǎn)小激動(dòng)，出現(xiàn)小紕漏，請幫忙指出，先多謝了哈。同時(shí)若還有其他常用的設(shè)計(jì)模式我沒涉及，希望能告知哈，一定補(bǔ)上！??！
對了，感謝 ProcessOn 大法！！感覺比StarUML好用
參考文章：
Android 源碼設(shè)計(jì)模式分析開源項(xiàng)目
最常用的12種設(shè)計(jì)模式
