模板方法模式（TEMPLATE?METHOD）

介紹：

知道一個(gè)算法的關(guān)鍵步驟瞭吃，并確定了這些步驟的執(zhí)行順序马篮，但不用的程序步驟是不一樣的晤柄，解決方案就是模板方法模式。

定義：

定義一個(gè)操作中的算法的框架亿昏，將一些步驟延遲到子類(lèi)中峦剔，使得子類(lèi)可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。

使用場(chǎng)景：

1.多個(gè)子類(lèi)有公有的方法角钩，邏輯基本相同時(shí)吝沫。

2.重要、復(fù)雜的算法递礼，可以把核心算法設(shè)計(jì)為模板方法惨险，周邊細(xì)節(jié)功能由子類(lèi)實(shí)現(xiàn)。

3.重構(gòu)時(shí)宰衙，模板方法模式是一個(gè)常用模式平道，把相同代碼抽到父類(lèi)中，通過(guò)鉤子函數(shù)約束其行為供炼。

UML圖：

優(yōu)點(diǎn)：

1.?封裝不變的部分一屋，擴(kuò)展可變的部分。

2.?提取公共部分代碼袋哼，便于維護(hù)冀墨。

缺點(diǎn)：

增加閱讀的難度。

觀察者模式（OBSERVER）

基礎(chǔ)概念：

介紹：

觀察者模式是一個(gè)使用率非常高的模式涛贯，最重要的作用就是解耦诽嘉，使得它們之間的依賴(lài)性更小，甚至做到毫無(wú)依賴(lài)弟翘。

定義：

定義對(duì)象間一對(duì)多的依賴(lài)關(guān)系虫腋，使得每當(dāng)一個(gè)對(duì)象改變狀態(tài)，則所有依賴(lài)它的對(duì)象都會(huì)得到通知并自動(dòng)更新稀余。

使用場(chǎng)景：

1.關(guān)聯(lián)行為場(chǎng)景悦冀，需要注意的是，關(guān)聯(lián)行為是可拆分的睛琳，而不是組合的關(guān)系盒蟆。

2.跨系統(tǒng)的消息交換場(chǎng)景踏烙，如消息隊(duì)列，事件總線的處理機(jī)制历等。

UML圖：

Observer?:?

抽象觀察者讨惩，角色的觀察者的抽象類(lèi)，定義了一個(gè)更新接口寒屯，?主題的更改時(shí)通知更新自己荐捻。

ConcreteObserver?:?

具體的觀察者，該角色實(shí)現(xiàn)抽象觀察者角色所定義的更新接口浩螺，在主題狀態(tài)變化時(shí)更新自身狀態(tài)靴患。

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

Adapter的notifyDataSetChaned()方法

優(yōu)點(diǎn)：

解耦仍侥，靈活性和擴(kuò)展性要出。

缺點(diǎn)：

開(kāi)發(fā)效率和運(yùn)行效率的問(wèn)題，多個(gè)觀察者存在時(shí)開(kāi)發(fā)和調(diào)試的內(nèi)容會(huì)比較復(fù)雜农渊。

狀態(tài)模式（STATE）

基礎(chǔ)概念：

介紹：

狀態(tài)模式的意圖是讓一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變的時(shí)候患蹂，其行為也隨之改變。

定義：

當(dāng)一個(gè)對(duì)象的內(nèi)在狀態(tài)改變時(shí)允許改變其行為砸紊，這個(gè)對(duì)象看起來(lái)像是改變了其類(lèi)传于。

使用場(chǎng)景：1.?一個(gè)對(duì)象的行為取決于它的狀態(tài)，并且它必須在運(yùn)行時(shí)根據(jù)狀態(tài)改變它的行為醉顽。

2.代碼中包含大量與對(duì)象狀態(tài)有關(guān)的條件語(yǔ)句

UML圖：

Context?:?環(huán)境類(lèi)沼溜，定義客戶感興趣的接口，維護(hù)一個(gè)State子類(lèi)實(shí)例

State?:?抽象狀態(tài)類(lèi)或者狀態(tài)接口游添，定義一個(gè)或一組接口系草，表示該狀態(tài)下的行為

ConcreteStateA?ConcreteStateB?:?具體狀態(tài)類(lèi)，實(shí)現(xiàn)每個(gè)具體的行為

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

WIFI管理中的開(kāi)關(guān)

優(yōu)點(diǎn)：

將繁瑣的狀態(tài)判斷結(jié)構(gòu)整理的清晰唆涝。

缺點(diǎn)：

增加類(lèi)的數(shù)量和個(gè)數(shù)找都。

策略模式（STRATEGY）

基礎(chǔ)概念：

介紹：

實(shí)現(xiàn)一個(gè)功能可能會(huì)有多種算法和策略，如果將這些算法或者策略抽象出來(lái)廊酣，提供一個(gè)統(tǒng)一的接口能耻，不同的算法和策略有不同的實(shí)現(xiàn)類(lèi)，在程序客戶端就可以通過(guò)注入不同的對(duì)象來(lái)實(shí)現(xiàn)算法和策略的動(dòng)態(tài)替換亡驰，這種模式的可擴(kuò)展性晓猛，可維護(hù)性就更高，就是策略模式凡辱。

定義：

策略模式定義了一系列的算法戒职，并將每個(gè)算法封裝起來(lái)，它們還可以相互替換煞茫。

使用場(chǎng)景：

1.針對(duì)同一類(lèi)型問(wèn)題的多種處理方式帕涌，僅僅是具體行為有差別時(shí)摄凡。

2.需要安全的封裝多種同一類(lèi)型的操作時(shí)。

3.同一抽象類(lèi)有多個(gè)子類(lèi)蚓曼，又需要使用if-else或者switch來(lái)選擇具體子類(lèi)時(shí)亲澡。

UML圖：

Context?:?用來(lái)操作策略的上下文環(huán)境。

Stragety?:?策略的抽象纫版。

ConcreteStragetyA?ConcreteStragetyB?:?具體的策略實(shí)現(xiàn)床绪。

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

動(dòng)畫(huà)插值器，TimeInterpolator其弊。

優(yōu)點(diǎn)：

結(jié)構(gòu)清晰癞己，耦合度低，封裝更徹底梭伐，數(shù)據(jù)更安全痹雅。

缺點(diǎn)：

子類(lèi)繁多。

責(zé)任鏈模式（Chain?Of?Responsibility）

介紹：

行為型設(shè)計(jì)模式之一糊识，將一個(gè)請(qǐng)求從鏈?zhǔn)降氖锥税l(fā)出绩社，沿著鏈的路徑依次傳遞給每個(gè)節(jié)點(diǎn)對(duì)象，直到有對(duì)象處理這個(gè)請(qǐng)求為止赂苗，這樣的模式叫做責(zé)任鏈模式愉耙。?

定義：

使多個(gè)對(duì)象有機(jī)會(huì)處理請(qǐng)求，避免了請(qǐng)求和發(fā)送者和接受者的耦合關(guān)系拌滋，將這些對(duì)象連城一條鏈朴沿，并沿著這條鏈傳遞該請(qǐng)求败砂，直到有對(duì)象處理它為止赌渣。?

使用場(chǎng)景：

多個(gè)對(duì)象可以處理同一請(qǐng)求，具體由哪個(gè)對(duì)象處理則在運(yùn)行時(shí)動(dòng)態(tài)決定吠卷。

在請(qǐng)求處理者不明確的情況下向多個(gè)對(duì)象中的一個(gè)提交一個(gè)請(qǐng)求锡垄。

需要?jiǎng)討B(tài)指定一組對(duì)象處理請(qǐng)求。

UML圖：

Handler：處理者角色祭隔，聲明一個(gè)請(qǐng)求處理的方法货岭，保持對(duì)下一個(gè)處理節(jié)點(diǎn)Handler對(duì)象的引用。

ConcreteHandler：處理者角色，對(duì)請(qǐng)求進(jìn)行處理，如果不能處理就轉(zhuǎn)發(fā)給下一個(gè)節(jié)點(diǎn)上的處理角色竞思。

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

事件分發(fā)的處理，如：ViewGroup通過(guò)dispatchTouchEvent將事件派發(fā)到View搔谴。

優(yōu)點(diǎn)：

請(qǐng)求者和處理者關(guān)系解耦，提高代碼靈活性桩撮。

缺點(diǎn)：

遍歷過(guò)多敦第，影響性能峰弹。

命令模式（COMMAND）

介紹：

命令模式是行為型設(shè)計(jì)模式之一。將一系列的方法調(diào)用封裝芜果，用戶只需要調(diào)用一個(gè)方法執(zhí)行鞠呈，那么所有這些被封裝的方法就會(huì)被挨個(gè)執(zhí)行調(diào)用。

定義：

將一個(gè)請(qǐng)求封裝成一個(gè)對(duì)象右钾，從而使用戶使用不同的請(qǐng)求吧客戶端參數(shù)化蚁吝，對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，以及可撤銷(xiāo)的操作舀射。

使用場(chǎng)景：

?需要抽象出待執(zhí)行的動(dòng)作窘茁，然后以參數(shù)的形式提供出來(lái)，類(lèi)似于過(guò)程設(shè)計(jì)中的回調(diào)機(jī)制脆烟，而命令模式是毀掉機(jī)制的一個(gè)面向?qū)ο蟮奶娲贰?/p>

UML圖：

Receiver:?接受者角色山林。(處理按鈕方法的角色,游戲本身)

Command:?命令角色。(執(zhí)行具體命令的邏輯方法)

ConcreteCommand:?具體命令角色浩淘。(按鈕方法里的邏輯)

Invoker:?請(qǐng)求者角色捌朴。(俄羅斯方塊的四個(gè)控制按鈕)

Client:?客戶端角色。(玩游戲的人)

優(yōu)點(diǎn)：

弱耦合张抄，更好的擴(kuò)展性。

缺點(diǎn)：

類(lèi)的膨脹洼怔，大量衍生類(lèi)的創(chuàng)建署惯。

訪問(wèn)者模式（VISITOR）

介紹：

知道一個(gè)算法的關(guān)鍵步驟，并確定了這些步驟的執(zhí)行順序镣隶，但不用的程序步驟是不一樣的极谊，解決方案就是模板方法模式。?

定義：

定義一個(gè)操作中的算法的框架安岂，將一些步驟延遲到子類(lèi)中轻猖，使得子類(lèi)可以不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。??

使用場(chǎng)景：

1.多個(gè)子類(lèi)有公有的方法域那，邏輯基本相同時(shí)咙边。

2.重要、復(fù)雜的算法次员，可以把核心算法設(shè)計(jì)為模板方法败许，周邊細(xì)節(jié)功能由子類(lèi)實(shí)現(xiàn)。

3.重構(gòu)時(shí)淑蔚，模板方法模式是一個(gè)常用模式市殷，把相同代碼抽到父類(lèi)中，通過(guò)鉤子函數(shù)約束其行為刹衫。

UML圖：

Visitor?:?接口或者抽象類(lèi)醋寝，定義了每個(gè)元素訪問(wèn)的行為搞挣，

ConcreteVisitor?:?具體訪問(wèn)者，給出對(duì)每個(gè)元素類(lèi)訪問(wèn)時(shí)所產(chǎn)生的具體行為音羞。

Element?:?元素接口或抽象類(lèi)柿究，定義一個(gè)接受訪問(wèn)者方法，每個(gè)元素都要可以被訪問(wèn)者訪問(wèn)黄选。

ElementA?ElementB?:?具體的元素類(lèi)蝇摸，它提供接受訪問(wèn)方法的具體實(shí)現(xiàn)，這個(gè)具體實(shí)現(xiàn)办陷，通常情況下是使用訪問(wèn)者提供的訪問(wèn)該元素類(lèi)的方法貌夕。

ObjectStructure?:?定義當(dāng)中提到的對(duì)象結(jié)構(gòu)，對(duì)象結(jié)構(gòu)是一個(gè)抽象表述民镜，內(nèi)部管理了元素集合啡专，可以迭代這些元素供訪問(wèn)者訪問(wèn)。

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

Android里的注解制圈。

優(yōu)點(diǎn)：?

1.?各角色職責(zé)分離们童，符合單一職責(zé)原則。

2.?優(yōu)秀的擴(kuò)展性鲸鹦。

3.?使得數(shù)據(jù)結(jié)構(gòu)和作用于結(jié)構(gòu)上的操作解耦慧库，使得操作集合可以獨(dú)立變化。

4.?靈活性馋嗜。

缺點(diǎn)：

1.?對(duì)訪問(wèn)者公布細(xì)節(jié)齐板，違反了迪米特原則。

2.?具體元素變更時(shí)導(dǎo)致修改成本大葛菇。

3.?違反了依賴(lài)倒置原則甘磨，為了達(dá)到區(qū)別對(duì)待而依賴(lài)了具體類(lèi)，沒(méi)有依賴(lài)抽象眯停。

中介者模式（MEDIATOR）

介紹：

中介者會(huì)知道所有的節(jié)點(diǎn)济舆，這些節(jié)點(diǎn)可以互不相關(guān)，中介者不屬于同事的任何一方莺债，也不偏袒任何一方滋觉，也稱(chēng)為調(diào)節(jié)者或者調(diào)停者模式。

定義：

中介者模式將多對(duì)多的相互作用轉(zhuǎn)化為一對(duì)多的相互作用九府。

使用場(chǎng)景：

對(duì)象之間交互操作很多每個(gè)對(duì)象的行為彼此依賴(lài)時(shí)椎瘟，可以使用終結(jié)者模式，解決緊耦合問(wèn)題侄旬。該模式將對(duì)象的多對(duì)多關(guān)系變成一對(duì)多關(guān)系肺蔚。

UML圖：

Mediator?:抽象中介者角色，定義了同事對(duì)象到中介者對(duì)象的接口儡羔。

ConcreteMediator?:具體中介者角色宣羊，實(shí)現(xiàn)中介者方法璧诵，向同事發(fā)出指令

Colleague?:抽象同事類(lèi)角色，定義中介者對(duì)象的接口仇冯，它知道中介者不知道其他對(duì)象之宿。

ConcreteColleagueA/B?:具體同事角色

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

Android里的Keyguard鎖屏功能的實(shí)現(xiàn)。

優(yōu)點(diǎn)：?

一個(gè)類(lèi)必然會(huì)和其他幾個(gè)類(lèi)產(chǎn)生依賴(lài)關(guān)系苛坚，中介者模式可以解耦讓邏輯結(jié)構(gòu)清晰比被。

缺點(diǎn)：

如果對(duì)本不復(fù)雜的依賴(lài)關(guān)系使用中介者模式會(huì)讓邏輯結(jié)構(gòu)變的復(fù)雜。

備忘錄模式（MEMENTO）

介紹：

備忘錄模式是一種行為模式泼舱，該模式用于保存對(duì)象當(dāng)前狀態(tài)等缀，并且在之后恢復(fù)到這種狀態(tài)。目的是為了保護(hù)好被保存對(duì)象狀態(tài)的完整性及內(nèi)部實(shí)現(xiàn)不向外暴露娇昙。

定義：

不破壞封閉的前提下尺迂，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)冒掌，以后就可以將該對(duì)象恢復(fù)到原先保存的狀態(tài)噪裕。

使用場(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)皇拣。

UML圖：

Originator?:?負(fù)責(zé)創(chuàng)建一個(gè)備忘錄严蓖，可以記錄，恢復(fù)自身的狀態(tài)氧急。

Memento?:?備忘錄角色，存儲(chǔ)Originator的內(nèi)部分享毫深，防止Originator以外的對(duì)象訪問(wèn)Memento.

Caretaker?:?負(fù)責(zé)存儲(chǔ)備忘錄吩坝，不能對(duì)備忘錄內(nèi)容進(jìn)行操作和訪問(wèn)，只能將備忘錄傳給其他對(duì)象哑蔫。

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

Activity里的onSaveInsanceState?與onRestoreInstanceState钉寝。

優(yōu)點(diǎn)：

實(shí)現(xiàn)了信息的封裝，用戶不需要關(guān)心狀態(tài)的保存細(xì)節(jié)闸迷。

缺點(diǎn)：

消耗資源嵌纲，每次保存都會(huì)消耗一定的內(nèi)存

迭代器模式（ITERATOR）

介紹：

迭代器模式又稱(chēng)游標(biāo)模式，是行為型設(shè)計(jì)模式腥沽。

定義：

提供一種方法順序訪問(wèn)一個(gè)容器對(duì)象中的各個(gè)元素逮走，而又不需要暴露該對(duì)象的內(nèi)部表示。

使用場(chǎng)景：

遍歷一個(gè)容器對(duì)象時(shí)今阳。

UML圖：

Iterator?:?迭代器接口

Concrete?Iterator?:?具體迭代器類(lèi)

Aggregate?:?容器接口

Concrete?Aggregate?:?具體容器類(lèi)

Client?:?客戶類(lèi)

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

數(shù)據(jù)庫(kù)查詢(xún)Cursor师溅。

優(yōu)點(diǎn)：?

支持以不用的方式去遍歷一個(gè)對(duì)象茅信。

缺點(diǎn)：

缺點(diǎn)就是類(lèi)文件的增加。

解釋器模式（INTERPRETER）

基礎(chǔ)概念：

介紹：

解釋器模式是用的比較少的行為型模式之一墓臭，提供了一種解釋語(yǔ)言的語(yǔ)法或表達(dá)式的方式蘸鲸，該模式定義了一個(gè)表達(dá)式接口，通過(guò)該接口解釋一個(gè)特定的上下文窿锉。

定義：

給定一個(gè)語(yǔ)言(如由abcdef六個(gè)字符組成的字符串集合)?,?定義它的文法的一種表示(如S：：=cd),并定義一個(gè)解釋器酌摇，該解釋器使用該表示來(lái)解釋語(yǔ)言中的句子。

使用場(chǎng)景：

1.某個(gè)簡(jiǎn)單的語(yǔ)言需要解釋執(zhí)行而且可以將該語(yǔ)言中的語(yǔ)句表示為一個(gè)抽象語(yǔ)法樹(shù)時(shí)可以考慮使用解釋器模式嗡载。

2.在某些特定的領(lǐng)域出現(xiàn)不斷重復(fù)的問(wèn)題時(shí)窑多，可以將該領(lǐng)域的問(wèn)題轉(zhuǎn)化為一種語(yǔ)法規(guī)則下的語(yǔ)句，然后構(gòu)建解釋器來(lái)解釋該語(yǔ)句鼻疮。

UML圖：

AbstractExpression?:?抽象表達(dá)式

TerminalExpression?:?終結(jié)符表達(dá)式

NonterminalExpression?:?非終結(jié)符表達(dá)式

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

Android通過(guò)PackageParser類(lèi)解析AndroidManifest文件怯伊，PackageParser對(duì)AndroidManifest每個(gè)組件標(biāo)簽了相應(yīng)的類(lèi)用于存儲(chǔ)相應(yīng)的信息。

優(yōu)點(diǎn)：

擴(kuò)展性佳判沟，對(duì)現(xiàn)有文法擴(kuò)展時(shí)耿芹，只需要增加對(duì)應(yīng)的非終結(jié)符解釋器。

構(gòu)建抽象語(yǔ)法樹(shù)時(shí)挪哄，使用新增的解釋器對(duì)象進(jìn)行具體的解釋即可吧秕。

缺點(diǎn)：

每個(gè)文法生成一個(gè)類(lèi)，后期維護(hù)困難迹炼，對(duì)于復(fù)雜的文法不推薦使用解釋器模式砸彬。