《軟件建模與實(shí)踐》課件-8-軟件設(shè)計(jì)模式-行為型模式 - 副本

課程內(nèi)容11種行為型模式的基本概念、特點(diǎn)及其適用環(huán)境課程目的了解行為型模式的基本概念掌握11種行為型模式的特點(diǎn)及其適用環(huán)境。進(jìn)一步熟悉和掌握類圖及其他軟件結(jié)構(gòu)的表現(xiàn)和表達(dá)方式。掌握在實(shí)際需求下應(yīng)用行為型設(shè)計(jì)模式的方法。重點(diǎn)迭代器模式、觀察者模式難點(diǎn)解釋器模式，訪問者模式8.1行為型模式行為型模式(BehavioralPattern)

關(guān)注系統(tǒng)中對(duì)象之間的交互，研究系統(tǒng)在運(yùn)行時(shí)對(duì)象之間的相互通信與協(xié)作，進(jìn)一步明確對(duì)象的職責(zé)行為型模式：不僅僅關(guān)注類和對(duì)象本身，還重點(diǎn)關(guān)注它們之間的相互作用和職責(zé)劃分2025/2/138:39行為型模式類行為型模式使用繼承關(guān)系在幾個(gè)類之間分配行為，主要通過多態(tài)等方式來分配父類與子類的職責(zé)對(duì)象行為型模式使用對(duì)象的關(guān)聯(lián)關(guān)系來分配行為，主要通過對(duì)象關(guān)聯(lián)等方式來分配兩個(gè)或多個(gè)類的職責(zé)行為型模式行為型模式一覽表模式名稱定

義學(xué)習(xí)難度使用頻率職責(zé)鏈模式(ChainofResponsibilityPattern)避免將一個(gè)請(qǐng)求的發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求。將接收請(qǐng)求的對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，直到有一個(gè)對(duì)象能夠處理它為止?！铩铩铩铩锩钅Ｊ?CommandPattern)將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而讓你可以用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化，對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，以及支持可撤銷的操作。★★★★★★★解釋器模式(InterpreterPattern)給定一個(gè)語言，定義它的文法的一種表示，并定義一個(gè)解釋器，這個(gè)解釋器使用該表示來解釋語言中的句子?！铩铩铩铩铩锏髂Ｊ?IteratorPattern)提供一種方法順序訪問一個(gè)聚合對(duì)象中的各個(gè)元素，且不用暴露該對(duì)象的內(nèi)部表示。★★★★★★★★中介者模式(MediatorPattern)定義一個(gè)對(duì)象來封裝一系列對(duì)象的交互。中介者模式使各對(duì)象之間不需要顯式地相互引用，從而使其耦合松散，而且讓你可以獨(dú)立地改變它們之間的交互。★★★★★備忘錄模式(MementoPattern)在不破壞封裝的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)，這樣可以在以后將對(duì)象恢復(fù)到原先保存的狀態(tài)?！铩铩铩镉^察者模式(ObserverPattern)定義對(duì)象之間的一種一對(duì)多依賴關(guān)系，使得每當(dāng)一個(gè)對(duì)象狀態(tài)發(fā)生改變時(shí)，其相關(guān)依賴對(duì)象都得到通知并被自動(dòng)更新?！铩铩铩铩铩铩铩餇顟B(tài)模式(StatePattern)允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來似乎修改了它的類?！铩铩铩铩铩锊呗阅Ｊ?StrategyPattern)定義一系列算法，將每一個(gè)算法封裝起來，并讓它們可以相互替換，策略模式讓算法可以獨(dú)立于使用它的客戶變化?！铩铩铩铩锬０宸椒Ｊ?TemplateMethodPattern)定義一個(gè)操作中算法的框架，而將一些步驟延遲到子類中。模板方法模式使得子類不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。★★★★★訪問者模式(VisitorPattern)表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各個(gè)元素的操作。訪問者模式讓你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。★★★★★2025/2/138:39貸款分級(jí)審批示意圖2025/2/138:398.2職責(zé)鏈模式職責(zé)鏈模式概述分析貸款資格審批，主任、副董事長(zhǎng)、董事長(zhǎng)和董事會(huì)都可以處理貸款審批，他們可以構(gòu)成一條處理貸款審批的鏈?zhǔn)浇Y(jié)構(gòu)，貸款審批沿著這條鏈進(jìn)行傳遞，這條鏈就稱為職責(zé)鏈職責(zé)鏈可以是一條直線、一個(gè)環(huán)或者一個(gè)樹形結(jié)構(gòu)，最常見的職責(zé)鏈?zhǔn)侵本€型，即沿著一條單向的鏈來傳遞請(qǐng)求職責(zé)鏈模式概述職責(zé)鏈模式的定義對(duì)象行為型模式職責(zé)鏈模式：避免將一個(gè)請(qǐng)求的發(fā)送者與接收者耦合在一起，讓多個(gè)對(duì)象都有機(jī)會(huì)處理請(qǐng)求。將接收請(qǐng)求的對(duì)象連接成一條鏈，并且沿著這條鏈傳遞請(qǐng)求，直到有一個(gè)對(duì)象能夠處理它為止。職責(zé)鏈模式概述職責(zé)鏈模式的定義又稱為責(zé)任鏈模式（翻譯不同，

）將請(qǐng)求的處理者組織成一條鏈，并讓請(qǐng)求沿著鏈傳遞，由鏈上的處理者對(duì)請(qǐng)求進(jìn)行相應(yīng)的處理客戶端無須關(guān)心請(qǐng)求的處理細(xì)節(jié)以及請(qǐng)求的傳遞，只需將請(qǐng)求發(fā)送到鏈上，將請(qǐng)求的發(fā)送者和請(qǐng)求的處理者解耦職責(zé)鏈模式的原理與框架職責(zé)鏈模式的結(jié)構(gòu)職責(zé)鏈模式的原理與框架職責(zé)鏈模式的結(jié)構(gòu)職責(zé)鏈模式包含以下兩個(gè)角色：Handler（抽象處理者）ConcreteHandler（具體處理者）職責(zé)鏈模式的應(yīng)用案例-貸款業(yè)務(wù)系統(tǒng)的分級(jí)審批實(shí)例說明某軟件公司承接了某銀行的貸款業(yè)務(wù)系統(tǒng)的開發(fā)任務(wù)，其中包含一個(gè)貸款資格審批子系統(tǒng)。該銀行的資格審批是分級(jí)進(jìn)行的，即根據(jù)貸款金額的不同由不同層次的主管人員來審批，主任可以審批5萬元以下(不包括5萬元)的貸款，副董事長(zhǎng)可以審批5萬元至50萬元(不包括50萬元)的貸款，董事長(zhǎng)可以審批50萬元至200萬元(不包括200萬元)的貸款，200萬元及以上的貸款就需要開董事會(huì)討論決定。如下圖所示：貸款分級(jí)審批示意圖現(xiàn)使用職責(zé)鏈模式設(shè)計(jì)并實(shí)現(xiàn)該系統(tǒng)。職責(zé)鏈模式的應(yīng)用案例實(shí)例類圖貸款分級(jí)審批結(jié)構(gòu)圖職責(zé)鏈模式的應(yīng)用案例實(shí)例代碼抽象類Approver充當(dāng)抽象處理者(抽象傳遞者)Director(主任)VicePresident(副董事長(zhǎng))President(董事長(zhǎng))Congress(董事會(huì))充當(dāng)具體處理者(具體傳遞者)LoanRequest充當(dāng)請(qǐng)求類純與不純的職責(zé)鏈模式純的職責(zé)鏈模式一個(gè)具體處理者對(duì)象只能在兩個(gè)行為中選擇一個(gè)：要么承擔(dān)全部責(zé)任，要么將責(zé)任推給下家不允許出現(xiàn)某一個(gè)具體處理者對(duì)象在承擔(dān)了一部分或全部責(zé)任后又將責(zé)任向下傳遞的情況一個(gè)請(qǐng)求必須被某一個(gè)處理者對(duì)象所接收，不能出現(xiàn)某個(gè)請(qǐng)求未被任何一個(gè)處理者對(duì)象處理的情況純與不純的職責(zé)鏈模式不純的職責(zé)鏈模式允許某個(gè)請(qǐng)求被一個(gè)具體處理者部分處理后向下傳遞，或者一個(gè)具體處理者處理完某請(qǐng)求后其后繼處理者可以繼續(xù)處理該請(qǐng)求一個(gè)請(qǐng)求可以最終不被任何處理者對(duì)象所接收并處理JavaScript的事件浮升(EventBubbling)處理機(jī)制2025/2/138:39職責(zé)鏈模式的優(yōu)缺點(diǎn)與適用場(chǎng)景模式優(yōu)點(diǎn)使得一個(gè)對(duì)象無須知道是其他哪一個(gè)對(duì)象處理其請(qǐng)求，降低了系統(tǒng)的耦合度可簡(jiǎn)化對(duì)象之間的相互連接給對(duì)象職責(zé)的分配帶來更多的靈活性增加一個(gè)新的具體請(qǐng)求處理者時(shí)無須修改原有系統(tǒng)的代碼，只需要在客戶端重新建鏈即可職責(zé)鏈模式的優(yōu)缺點(diǎn)與適用場(chǎng)景模式缺點(diǎn)不能保證請(qǐng)求一定會(huì)被處理對(duì)于比較長(zhǎng)的職責(zé)鏈，系統(tǒng)性能將受到一定影響，在進(jìn)行代碼調(diào)試時(shí)不太方便如果建鏈不當(dāng)，可能會(huì)造成循環(huán)調(diào)用，將導(dǎo)致系統(tǒng)陷入死循環(huán)2025/2/138:39職責(zé)鏈模式的優(yōu)缺點(diǎn)與適用場(chǎng)景模式適用環(huán)境有多個(gè)對(duì)象可以處理同一個(gè)請(qǐng)求，具體哪個(gè)對(duì)象處理該請(qǐng)求待運(yùn)行時(shí)刻再確定在不明確指定接收者的情況下，向多個(gè)對(duì)象中的一個(gè)提交一個(gè)請(qǐng)求可動(dòng)態(tài)指定一組對(duì)象處理請(qǐng)求8.3命令模式概述開關(guān)與電燈、排氣扇示意圖命令模式概述分析現(xiàn)實(shí)生活相同的開關(guān)可以通過不同的電線來控制不同的電器開關(guān)

請(qǐng)求發(fā)送者電燈

請(qǐng)求的最終接收者和處理者開關(guān)和電燈之間并不存在直接耦合關(guān)系，它們通過電線連接在一起，使用不同的電線可以連接不同的請(qǐng)求接收者命令模式概述分析軟件開發(fā)按鈕

請(qǐng)求發(fā)送者事件處理類

請(qǐng)求的最終接收者和處理者發(fā)送者與接收者之間引入了新的命令對(duì)象（類似電線），將發(fā)送者的請(qǐng)求封裝在命令對(duì)象中，再通過命令對(duì)象來調(diào)用接收者的方法相同的按鈕可以對(duì)應(yīng)不同的事件處理類命令模式概述動(dòng)機(jī)將請(qǐng)求發(fā)送者和接收者完全解耦發(fā)送者與接收者之間沒有直接引用關(guān)系發(fā)送請(qǐng)求的對(duì)象只需要知道如何發(fā)送請(qǐng)求，而不必知道如何完成請(qǐng)求對(duì)象行為型模式命令模式：將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，從而讓你可以用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化，對(duì)請(qǐng)求排隊(duì)或者記錄請(qǐng)求日志，以及支持可撤銷的操作。命令模式概述別名為動(dòng)作(Action)模式或事務(wù)(Transaction)模式“用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化”“對(duì)請(qǐng)求排隊(duì)”“記錄請(qǐng)求日志”“支持可撤銷操作”命令模式概述命令模式的原理與框架命令模式的結(jié)構(gòu)命令模式的原理與框架命令模式的結(jié)構(gòu)命令模式包含以下4個(gè)角色：Command（抽象命令類）ConcreteCommand（具體命令類）Invoker（調(diào)用者）Receiver（接收者）命令模式的原理與框架命令模式的實(shí)現(xiàn)命令模式的本質(zhì)是對(duì)請(qǐng)求進(jìn)行封裝一個(gè)請(qǐng)求對(duì)應(yīng)于一個(gè)命令，將發(fā)出命令的責(zé)任和執(zhí)行命令的責(zé)任分開命令模式允許請(qǐng)求的一方和接收的一方獨(dú)立開來，使得請(qǐng)求的一方不必知道接收請(qǐng)求的一方的接口，更不必知道請(qǐng)求如何被接收、操作是否被執(zhí)行、何時(shí)被執(zhí)行，以及是怎么被執(zhí)行的命令模式的應(yīng)用案例-自定義功能鍵某軟件公司開發(fā)人員為公司內(nèi)部OA系統(tǒng)開發(fā)了一個(gè)桌面版應(yīng)用程序，該應(yīng)用程序?yàn)橛脩籼峁┝艘幌盗凶远x功能鍵，用戶可以通過這些功能鍵來實(shí)現(xiàn)一些快捷操作。該軟件公司開發(fā)人員通過分析，發(fā)現(xiàn)不同的用戶可能會(huì)有不同的使用習(xí)慣，在設(shè)置功能鍵的時(shí)候每個(gè)人都有自己的喜好，例如有的人喜歡將第一個(gè)功能鍵設(shè)置為“打開幫助文檔”，有的人則喜歡將該功能鍵設(shè)置為“最小化至托盤”，為了讓用戶能夠靈活地進(jìn)行功能鍵的設(shè)置，開發(fā)人員提供了一個(gè)“功能鍵設(shè)置”窗口，如下所示：用戶可以通過修改配置文件來改變功能鍵的用途，現(xiàn)使用命令模式來設(shè)計(jì)該系統(tǒng)，使得功能鍵類與功能類之間解耦，可為同一個(gè)功能鍵設(shè)置不同的功能。命令模式的應(yīng)用案例實(shí)例類圖自定義功能鍵核心結(jié)構(gòu)圖命令模式的應(yīng)用案例實(shí)例代碼FBSettingWindow是“功能鍵設(shè)置”界面類FunctionButton充當(dāng)請(qǐng)求調(diào)用者Command充當(dāng)抽象命令類MinimizeCommand和HelpCommand充當(dāng)具體命令類WindowHanlder和HelpHandler充當(dāng)請(qǐng)求接收者命令模式的應(yīng)用案例結(jié)果及分析如果需要更換具體命令類，無須修改源代碼，只需修改配置文件，完全符合開閉原則每一個(gè)具體命令類對(duì)應(yīng)一個(gè)請(qǐng)求的處理者（接收者），通過向請(qǐng)求發(fā)送者注入不同的具體命令對(duì)象可以使相同的發(fā)送者對(duì)應(yīng)不同的接收者，從而實(shí)現(xiàn)“將一個(gè)請(qǐng)求封裝為一個(gè)對(duì)象，用不同的請(qǐng)求對(duì)客戶進(jìn)行參數(shù)化”，客戶端只需要將具體命令對(duì)象作為參數(shù)注入請(qǐng)求發(fā)送者，無須直接操作請(qǐng)求的接收者<?xmlversion="1.0"encoding="utf-8"?><configuration><appSettings><addkey="command"value="CommandSample.HelpCommand"/></appSettings></configuration>命令模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)降低了系統(tǒng)的耦合度新的命令可以很容易地加入到系統(tǒng)中，符合開閉原則可以比較容易地設(shè)計(jì)一個(gè)命令隊(duì)列或宏命令（組合命令）為請(qǐng)求的撤銷(Undo)和恢復(fù)(Redo)操作提供了一種設(shè)計(jì)和實(shí)現(xiàn)方案命令模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)使用命令模式可能會(huì)導(dǎo)致某些系統(tǒng)有過多的具體命令類（針對(duì)每一個(gè)對(duì)請(qǐng)求接收者的調(diào)用操作都需要設(shè)計(jì)一個(gè)具體命令類）命令模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境系統(tǒng)需要將請(qǐng)求調(diào)用者和請(qǐng)求接收者解耦，使得調(diào)用者和接收者不直接交互系統(tǒng)需要在不同的時(shí)間指定請(qǐng)求、將請(qǐng)求排隊(duì)和執(zhí)行請(qǐng)求系統(tǒng)需要支持命令的撤銷(Undo)操作和恢復(fù)(Redo)操作系統(tǒng)需要將一組操作組合在一起形成宏命令8.4迭代器模式電視機(jī)遙控器與電視機(jī)示意圖迭代器模式概述分析電視機(jī)

存儲(chǔ)電視頻道的集合

聚合類(AggregateClasses)電視機(jī)遙控器

操作電視頻道

迭代器(Iterator)訪問一個(gè)聚合對(duì)象中的元素但又不需要暴露它的內(nèi)部結(jié)構(gòu)迭代器模式概述分析聚合對(duì)象的兩個(gè)職責(zé)：存儲(chǔ)數(shù)據(jù)，聚合對(duì)象的基本職責(zé)遍歷數(shù)據(jù)，既是可變化的，又是可分離的將遍歷數(shù)據(jù)的行為從聚合對(duì)象中分離出來，封裝在迭代器對(duì)象中由迭代器來提供遍歷聚合對(duì)象內(nèi)部數(shù)據(jù)的行為，簡(jiǎn)化聚合對(duì)象的設(shè)計(jì)，更符合單一職責(zé)原則迭代器模式的定義對(duì)象行為型模式迭代器模式：提供一種方法順序訪問一個(gè)聚合對(duì)象中各個(gè)元素，且不用暴露該對(duì)象的內(nèi)部表示。迭代器模式概述迭代器模式概述迭代器模式的定義又名游標(biāo)(Cursor)模式通過引入迭代器，客戶端無須了解聚合對(duì)象的內(nèi)部結(jié)構(gòu)即可實(shí)現(xiàn)對(duì)聚合對(duì)象中成員的遍歷，還可以根據(jù)需要很方便地增加新的遍歷方式2025/2/138:39迭代器模式的原理與框架迭代器模式的結(jié)構(gòu)迭代器模式的原理與框架迭代器模式的結(jié)構(gòu)迭代器模式包含以下4個(gè)角色：Iterator（抽象迭代器）ConcreteIterator（具體迭代器）Aggregate（抽象聚合類）ConcreteAggregate（具體聚合類）應(yīng)用案例-商品交易系統(tǒng)中數(shù)據(jù)的遍歷實(shí)例說明某軟件公司為某商場(chǎng)開發(fā)了一套商品交易系統(tǒng)，在對(duì)該系統(tǒng)進(jìn)行分析和設(shè)計(jì)時(shí)，該軟件公司開發(fā)人員發(fā)現(xiàn)經(jīng)常需要對(duì)系統(tǒng)中的商品數(shù)據(jù)、用戶數(shù)據(jù)等進(jìn)行遍歷，為了復(fù)用這些遍歷代碼，公司開發(fā)人員設(shè)計(jì)了一個(gè)抽象的數(shù)據(jù)集合類AbstractDataList，而將存儲(chǔ)商品和用戶等數(shù)據(jù)的類作為其子類。AbstractDataList類結(jié)構(gòu)如下圖所示：

AbstractDataList類結(jié)構(gòu)圖在圖中，List類型的對(duì)象objects用于存儲(chǔ)數(shù)據(jù)，其方法與說明如下表所示：方法名方法說明AbstractDataList()構(gòu)造方法，用于給objects對(duì)象賦值addObject()增加元素removeObject()刪除元素getObjects()獲取所有元素next()移至下一個(gè)元素isLast()判斷當(dāng)前元素是否是最后一個(gè)元素previous()移至上一個(gè)元素isFirst()判斷當(dāng)前元素是否是第一個(gè)元素getNextItem()獲取下一個(gè)元素getPreviousItem()獲取上一個(gè)元素表AbstractDataList類方法說明AbstractDataList類存在的問題聚合類的職責(zé)過重，既負(fù)責(zé)存儲(chǔ)和管理數(shù)據(jù)，又負(fù)責(zé)遍歷數(shù)據(jù)，違反了單一職責(zé)原則。聚合類非常龐大，實(shí)現(xiàn)代碼過長(zhǎng)，還將給測(cè)試和維護(hù)增加難度。如果將抽象聚合類聲明為一個(gè)接口，則在這個(gè)接口中充斥著大量方法，不利于子類實(shí)現(xiàn)，違反了接口隔離原則。如果將所有的遍歷操作都交給子類來實(shí)現(xiàn)，將導(dǎo)致子類代碼龐大，而且必須暴露AbstractDataList的內(nèi)部存儲(chǔ)細(xì)節(jié)，向子類公開自己的私有屬性，否則子類無法實(shí)施對(duì)數(shù)據(jù)的遍歷，這將破壞AbstractDataList類的封裝性。迭代器模式的應(yīng)用案例實(shí)例類圖商品交易系統(tǒng)數(shù)據(jù)遍歷結(jié)構(gòu)圖2025/2/138:39迭代器模式的應(yīng)用案例實(shí)例代碼(1)AbstractDataList：抽象聚合類(2)StuffList：具體聚合類(3)AbstractIterator：抽象迭代器(4)StuffIterator：商品迭代器，充當(dāng)具體迭代器迭代器模式的應(yīng)用案例結(jié)果及分析如果需要增加一個(gè)新的具體聚合類，只需增加一個(gè)新的聚合子類和一個(gè)新的具體迭代器類即可，原有類庫(kù)代碼無須修改，符合開閉原則如果需要更換一個(gè)迭代器，只需要增加一個(gè)新的具體迭代器類作為抽象迭代器類的子類，重新實(shí)現(xiàn)遍歷方法即可，原有迭代器代碼無須修改，也符合開閉原則如果要在迭代器中增加新的方法，則需要修改抽象迭代器的源代碼，這將違背開閉原則迭代器模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)支持以不同的方式遍歷一個(gè)聚合對(duì)象，在同一個(gè)聚合對(duì)象上可以定義多種遍歷方式簡(jiǎn)化了聚合類由于引入了抽象層，增加新的聚合類和迭代器類都很方便，無須修改原有代碼，符合開閉原則迭代器模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)在增加新的聚合類時(shí)需要對(duì)應(yīng)地增加新的迭代器類，類的個(gè)數(shù)成對(duì)增加，這在一定程度上增加了系統(tǒng)的復(fù)雜性抽象迭代器的設(shè)計(jì)難度較大，需要充分考慮到系統(tǒng)將來的擴(kuò)展。在自定義迭代器時(shí)，創(chuàng)建一個(gè)考慮全面的抽象迭代器并不是一件很容易的事情迭代器模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境訪問一個(gè)聚合對(duì)象的內(nèi)容而無須暴露它的內(nèi)部表示需要為一個(gè)聚合對(duì)象提供多種遍歷方式為遍歷不同的聚合結(jié)構(gòu)提供一個(gè)統(tǒng)一的接口，在該接口的實(shí)現(xiàn)類中為不同的聚合結(jié)構(gòu)提供不同的遍歷方式，而客戶端可以一致性地操作該接口8.5觀察者模式交通信號(hào)燈與汽車示意圖觀察者模式概述分析交通信號(hào)燈

觀察目標(biāo)汽車（汽車駕駛員）

觀察者一對(duì)多觀察者模式概述分析軟件系統(tǒng)：一個(gè)對(duì)象的狀態(tài)或行為的變化將導(dǎo)致其他對(duì)象的狀態(tài)或行為也發(fā)生改變，它們之間將產(chǎn)生聯(lián)動(dòng)觀察者模式：定義了對(duì)象之間一種一對(duì)多的依賴關(guān)系，讓一個(gè)對(duì)象的改變能夠影響其他對(duì)象發(fā)生改變的對(duì)象稱為觀察目標(biāo)，被通知的對(duì)象稱為觀察者一個(gè)觀察目標(biāo)可以對(duì)應(yīng)多個(gè)觀察者觀察者模式概述觀察者模式的定義對(duì)象行為型模式觀察者模式：定義對(duì)象之間的一種一對(duì)多依賴關(guān)系，使得每當(dāng)一個(gè)對(duì)象狀態(tài)發(fā)生改變時(shí)，其相關(guān)依賴對(duì)象都得到通知并被自動(dòng)更新。觀察者模式概述觀察者模式的定義別名發(fā)布-訂閱(Publish/Subscribe)模式模型-視圖(Model/View)模式源-監(jiān)聽器(Source/Listener)模式從屬者(Dependents)模式觀察者模式的原理與框架觀察者模式的結(jié)構(gòu)58觀察者模式的原理與框架觀察者模式的結(jié)構(gòu)觀察者模式包含以下4個(gè)角色：Subject（目標(biāo)）ConcreteSubject（具體目標(biāo)）Observer（觀察者）ConcreteObserver（具體觀察者）08:39:3059觀察者模式的原理與框架觀察者模式的實(shí)現(xiàn)說明：有時(shí)候在具體觀察者類ConcreteObserver中需要使用到具體目標(biāo)類ConcreteSubject中的狀態(tài)（屬性），會(huì)存在關(guān)聯(lián)或依賴關(guān)系如果在具體層之間具有關(guān)聯(lián)關(guān)系，系統(tǒng)的擴(kuò)展性將受到一定的影響，增加新的具體目標(biāo)類有時(shí)候需要修改原有觀察者的代碼，在一定程度上違背了開閉原則，但是如果原有觀察者類無須關(guān)聯(lián)新增的具體目標(biāo)，則系統(tǒng)擴(kuò)展性不受影響觀察者模式的應(yīng)用案例-地圖應(yīng)用中道路擁堵通知功能的設(shè)計(jì)實(shí)例說明某軟件公司欲開發(fā)一款地圖應(yīng)用(類似于谷歌地圖、百度地圖等)。在此地圖應(yīng)用中，用戶可以查看當(dāng)前路段的擁堵情況。地圖應(yīng)用會(huì)及時(shí)關(guān)注目標(biāo)路段車輛的行駛速度，在注意到當(dāng)前路段車輛行駛緩慢的擁堵情況之后，會(huì)向正準(zhǔn)備經(jīng)過這段路的各位用戶發(fā)送擁堵通知，提醒用戶及時(shí)調(diào)整行車路線。開發(fā)人員需要提供一個(gè)設(shè)計(jì)方案來現(xiàn)實(shí)道路擁堵通知功能。觀察者模式的應(yīng)用案例實(shí)例分析及類圖開發(fā)人員通過對(duì)系統(tǒng)功能需求進(jìn)行分析，發(fā)現(xiàn)在該應(yīng)用中道路擁堵通知過程：路段車輛行駛緩慢→發(fā)送道路擁堵通知→后續(xù)車輛接收道路擁堵通知觀察者模式的應(yīng)用案例實(shí)例分析及類圖道路擁堵通知功能結(jié)構(gòu)圖觀察者模式的應(yīng)用案例實(shí)例代碼(1)ApplicationBackground：抽象目標(biāo)類(2)ConcreteApplicationBackground：具體目標(biāo)類(3)Observer：抽象觀察者類(4)Car：充當(dāng)具體觀察者類64觀察者模式的應(yīng)用案例結(jié)果及分析兩次對(duì)象之間的聯(lián)動(dòng)，觸發(fā)鏈：

Car.beStuck()→ApplicationBackground.notifyObserver()→Car.adjust()08:39:3065觀察者模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)可以實(shí)現(xiàn)表示層和數(shù)據(jù)邏輯層的分離在觀察目標(biāo)和觀察者之間建立一個(gè)抽象的耦合支持廣播通信，簡(jiǎn)化了一對(duì)多系統(tǒng)設(shè)計(jì)的難度符合開閉原則，增加新的具體觀察者無須修改原有系統(tǒng)代碼，在具體觀察者與觀察目標(biāo)之間不存在關(guān)聯(lián)關(guān)系的情況下，增加新的觀察目標(biāo)也很方便觀察者模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)將所有的觀察者都通知到會(huì)花費(fèi)很多時(shí)間如果存在循環(huán)依賴時(shí)可能導(dǎo)致系統(tǒng)崩潰沒有相應(yīng)的機(jī)制讓觀察者知道所觀察的目標(biāo)對(duì)象是怎么發(fā)生變化的，而只是知道觀察目標(biāo)發(fā)生了變化觀察者模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境一個(gè)抽象模型有兩個(gè)方面，其中一個(gè)方面依賴于另一個(gè)方面，將這兩個(gè)方面封裝在獨(dú)立的對(duì)象中使它們可以各自獨(dú)立地改變和復(fù)用一個(gè)對(duì)象的改變將導(dǎo)致一個(gè)或多個(gè)其他對(duì)象發(fā)生改變，且并不知道具體有多少對(duì)象將發(fā)生改變，也不知道這些對(duì)象是誰需要在系統(tǒng)中創(chuàng)建一個(gè)觸發(fā)鏈8.6中介者模式QQ聊天示意圖中介者模式概述分析QQ聊天的兩種方式：(1)用戶與用戶直接聊天，用戶與用戶之間存在多對(duì)多的聯(lián)系，這將導(dǎo)致系統(tǒng)中用戶之間的關(guān)系非常復(fù)雜，一個(gè)用戶如果要將相同的信息或文件發(fā)送給其他所有用戶，必須一個(gè)一個(gè)地發(fā)送(2)通過QQ群聊天，用戶只需要將信息或文件發(fā)送到群中或上傳為群共享文件即可，群的作用就是將發(fā)送者所發(fā)送的信息和文件轉(zhuǎn)發(fā)給每一個(gè)接收者，將極大地減少系統(tǒng)中用戶之間的兩兩通信中介者模式概述分析軟件開發(fā)：網(wǎng)狀結(jié)構(gòu)：多對(duì)多聯(lián)系將導(dǎo)致系統(tǒng)非常復(fù)雜，幾乎每個(gè)對(duì)象都需要與其他對(duì)象發(fā)生相互作用，而這種相互作用表現(xiàn)為一個(gè)對(duì)象與另外一個(gè)對(duì)象的直接耦合，這將導(dǎo)致一個(gè)過度耦合的系統(tǒng)網(wǎng)狀結(jié)構(gòu)中介者模式概述分析軟件開發(fā)：星型結(jié)構(gòu)：中介者模式將系統(tǒng)的網(wǎng)狀結(jié)構(gòu)變成以中介者為中心的星型結(jié)構(gòu)，同事對(duì)象不再直接與另一個(gè)對(duì)象聯(lián)系，它通過中介者對(duì)象與另一個(gè)對(duì)象發(fā)生相互作用。系統(tǒng)的結(jié)構(gòu)不會(huì)因?yàn)樾聦?duì)象的引入帶來大量的修改工作星型結(jié)構(gòu)中介者模式的定義對(duì)象行為型模式中介者模式：定義一個(gè)對(duì)象來封裝一系列對(duì)象的交互。中介者模式使各對(duì)象之間不需要顯式地相互引用，從而使其耦合松散，而且讓你可以獨(dú)立地改變它們之間的交互。中介者模式概述中介者模式的定義又稱為調(diào)停者模式在中介者模式中，通過引入中介者來簡(jiǎn)化對(duì)象之間的復(fù)雜交互中介者模式是迪米特法則的一個(gè)典型應(yīng)用對(duì)象之間多對(duì)多的復(fù)雜關(guān)系轉(zhuǎn)化為相對(duì)簡(jiǎn)單的一對(duì)多關(guān)系中介者模式的原理與框架中介者模式的結(jié)構(gòu)中介者模式的原理與框架中介者模式的結(jié)構(gòu)中介者模式包含以下4個(gè)角色：Mediator（抽象中介者）ConcreteMediator（具體中介者）Colleague（抽象同事類）ConcreteColleague（具體同事類）08:39:3076中介者模式的原理與框架中介者模式的實(shí)現(xiàn)中介者類的職責(zé)中轉(zhuǎn)作用（結(jié)構(gòu)性）：各個(gè)同事對(duì)象不再需要顯式地引用其他同事，當(dāng)需要和其他同事進(jìn)行通信時(shí)，可通過中介者來實(shí)現(xiàn)間接調(diào)用協(xié)調(diào)作用（行為性）：中介者可以更進(jìn)一步的對(duì)同事之間的關(guān)系進(jìn)行封裝，同事可以一致地和中介者進(jìn)行交互，而不需要指明中介者需要具體怎么做，中介者根據(jù)封裝在自身內(nèi)部的協(xié)調(diào)邏輯對(duì)同事的請(qǐng)求進(jìn)行進(jìn)一步處理，將同事成員之間的關(guān)系行為進(jìn)行分離和封裝中介者模式的應(yīng)用案例實(shí)例說明某軟件公司欲開發(fā)一套學(xué)生信息管理系統(tǒng)，其中包含一個(gè)學(xué)生信息管理模塊，所設(shè)計(jì)的“學(xué)生信息管理窗口”界面效果圖如下圖所示：

通過分析發(fā)現(xiàn)，在上圖中，界面組件之間存在較為復(fù)雜的交互關(guān)系：如果刪除一個(gè)學(xué)生，要在學(xué)生列表(List)中刪掉對(duì)應(yīng)的項(xiàng)，學(xué)生選擇組合框(ComboBox)中學(xué)生名稱也將減少一個(gè)；如果增加一個(gè)學(xué)生信息，學(xué)生列表中需增加一個(gè)學(xué)生，且組合框中也將增加一項(xiàng)?！皩W(xué)生信息管理窗口”原始結(jié)構(gòu)圖該設(shè)計(jì)方案存在的問題(1)系統(tǒng)結(jié)構(gòu)復(fù)雜且耦合度高：每一個(gè)界面組件都與其他多個(gè)組件之間產(chǎn)生相互關(guān)聯(lián)和調(diào)用，若一個(gè)界面組件對(duì)象發(fā)生變化，需要跟蹤與之有關(guān)聯(lián)的其他所有組件并進(jìn)行處理，系統(tǒng)組件之間呈現(xiàn)一種較為復(fù)雜的網(wǎng)狀結(jié)構(gòu)，組件之間的耦合度高。(2)組件的可重用性差：每一個(gè)組件和其他組件之間都具有很強(qiáng)的關(guān)聯(lián)，若沒有其他組件的支持，一個(gè)組件很難被另一個(gè)系統(tǒng)或模塊重用，這些組件表現(xiàn)出來更像一個(gè)不可分割的整體，而在實(shí)際使用時(shí)，我們往往需要每一個(gè)組件都能夠單獨(dú)重用，而不是重用一個(gè)由多個(gè)組件組成的復(fù)雜結(jié)構(gòu)。(3)系統(tǒng)的可擴(kuò)展性差：如果在上述系統(tǒng)中增加一個(gè)新的組件類，則必須修改與之交互的其他組件類的源代碼，將導(dǎo)致多個(gè)類的源代碼需要修改，同樣，如果要?jiǎng)h除一個(gè)組件也存在類似的問題，這違反了開閉原則，可擴(kuò)展性和靈活性欠佳。使用中介者模式來設(shè)計(jì)學(xué)生信息管理窗口實(shí)例分析及類圖引入了中介者類的“學(xué)生信息管理窗口”結(jié)構(gòu)示意圖81使用中介者模式來設(shè)計(jì)學(xué)生信息管理窗口-重構(gòu)實(shí)例分析及類圖重構(gòu)后的“學(xué)生信息管理窗口”結(jié)構(gòu)圖使用中介者模式來設(shè)計(jì)學(xué)生信息管理窗口-重構(gòu)實(shí)例代碼Student充當(dāng)抽象類Button、List、ComboBox和TextBox充當(dāng)具體同事類Mediator充當(dāng)抽象中介者類ConcreteMediator充當(dāng)具體中介者類ConcreteMediator維持了對(duì)具體同事類的引用為了簡(jiǎn)化ConcreteMediator類的代碼，只定義了一個(gè)Button對(duì)象和一個(gè)TextBox對(duì)象使用中介者模式來設(shè)計(jì)學(xué)生信息管理窗口-重構(gòu)結(jié)果及分析當(dāng)某個(gè)組件類的update()方法被調(diào)用時(shí)，中介者的componentChanged()方法將被調(diào)用，在中介者的componentChanged()方法中再逐個(gè)調(diào)用與該組件有交互的其他組件的相關(guān)方法如果某個(gè)組件類需要與新的組件進(jìn)行交互，無須修改已有組件類的源代碼，只需修改中介者或者對(duì)現(xiàn)有中介者進(jìn)行擴(kuò)展即可，系統(tǒng)具有更好的靈活性和可擴(kuò)展性中介者模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)簡(jiǎn)化了對(duì)象之間的交互，它用中介者和同事的一對(duì)多交互代替了原來同事之間的多對(duì)多交互，將原本難以理解的網(wǎng)狀結(jié)構(gòu)轉(zhuǎn)換成相對(duì)簡(jiǎn)單的星型結(jié)構(gòu)可將各同事對(duì)象解耦可以減少子類生成，中介者模式將原本分布于多個(gè)對(duì)象間的行為集中在一起，改變這些行為只需生成新的中介者子類即可，這使得各個(gè)同事類可被重用，無須直接對(duì)同事類進(jìn)行擴(kuò)展中介者模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)在具體中介者類中包含了大量的同事之間的交互細(xì)節(jié)，可能會(huì)導(dǎo)致具體中介者類非常復(fù)雜，使得系統(tǒng)難以維護(hù)中介者模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境系統(tǒng)中對(duì)象之間存在復(fù)雜的引用關(guān)系，系統(tǒng)結(jié)構(gòu)混亂且難以理解一個(gè)對(duì)象由于引用了其他很多對(duì)象并且直接和這些對(duì)象通信，導(dǎo)致難以復(fù)用該對(duì)象想通過一個(gè)中間類來封裝多個(gè)類中的行為，又不想生成太多的子類8.7備忘錄模式概述備忘錄模式——軟件中的“后悔藥”——撤銷(Undo)備忘錄模式概述分析通過使用備忘錄模式可以讓系統(tǒng)恢復(fù)到某一特定的歷史狀態(tài)首先保存軟件系統(tǒng)的歷史狀態(tài)，當(dāng)用戶需要取消錯(cuò)誤操作并且返回到某個(gè)歷史狀態(tài)時(shí)，可以取出事先保存的歷史狀態(tài)來覆蓋當(dāng)前狀態(tài)備忘錄模式概述備忘錄模式的定義對(duì)象行為型模式備忘錄模式：在不破壞封裝的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)，這樣就可以在以后將對(duì)象恢復(fù)到原先保存的狀態(tài)。備忘錄模式概述備忘錄模式的定義別名為標(biāo)記(Token)模式提供了一種狀態(tài)恢復(fù)的實(shí)現(xiàn)機(jī)制，使得用戶可以方便地回到一個(gè)特定的歷史步驟當(dāng)前在很多軟件所提供的撤銷(Undo)操作中就使用了備忘錄模式備忘錄模式的原理與框架備忘錄模式的結(jié)構(gòu)備忘錄模式的原理與框架備忘錄模式的結(jié)構(gòu)備忘錄模式包含以下3個(gè)角色：Originator（原發(fā)器）Memento（備忘錄)Caretaker（負(fù)責(zé)人）備忘錄模式的原理與框架備忘錄模式的實(shí)現(xiàn)除了Originator類，不允許其他類來調(diào)用備忘錄類Memento的構(gòu)造函數(shù)與相關(guān)方法如果允許其他類調(diào)用SetState()等方法，將導(dǎo)致在備忘錄中保存的歷史狀態(tài)發(fā)生改變，通過撤銷操作所恢復(fù)的狀態(tài)就不再是真實(shí)的歷史狀態(tài)，備忘錄模式也就失去了本身的意義

理想的情況是只允許生成該備忘錄的原發(fā)器訪問備忘錄的內(nèi)部狀態(tài)備忘錄模式的應(yīng)用案例實(shí)例說明某軟件公司欲開發(fā)一款可以運(yùn)行在Android平臺(tái)的觸摸式國(guó)際象棋軟件，由于考慮到有些用戶是新手，經(jīng)常不小心走錯(cuò)棋；還有些用戶因?yàn)椴涣?xí)慣使用手指在手機(jī)屏幕上拖動(dòng)棋子，常常出現(xiàn)操作失誤，因此需要為該象棋軟件提供“悔棋”功能，用戶走錯(cuò)棋或操作失誤后可恢復(fù)到前一個(gè)步驟。如下圖所示：為了實(shí)現(xiàn)“悔棋”功能，現(xiàn)使用備忘錄模式來設(shè)計(jì)該中國(guó)象棋軟件。撤銷功能的實(shí)現(xiàn)原理在實(shí)現(xiàn)撤銷時(shí)，首先必須保存軟件系統(tǒng)的歷史狀態(tài)，當(dāng)用戶需要取消錯(cuò)誤操作并且返回到某個(gè)歷史狀態(tài)時(shí)，可以取出事先保存的歷史狀態(tài)來覆蓋當(dāng)前狀態(tài)備忘錄模式的應(yīng)用案例實(shí)例類圖國(guó)際象棋棋子撤銷功能結(jié)構(gòu)圖備忘錄模式的應(yīng)用案例實(shí)例代碼(1)Chessman：象棋棋子類，充當(dāng)原發(fā)器(2)ChessmanMemento：象棋棋子備忘錄類，充當(dāng)備忘錄(3)MementoCaretaker：象棋棋子備忘錄管理類，充當(dāng)負(fù)責(zé)人備忘錄模式的應(yīng)用案例結(jié)果及分析通過創(chuàng)建備忘錄對(duì)象可以將象棋棋子的歷史狀態(tài)信息記錄下來，在“悔棋”時(shí)取出存儲(chǔ)在備忘錄中的歷史狀態(tài)信息，用歷史狀態(tài)來覆蓋當(dāng)前狀態(tài)，從而實(shí)現(xiàn)狀態(tài)的撤銷備忘錄模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)提供了一種狀態(tài)恢復(fù)的實(shí)現(xiàn)機(jī)制，使得用戶可以方便地回到一個(gè)特定的歷史步驟實(shí)現(xiàn)了對(duì)信息的封裝，一個(gè)備忘錄對(duì)象是一種原發(fā)器對(duì)象狀態(tài)的表示，不會(huì)被其他代碼所改動(dòng)備忘錄模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)資源消耗過大，如果需要保存的原發(fā)器類的成員變量太多，就不可避免地需要占用大量的存儲(chǔ)空間，每保存一次對(duì)象的狀態(tài)都需要消耗一定的系統(tǒng)資源備忘錄模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境保存一個(gè)對(duì)象在某一個(gè)時(shí)刻的全部狀態(tài)或部分狀態(tài)，這樣以后需要時(shí)能夠恢復(fù)到先前的狀態(tài)，實(shí)現(xiàn)撤銷操作防止外界對(duì)象破壞一個(gè)對(duì)象歷史狀態(tài)的封裝性，避免將對(duì)象歷史狀態(tài)的實(shí)現(xiàn)細(xì)節(jié)暴露給外界對(duì)象8.8解釋器模式加法/減法解釋器示意圖解釋器模式概述分析C#語言無法直接解釋類似“1+2+3–4+1”這樣的字符串定義一套文法規(guī)則來實(shí)現(xiàn)對(duì)這些語句的解釋，即設(shè)計(jì)一個(gè)自定義語言基于現(xiàn)有的編程語言

面向?qū)ο缶幊陶Z言

解釋器模式解釋器模式概述解釋器模式的定義類行為型模式解釋器模式：給定一個(gè)語言，定義它的文法的一種表示，并定義一個(gè)解釋器，這個(gè)解釋器使用該表示來解釋語言中的句子。解釋器模式概述解釋器模式的定義在解釋器模式的定義中所指的“語言”是使用規(guī)定格式和語法的代碼是一種使用頻率相對(duì)較低但學(xué)習(xí)難度相對(duì)較大的設(shè)計(jì)模式，用于描述如何使用面向?qū)ο笳Z言構(gòu)成一個(gè)簡(jiǎn)單的語言解釋器能夠加深對(duì)面向?qū)ο笏枷氲睦斫猓⑶依斫饩幊陶Z言中文法規(guī)則的解釋過程文法規(guī)則和抽象語法樹文法規(guī)則1+2+3–4+1“::=”表示“定義為”“|”表示“或”“{”和“}”表示“組合”“*”表示“出現(xiàn)0次或多次”expression::=value|operationoperation::=expression'+'expression|expression'-'expressionvalue::=aninteger//一個(gè)整數(shù)值文法規(guī)則和抽象語法樹抽象語法樹抽象語法樹(AbstractSyntaxTree,AST)描述了如何構(gòu)成一個(gè)復(fù)雜的句子，通過對(duì)抽象語法樹的分析，可以識(shí)別出語言中的終結(jié)符類和非終結(jié)符類非終結(jié)符表達(dá)式終結(jié)符表達(dá)式解釋器模式的原理與框架解釋器模式的結(jié)構(gòu)解釋器模式的原理與框架解釋器模式的結(jié)構(gòu)解釋器模式包含以下4個(gè)角色：AbstractExpression（抽象表達(dá)式）TerminalExpression（終結(jié)符表達(dá)式）NonterminalExpression（非終結(jié)符表達(dá)式）Context（環(huán)境類）解釋器模式的原理與框架解釋器模式的實(shí)現(xiàn)環(huán)境類Context：用于存儲(chǔ)一些全局信息，一般包含一個(gè)Hashtable或List等類型的集合對(duì)象（也可以直接由Hashtable等集合類充當(dāng)環(huán)境類），存儲(chǔ)一系列公共信息，例如變量名與值的映射關(guān)系(key/value)等，用于在執(zhí)行具體的解釋操作時(shí)從中獲取相關(guān)信息可以在環(huán)境類中增加一些所有表達(dá)式解釋器都共有的功能，以減輕解釋器的職責(zé)當(dāng)系統(tǒng)無須提供全局公共信息時(shí)可以省略環(huán)境類，根據(jù)實(shí)際情況決定是否需要環(huán)境類解釋器模式的應(yīng)用案例實(shí)例說明某軟件公司要為某勘測(cè)企業(yè)開發(fā)一套R(shí)OS(RobotOperatingSystem)小車控制程序，在該ROS小車控制程序中包含了一些簡(jiǎn)單的英文控制指令，每一個(gè)指令對(duì)應(yīng)一個(gè)表達(dá)式(expression)，該表達(dá)式可以是簡(jiǎn)單表達(dá)式也可以是復(fù)合表達(dá)式，每一個(gè)簡(jiǎn)單表達(dá)式由移動(dòng)方向(direction)、移動(dòng)方式(action)和移動(dòng)距離(distance)三部分組成，其中移動(dòng)方向包括上(up)、下(down)、左(left)、右(right)；移動(dòng)方式包括移動(dòng)(move)和快速移動(dòng)(run)；移動(dòng)距離為一個(gè)正整數(shù)。兩個(gè)表達(dá)式之間可以通過與(and)連接形成復(fù)合(composite)表達(dá)式。用戶通過對(duì)圖形化的設(shè)置界面進(jìn)行操作可以創(chuàng)建一個(gè)機(jī)器人控制指令，機(jī)器人在收到指令后將按照指令的設(shè)置進(jìn)行移動(dòng)，例如輸入控制指令：upmove5，則“向上移動(dòng)5個(gè)單位”；輸入控制指令：downrun10andleftmove20，則“向下快速移動(dòng)10個(gè)單位再向左移動(dòng)20個(gè)單位”。現(xiàn)使用解釋器模式來設(shè)計(jì)該程序并模擬實(shí)現(xiàn)。解釋器模式的應(yīng)用案例實(shí)例分析及類圖文法規(guī)則終結(jié)符表達(dá)式direction、action和distance對(duì)應(yīng)DirectionNode類、ActionNode類和DistanceNode類非終結(jié)符表達(dá)式expression和composite對(duì)應(yīng)SentenceNode類和AndNode類expression::=directionactiondistance|composite//表達(dá)式composite::=expression'and'expression//復(fù)合表達(dá)式direction::='up'|'down'|'left'|'right'//移動(dòng)方向action::='move'|'run'//移動(dòng)方式distance::=aninteger//移動(dòng)距離解釋器模式的應(yīng)用案例實(shí)例分析及類圖抽象語法樹downrun10andleftmove20解釋器模式的應(yīng)用案例實(shí)例分析及類圖ROS小車控制程序結(jié)構(gòu)圖解釋器模式的應(yīng)用案例實(shí)例代碼(1)AbstractNode：抽象結(jié)點(diǎn)類，充當(dāng)抽象表達(dá)式角色(2)AndNode：And結(jié)點(diǎn)類，充當(dāng)非終結(jié)符表達(dá)式角色(3)SentenceNode：簡(jiǎn)單句子結(jié)點(diǎn)類，充當(dāng)非終結(jié)符表達(dá)式角色(4)DirectionNode：方向結(jié)點(diǎn)類，充當(dāng)終結(jié)符表達(dá)式角色(5)ActionNode：動(dòng)作結(jié)點(diǎn)類，充當(dāng)終結(jié)符表達(dá)式角色(6)DistanceNode：距離結(jié)點(diǎn)類，充當(dāng)終結(jié)符表達(dá)式角色(7)InstructionHandler：指令處理類，工具類解釋器模式的應(yīng)用案例結(jié)果及分析downrun10andleftmove20向下快速移動(dòng)10再向左移動(dòng)20upmove5anddownrun10andleftmove5向上移動(dòng)5再向下快速移動(dòng)10再向左移動(dòng)5解釋器模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)易于改變和擴(kuò)展文法可以方便地實(shí)現(xiàn)一個(gè)簡(jiǎn)單的語言實(shí)現(xiàn)文法較為容易（有自動(dòng)生成工具）增加新的解釋表達(dá)式較為方便解釋器模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)對(duì)于復(fù)雜文法難以維護(hù)執(zhí)行效率較低解釋器模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境可以將一個(gè)需要解釋執(zhí)行的語言中的句子表示為一棵抽象語法樹一些重復(fù)出現(xiàn)的問題可以用一種簡(jiǎn)單的語言來進(jìn)行表達(dá)一個(gè)語言的文法較為簡(jiǎn)單執(zhí)行效率不是關(guān)鍵問題8.8狀態(tài)模式H2O的三種狀態(tài)（未考慮臨界點(diǎn)）狀態(tài)模式概述分析在軟件系統(tǒng)中：有些對(duì)象具有多種狀態(tài)這些狀態(tài)在某些情況下能夠相互轉(zhuǎn)換對(duì)象在不同的狀態(tài)下將具有不同的行為復(fù)雜的條件判斷語句來進(jìn)行狀態(tài)的判斷和轉(zhuǎn)換操作

導(dǎo)致代碼的可維護(hù)性和靈活性下降

出現(xiàn)新的狀態(tài)時(shí)，代碼的擴(kuò)展性很差，客戶端代碼也需要進(jìn)行相應(yīng)的修改，違背了開閉原則classTestXYZ{intbehaviour;//GetterandSetter......publicvoidHandleAll(){if(behaviour==0){//dosomething}elseif(behaviour==1){//dosomething}elseif(behaviour==2){//dosomething}elseif(behaviour==3){//dosomething}...somemoreelseif...}}狀態(tài)模式概述狀態(tài)模式的定義對(duì)象行為型模式狀態(tài)模式：允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來似乎修改了它的類。狀態(tài)模式概述狀態(tài)模式的定義又名狀態(tài)對(duì)象(ObjectsforStates)用于解決系統(tǒng)中復(fù)雜對(duì)象的狀態(tài)轉(zhuǎn)換以及不同狀態(tài)下行為的封裝問題將一個(gè)對(duì)象的狀態(tài)從該對(duì)象中分離出來，封裝到專門的狀態(tài)類中，使得對(duì)象狀態(tài)可以靈活變化對(duì)于客戶端而言，無須關(guān)心對(duì)象狀態(tài)的轉(zhuǎn)換以及對(duì)象所處的當(dāng)前狀態(tài)，無論對(duì)于何種狀態(tài)的對(duì)象，客戶端都可以一致處理狀態(tài)模式的原理與框架狀態(tài)模式的結(jié)構(gòu)狀態(tài)模式的原理與框架狀態(tài)模式的結(jié)構(gòu)狀態(tài)模式包含以下3個(gè)角色：Context（環(huán)境類）State（抽象狀態(tài)類）ConcreteState（具體狀態(tài)類）狀態(tài)模式的應(yīng)用案例實(shí)例說明某軟件公司欲開發(fā)一套購(gòu)物網(wǎng)站的后臺(tái)系統(tǒng)，商品管理(Goods)是該系統(tǒng)的核心類之一。通過分析，該軟件公司開發(fā)人員發(fā)現(xiàn)在該系統(tǒng)中，商品根據(jù)庫(kù)存量的不同存在三種狀態(tài)，且在不同狀態(tài)下商品存在不同的行為，具體說明如下：(1)如果商品的庫(kù)存量大于等于10%，則商品的狀態(tài)為庫(kù)存充足狀態(tài)(SufficientState)，此時(shí)用戶可以任意購(gòu)買數(shù)量小于庫(kù)存量的商品。(2)如果商品的庫(kù)存量小于10%，并且大于0，則商品的狀態(tài)為庫(kù)存緊張狀態(tài)(TensionState)，此時(shí)用戶仍然可以購(gòu)買數(shù)量小于庫(kù)存量的商品，同時(shí)需要提醒商家補(bǔ)充庫(kù)存。(3)如果商品的庫(kù)存量等于0，那么商品的狀態(tài)為已售罄狀態(tài)(SoldOutState)，此時(shí)用戶不能再購(gòu)買該商品，提醒商家下架該商品或補(bǔ)充庫(kù)存。(4)根據(jù)商品庫(kù)存量的不同，以上三種狀態(tài)可發(fā)生相互轉(zhuǎn)換?，F(xiàn)使用狀態(tài)模式設(shè)計(jì)并實(shí)現(xiàn)銀行賬戶狀態(tài)的轉(zhuǎn)換。狀態(tài)模式的應(yīng)用案例實(shí)例分析與類圖商品庫(kù)存量狀態(tài)圖狀態(tài)模式的應(yīng)用案例實(shí)例分析與類圖商品類結(jié)構(gòu)圖狀態(tài)模式的應(yīng)用案例實(shí)例代碼(1)Goods：環(huán)境類(2)GoodsState：抽象狀態(tài)角色(3)SufficientState：正常狀態(tài)類，充當(dāng)具體狀態(tài)角色(4)SoldOutState：脫銷狀態(tài)類，充當(dāng)具體狀態(tài)角色(5)TensionState：受限狀態(tài)類，充當(dāng)具體狀態(tài)角色(6)Program：客戶端測(cè)試類狀態(tài)模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)封裝了狀態(tài)的轉(zhuǎn)換規(guī)則，可以對(duì)狀態(tài)轉(zhuǎn)換代碼進(jìn)行集中管理，而不是分散在一個(gè)個(gè)業(yè)務(wù)方法中將所有與某個(gè)狀態(tài)有關(guān)的行為放到一個(gè)類中，只需要注入一個(gè)不同的狀態(tài)對(duì)象即可使環(huán)境對(duì)象擁有不同的行為允許狀態(tài)轉(zhuǎn)換邏輯與狀態(tài)對(duì)象合成一體，而不是提供一個(gè)巨大的條件語句塊，可以避免使用龐大的條件語句來將業(yè)務(wù)方法和狀態(tài)轉(zhuǎn)換代碼交織在一起可以讓多個(gè)環(huán)境對(duì)象共享一個(gè)狀態(tài)對(duì)象，從而減少系統(tǒng)中對(duì)象的個(gè)數(shù)狀態(tài)模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)會(huì)增加系統(tǒng)中類和對(duì)象的個(gè)數(shù)，導(dǎo)致系統(tǒng)運(yùn)行開銷增大原理與框架都較為復(fù)雜，如果使用不當(dāng)將導(dǎo)致程序結(jié)構(gòu)和代碼混亂，增加系統(tǒng)設(shè)計(jì)的難度對(duì)開閉原則的支持并不太好，增加新的狀態(tài)類需要修改負(fù)責(zé)狀態(tài)轉(zhuǎn)換的源代碼，否則無法轉(zhuǎn)換到新增狀態(tài)；而且修改某個(gè)狀態(tài)類的行為也需要修改對(duì)應(yīng)類的源代碼狀態(tài)模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境對(duì)象的行為依賴于它的狀態(tài)（例如某些屬性值），狀態(tài)的改變將導(dǎo)致行為的變化在代碼中包含大量與對(duì)象狀態(tài)有關(guān)的條件語句，這些條件語句的出現(xiàn)會(huì)導(dǎo)致代碼的可維護(hù)性和靈活性變差，不能方便地增加和刪除狀態(tài)，并且導(dǎo)致客戶類與類庫(kù)之間的耦合增強(qiáng)8.10策略模式旅游出行方式示意圖策略模式概述分析實(shí)現(xiàn)某個(gè)目標(biāo)的途徑不止一條，可根據(jù)實(shí)際情況選擇一條合適的途徑軟件開發(fā)：多種算法，例如排序、查找、打折等使用硬編碼(HardCoding)實(shí)現(xiàn)將導(dǎo)致系統(tǒng)違背開閉原則，擴(kuò)展性差，且維護(hù)困難可以定義一些獨(dú)立的類來封裝不同的算法，每一個(gè)類封裝一種具體的算法

策略類08:39:30135策略模式概述策略模式的定義對(duì)象行為型模式策略模式：定義一系列算法，將每一個(gè)算法封裝起來，并讓它們可以相互替換。策略模式讓算法可以獨(dú)立于使用它的客戶變化。策略模式概述策略模式的定義又稱為政策(Policy)模式每一個(gè)封裝算法的類稱之為策略(Strategy)類策略模式提供了一種可插入式(Pluggable)算法的實(shí)現(xiàn)方案策略模式的原理與框架策略模式的結(jié)構(gòu)策略模式的原理與框架策略模式的結(jié)構(gòu)策略模式包含以下3個(gè)角色：Context（環(huán)境類）Strategy（抽象策略類）ConcreteStrategy（具體策略類）策略模式的應(yīng)用案例實(shí)例說明某軟件公司為某景區(qū)開發(fā)了一套景區(qū)門票打折方案，在該系統(tǒng)中需要為不同類型的用戶提供不同的景區(qū)票打折方式，具體打折方案如下：(1)學(xué)生憑學(xué)生證可享受票價(jià)5折優(yōu)惠。(2)年齡在12周歲及以下的兒童可享受免門票優(yōu)惠。(3)景區(qū)VIP用戶除享受票價(jià)半價(jià)優(yōu)惠外還可獲得積分，積分累計(jì)到一定額度可換取免費(fèi)門票。該系統(tǒng)在將來可能還需要根據(jù)景區(qū)的活動(dòng)，引入新的優(yōu)惠折扣方式。策略模式的應(yīng)用案例實(shí)例類圖景區(qū)門票打折方案結(jié)構(gòu)圖策略模式的應(yīng)用案例實(shí)例代碼(1)Ticket：門票類，充當(dāng)環(huán)境類(2)Discount：折扣類，充當(dāng)抽象策略類(3)StudentDiscount：學(xué)生票折扣類，充當(dāng)具體策略類(4)ChildrenDiscount：兒童票折扣類，充當(dāng)具體策略類(5)VIPDiscount：VIP會(huì)員票折扣類，充當(dāng)具體策略類策略模式的應(yīng)用案例結(jié)果及分析如果需要更換具體策略類，無須修改源代碼，只需修改配置文件即可，完全符合開閉原則<?xmlversion="1.0"encoding="utf-8"?><configuration><appSettings><addkey="discountType"value="StrategySample.ChildrenDiscount"/></appSettings></configuration>策略模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)提供了對(duì)開閉原則的完美支持，用戶可以在不修改原有系統(tǒng)的基礎(chǔ)上選擇算法或行為，也可以靈活地增加新的算法或行為提供了管理相關(guān)的算法族的辦法提供了一種可以替換繼承關(guān)系的辦法可以避免多重條件選擇語句提供了一種算法的復(fù)用機(jī)制，不同的環(huán)境類可以方便地復(fù)用策略類策略模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)客戶端必須知道所有的策略類，并自行決定使用哪一個(gè)策略類將造成系統(tǒng)產(chǎn)生很多具體策略類無法同時(shí)在客戶端使用多個(gè)策略類策略模式的優(yōu)缺點(diǎn)與適用環(huán)境模式適用環(huán)境一個(gè)系統(tǒng)需要?jiǎng)討B(tài)地在幾種算法中選擇一種避免使用難以維護(hù)的多重條件選擇語句不希望客戶端知道復(fù)雜的、與算法相關(guān)的數(shù)據(jù)結(jié)構(gòu)，提高算法的保密性與安全性8.11模板方法模式請(qǐng)客吃飯示意圖模板方法模式概述分析請(qǐng)客吃飯：(1)點(diǎn)單

(2)吃東西

(3)買單軟件開發(fā)：某個(gè)方法的實(shí)現(xiàn)需要多個(gè)步驟（類似“請(qǐng)客”），其中有些步驟是固定的（類似“點(diǎn)單”和“買單”），而有些步驟并不固定，存在可變性（類似“吃東西”）模板方法模式：基本方法（“點(diǎn)單”、“吃東西”和“買單”）模板方法（“請(qǐng)客”）模板方法模式概述模板方法模式的定義類行為型模式模板方法模式：定義一個(gè)操作中算法的框架，而將一些步驟延遲到子類中。模板方法模式使得子類不改變一個(gè)算法的結(jié)構(gòu)即可重定義該算法的某些特定步驟。模板方法模式概述模板方法模式的定義是一種基于繼承的代碼復(fù)用技術(shù)將一些復(fù)雜流程的實(shí)現(xiàn)步驟封裝在一系列基本方法中在抽象父類中提供一個(gè)稱之為模板方法的方法來定義這些基本方法的執(zhí)行次序，而通過其子類來覆蓋某些步驟，從而使得相同的算法框架可以有不同的執(zhí)行結(jié)果模板方法模式的原理與框架模板方法模式的結(jié)構(gòu)模板方法模式的原理與框架模板方法模式的結(jié)構(gòu)模板方法模式包含以下兩個(gè)角色：AbstractClass（抽象類）ConcreteClass（具體子類）模板方法模式的原理與框架模板方法模式的實(shí)現(xiàn)模板方法(TemplateMethod)基本方法(PrimitiveMethod)抽象方法(AbstractMethod)具體方法(ConcreteMethod)鉤子方法(HookMethod)模板方法模式的原理與框架模板方法模式的實(shí)現(xiàn)鉤子方法(1)“掛鉤”方法：IsXXX()，返回類型為bool類型(2)空方法……//模板方法publicvoidTemplateMethod(){Open();Display();//通過鉤子方法來確定某步驟是否執(zhí)行if(IsPrint()){Print();}}//鉤子方法publicboolIsPrint(){returntrue;}……模板方法模式的原理與框架模板方法模式的實(shí)現(xiàn)抽象類典型代碼：abstractclassAbstractClass{//模板方法publicvoidTemplateMethod(){PrimitiveOperation1();PrimitiveOperation2();PrimitiveOperation3();}//基本方法—具體方法publicvoidPrimitiveOperation1(){//實(shí)現(xiàn)代碼}//基本方法—抽象方法publicabstractvoidPrimitiveOperation2();//基本方法—鉤子方法publicvirtualvoidPrimitiveOperation3(){}}模板方法模式的原理與框架模板方法模式的實(shí)現(xiàn)具體子類典型代碼：classConcreteClass:AbstractClass{publicoverridevoidPrimitiveOperation2(){//實(shí)現(xiàn)代碼}publicoverridevoidPrimitiveOperation3(){//實(shí)現(xiàn)代碼}}模板方法模式的應(yīng)用案例實(shí)例說明某軟件公司欲為某商戶的業(yè)務(wù)支撐系統(tǒng)開發(fā)一個(gè)商品郵費(fèi)計(jì)算模塊，郵費(fèi)計(jì)算流程如下：(1)系統(tǒng)根據(jù)賬號(hào)和密碼驗(yàn)證用戶信息，如果用戶信息錯(cuò)誤，系統(tǒng)顯示出錯(cuò)提示；(2)如果用戶信息正確，則根據(jù)商品目的地址和重量的不同使用不同的郵費(fèi)計(jì)算公式(如江浙滬和其他地區(qū)具有不同的郵費(fèi)計(jì)算標(biāo)準(zhǔn))；(3)系統(tǒng)顯示運(yùn)費(fèi)。試使用模板方法模式設(shè)計(jì)該郵費(fèi)計(jì)算模塊。模板方法模式的應(yīng)用案例實(shí)例類圖商品郵費(fèi)計(jì)算模塊結(jié)構(gòu)圖模板方法模式的應(yīng)用案例實(shí)例類圖商品郵費(fèi)計(jì)算模塊結(jié)構(gòu)圖模板方法模式的應(yīng)用案例實(shí)例代碼(1)ExpressPrice：抽象類(2)SomeProvinces：具體子類(3)OtherProvinces：具體子類模板方法模式的應(yīng)用案例結(jié)果及分析如果需要更換或增加具體子類，無須修改源代碼，只需修改配置文件App.config即可，符合開閉原則模板方法模式的優(yōu)缺點(diǎn)與適用環(huán)境模式優(yōu)點(diǎn)在父類中形式化地定義一個(gè)算法，而由它的子類來實(shí)現(xiàn)細(xì)節(jié)的處理，在子類實(shí)現(xiàn)詳細(xì)的處理算法時(shí)并不會(huì)改變算法中步驟的執(zhí)行次序提取了類庫(kù)中的公共行為，將公共行為放在父類中，而通過其子類來實(shí)現(xiàn)不同的行為可實(shí)現(xiàn)一種反向控制結(jié)構(gòu)，通過子類覆蓋父類的鉤子方法來決定某一特定步驟是否需要執(zhí)行更換和增加新的子類很方便，符合單一職責(zé)原則和開閉原則模板方法模式的優(yōu)缺點(diǎn)與適用環(huán)境模式缺點(diǎn)需要為每一個(gè)基本方法的不同實(shí)現(xiàn)提供一個(gè)子類，如果父類中可變的基本方法太多，將會(huì)導(dǎo)致類的個(gè)數(shù)增加，系統(tǒng)會(huì)更加龐大，設(shè)計(jì)也會(huì)更加抽象（可結(jié)合橋接模式）