第10講：軟件設計模式

1、哈爾濱工業(yè)大學計算機學院唐好選Email:主要內(nèi)容主要內(nèi)容p軟件設計模式基礎p創(chuàng)建型模式p結構型模式p行為型模式軟件設計模式基礎p 廣義講，軟件設計模式是可解決某類軟件問題并能重復使用的軟件設計方案p 狹義講，軟件設計模式是“對特定場景下解決一般設計問題的類和相互通信對象的描述”。是在類和對象的層次描述的可重復使用的軟件設計問題的解決方案p 模式體現(xiàn)程序整體構思，也會出現(xiàn)在分析或概要設計階段 p 模式的核心思想：通過增加抽象層，把變化部分從那些不變部分里分離出來設計模式的概念設計模式的概念（1）模式名稱(Pattern Name)（2）問題(Problem)：描述應在何時使用模式。解釋了設計問

2、題和問題存在的前因后果,可能還描述模式必須滿足的先決條件（3）解決方案(Solution)：描述設計的組成成分、相互關系及各自的職責和協(xié)作方式。模式就像一個模板，可用于多種場合，所以解決方案并不描述一個具體的設計或實現(xiàn)，而是提供設計問題的抽象描述和解決問題所采用的元素組合（類和對象）（4）效果(consequences )：描述模式的應用效果及使用模式應權衡的問題模式的基本要素模式的基本要素p模式名和分類p意圖：設計模式是做什么的？它的基本原理和意圖是什么？它解決的是什么樣的特定設計問題？p動機：說明一個設計問題以及如何用模式中的類、對象來解決該問題的特定情景p適用性：什么情況下可以使用該設計

3、模式？該模式可用來改進哪些不良設計？如何識別這些情況？p結構：采用對象建模技術對模式中的類進行描述如何描述設計模式如何描述設計模式p參與者：指設計模式中的類 和/或 對象以及它們各自的職責p協(xié)作：模式的參與者如何協(xié)作并實現(xiàn)其職責p效果：模式如何支持其目標？使用模式的效果和所需做的權衡取舍？系統(tǒng)結構的哪些方面可以獨立改變？p實現(xiàn)：實現(xiàn)模式時需了解的一些技術要點及應避免的缺陷，以及是否存在某些特定于實現(xiàn)語言的問題p代碼示例：說明怎樣實現(xiàn)該模式的代碼片段p相關模式：與這個模式緊密相關的模式有哪些？其不同之處是什么？這個模式應與哪些其他模式一起使用？描述設計模式（續(xù)）描述設計模式（續(xù)）設計模式的原則設

4、計模式的原則p 開-閉原則(Open Closed Principal)p 單一職責原則(Single Responsibility Principle )p 里氏替換原則(Liskov Substitution Principle )p 依賴倒置原則(Dependence Inversion Principle )p 接口隔離原則(Interface Segregation Principle )p 迪米特法則（最少知道原則）(Least Knowledge Principle)p 設計模式就是實現(xiàn)了上述原則，從而達到代碼復用、增加可維護性的目的p 定義：對擴展是開放的，對修改是關閉的。開發(fā)

5、軟件時，可對其功能進行擴展(開放)，進行擴展時，不需要對原程序進行修改(關閉)p 優(yōu)點p 軟件可用性較靈活，可對完成后的軟件進行擴展，加入新功能，可通過不斷增加新模塊滿足不斷變化的新需求p 由于不修改軟件原有的模塊，不用擔心軟件的穩(wěn)定性開閉原則（開閉原則（OCP）u就一個類而言，應該僅有一個引起它變化的原因。每一個引起類變化的原因就是一個職責，當類具有多職責時,應把多余職責分離出去，分別創(chuàng)建一些類來完成每一個職責u每一個職責都是一個變化的軸線，當需求變化時會反映為類的職責的變化舉例： interface Modem public void dial(String pno); public vo

6、id hangup(); public send(char c); public char recv(); Modem類有兩個職責：連接管理和數(shù)據(jù)通信，應將它們分離單一職責原則（單一職責原則（SRP）interface ModemCon public void dial(String pno); public void hangup(); interface ModemCom public send(char c); public char recv(); 里氏替換原則（里氏替換原則（LSP）p 里氏替換原則是繼承復用的基石，只有當派生類可以替換掉其基類，而軟件功能不受影響時，基類才能真正被復

7、用，派生類也才能夠在基類的基礎上增加新的行為p LSP本質：在同一個繼承體系中的對象應該有共同的行為特征p 例子：企鵝是鳥嗎？ 生物學：企鵝屬于鳥類 LSP原則：企鵝不屬于鳥類，因為企鵝不會“飛”p 違反LSP的后果：有可能需要修改客戶代碼依賴倒置原則（依賴倒置原則（DIP）p 高層模塊不應依賴于低層模塊，二者都依賴于抽象；抽象不應該依賴細節(jié)；細節(jié)應該依賴抽象p 高層模塊只應該包含重要的業(yè)務模型和策略選擇，低層模塊則是不同業(yè)務和策略的實現(xiàn)p 高層抽象不依賴高層和低層模塊的具體實現(xiàn)，最多只依賴于低層的抽象p 低層抽象和實現(xiàn)也只依賴于高層抽象 p 輔助原則 p 任何變量都不應該持有一個指向具體類的

8、引用p 任何類都不應該從具體類派生p 任何方法都不應覆蓋其任何基類中已經(jīng)實現(xiàn)了的方法 接口隔離原則（接口隔離原則（ISP）p使用多個專門的接口比使用單一的總接口要好 p一個類對另一個類的依賴性應當建立在最小的接口上 p一個接口代表一個角色，不應當將不同的角色都交給一個接口，沒有關系的接口合并在一起，形成一個臃腫的大接口，這是對角色和接口的污染p“不應該強迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結構。”換句話說，不要強迫客戶使用它們不用的方法，如果強迫用戶使用它們不用的方法，那么這些客戶就會面臨由于這些不使用方法的改變所帶來的改變最少知道原則（最少知道原則（LKP）p 一個

9、軟件實體應當盡可能少地與其他實體發(fā)生相互作用p 每一個軟件單位對其他單位都只有最少的知識，而且局限于那些與本單位密切相關的軟件單位p 迪米特法則的初衷在于降低類之間的耦合。由于每個類盡量減少對其他類的依賴，因此，很容易使得系統(tǒng)的功能模塊功能獨立，相互之間不存在（或很少有）依賴關系 p在設計模式經(jīng)典著作GOF95中，設計模式從應用的角度被分為三大類型 p創(chuàng)建型模式/結構型模式/行為型模式p根據(jù)模式應用范圍分，模式可應用于類，也可應用于對象p類模式：處理類和子類之間的關系，這些關系通過繼承建立，是靜態(tài)的，在編譯時刻便確定下來了p對象模式：處理對象間的關系，這些關系在運行時刻是可以變化的，更具動態(tài)性

10、p從某種意義上來說，幾乎所有模式都使用繼承機制，所以“類模式”只指那些集中于處理類間關系的模式，而大部分模式都屬于對象模式的范疇設計模式的類型設計模式的類型p 創(chuàng)建型設計模式是用來創(chuàng)建對象的模式，該類模式抽象了實例化過程 p 工廠模式：父類負責定義創(chuàng)建對象的公共接口，而子類則負責生成具體對象，將類的實例化操作延遲到子類中完成p 抽象工廠模式：為一個產(chǎn)品族提供統(tǒng)一的創(chuàng)建接口。當需要這個產(chǎn)品族的某一系列的時候，可以從抽象工廠中選出相應的系列創(chuàng)建一個具體的工廠類p 單件（Singleton）模式：保證一個類有且僅有一個實例，提供一個全局訪問點創(chuàng)建型設計模式創(chuàng)建型設計模式創(chuàng)建型設計模式創(chuàng)建型設計模式p

11、 生成器（Builder）模式：將復雜對象創(chuàng)建與表示分離，同樣的創(chuàng)建過程可創(chuàng)建不同的表示。允許用戶通過指定復雜對象類型和內(nèi)容來創(chuàng)建對象，用戶不需要知道對象內(nèi)部的具體構建細節(jié)p 原型（Prototype）模式：通過“復制”一個已經(jīng)存在的實例來返回新的實例（不新建實例）。被復制的實例就是“原型”，這個原型是可定制的。原型模式多用于創(chuàng)建復雜的或者耗時的實例，因為這種情況下，復制一個已經(jīng)存在的實例使程序運行更高效p 結構型模式討論的是類和對象的結構，它采用繼承機制來組合接口或實現(xiàn)（類結構型模式），或者通過組合一些對象來實現(xiàn)新的功能（對象結構型模式）p 組合（Composite）模式：定義一個接口，使之

12、用于單一對象，也可以應用于多個單一對象組成的對象組p 裝飾（Decorator）模式：給對象動態(tài)添加額外的職責，就好像給一個物體加上裝飾物，完善其功能p 代理（Proxy）模式：有些對象由于跨越網(wǎng)絡或其他障礙，而不能或者不想直接訪問另一個對象，直接訪問會給系統(tǒng)帶來不必要的復雜性，這時候可以在客戶程序和目標對象之間增加一個中間代理對象，讓代理對象來代替目標對象結構型設計模式結構型設計模式結構型設計模式結構型設計模式p 享元（Flyweight）模式：享元是一個共享對象，它可以同時在不同上下文（Context）使用p 外觀（Facade）模式：外觀模式為子系統(tǒng)提供了一個更高層次、更簡單的接口，從而

13、降低了子系統(tǒng)的復雜度，使子系統(tǒng)更易于使用和管理。外觀承擔了子系統(tǒng)中類交互的責任p 橋梁（Bridge）模式：橋梁模式的用意是將問題的抽象和實現(xiàn)分離開來實現(xiàn)，通過用聚合代替繼承來解決子類爆炸性增長的問題p 適配器(Adapter)模式：將一個類的接口適配成用戶期待接口。一個適配器允許因為接口不兼容而不能在一起工作的類工作在一起，做法是將類自己的接口包裝在一個已存在的類中 p 著力解決的是類實體之間的通訊關系，希望以面向對象的方式描述一個控制流程p 模版（Template ） 模式：定義了一個算法步驟，并允許子類為一個或多個步驟提供實現(xiàn)。子類在不改變算法架構的情況下，可重新定義算法中某些步驟p 觀

14、察者（Observer）模式：定義了對象之間一對多的依賴，當這個對象的狀態(tài)發(fā)生改變的時候，多個對象會接受到通知，有機會做出反饋p 迭代子（Iterator）模式：提供一種方法順序訪問一個聚合對象中各個元素, 而又不需暴露該對象的內(nèi)部表示行為型設計模式行為型設計模式p 責任鏈（Chain of Responsibility）模式：多個對象由每一個對象對其下一個對象的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發(fā)出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使系統(tǒng)可以在不影響客戶端的情況下動態(tài)的重新組織鏈和分配責任p 備忘錄（Memento）模

15、式：在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復到原先保存的狀態(tài)p 命令（Command）模式：將請求及其參數(shù)封裝成一個對象，作為命令發(fā)起者和接收者的中介，可以對這些請求排隊或記錄請求日志，以及支持可撤銷操作行為型設計模式行為型設計模式p 狀態(tài)（State）模式：允許一個“對象”在其內(nèi)部狀態(tài)改變的時候改變其行為，不同狀態(tài)表現(xiàn)不同行為p 訪問者（Visitor）模式：表示作用于某對象結構中的各元素的操作?？稍诓桓淖冊仡惖那疤嵯露x作用于這些元素的新操作p 解釋器(Interpreter) 模式：給定一個語言，定義其文法的表示，并定義一個解

16、釋器，該解釋器使用文法表示來解釋語言中的句子p 中介者（Mediator）模式：用一個中介對象來封裝一系列的對象交互p 策略（Strategy）模式：定義一組算法，將每個算法都封裝起來，并且使它們之間可以互換。策略模式使這些算法在客戶端調(diào)用它們的時候能夠互不影響地變化行為型設計模式行為型設計模式創(chuàng)建型設計模式p工廠模式p抽象工廠模式p建造者模式p單件模式p原型模式創(chuàng)建型設計模式創(chuàng)建型設計模式p 在面向對象編程中, 使用new操作符構造對象實例是一種常規(guī)方法，但該方法存在一些約束條件和缺陷：（1）創(chuàng)建對象前須明確對象的類信息，但某些情況可能無法達到此要求，譬如打開一個視頻文件需要一個播放器對象，

17、但用戶可能并不知道具體播放器，需要系統(tǒng)分派一個合適的播放器（2）復雜對象的創(chuàng)建需要多個步驟p 需計算或取得對象的初始設置p 需選擇生成哪個子對象實例p 在生成所需對象之前必須先生成一些輔助對象p 新對象的創(chuàng)建是一個“過程”，而不是一個簡單操作。為了能方便完成這些復雜對象的創(chuàng)建工作，可引入工廠模式 工廠模式的由來工廠模式的由來工廠模式的結構工廠模式的結構p Product：定義工廠方法所創(chuàng)建對象的接口p ConcreteProduct：實現(xiàn)Product接口p Factory：聲明工廠方法，返回一個Product對象。Factory也可定義工廠方法的缺省實現(xiàn)，返回一個缺省ConcreteProd

18、uct對象p Concrete Factory：重定義工廠方法，返回一個ConcreteProduct對象工廠模式的參與者工廠模式的參與者p日志管理器，支持兩種類型日志pFileLogpEventLog工廠模式實例工廠模式實例/ LogFactory類public abstract class LogFactory public abstract Log Create();工廠模式實例分析工廠模式實例分析/ FileFactory類 public class FileFactory：LogFactory public override FileLog Create() return new F

19、ileLog(); / EventFactory類 public class EventFactory：LogFactory public override EventLog Create() return new EventLog(); public class App public static void Main(string args) LogFactory factory1 = new EventFactory(); FileFactory factory2 = new FileFactory(); Log log1 = factory1.Create(); Log log2 = f

20、actory2.Create(); log1.Write(); log2.Write(); 工廠模式客戶端程序工廠模式客戶端程序p 有效避免了具體產(chǎn)品對象和應用程序之間的耦合，增加了具體工廠對象和應用程序之間的耦合p 在類內(nèi)部創(chuàng)建對象通常比直接創(chuàng)建對象更靈活p 工廠模式通過面向對象的手法，將具體對象的創(chuàng)建工作延遲到子類，提供了一種擴展策略，較好的解決了緊耦合問題工廠模式實例分析工廠模式實例分析抽象工廠模式的由來抽象工廠模式的由來p 在軟件系統(tǒng)中，經(jīng)常面臨“一系列相互依賴對象”的創(chuàng)建工作，由于需求變化，“一系列相互依賴的對象”也要改變，如何應對這種變化呢？如何像工廠模式一樣繞過常規(guī)的”new”，

21、提供一種“封裝機制”來避免客戶程序和這種“多系列具體對象創(chuàng)建工作”的緊耦合？p 一種說法：可以通過工廠模式創(chuàng)建每個對象，但無法保證“相互依賴對象”之間的聯(lián)系 p 實例：Windows桌面主題，當更換一個桌面主題的時候，系統(tǒng)的開始按鈕、任務欄、菜單欄、工具欄等都變了，而且是一起變的，色調(diào)都保持一致，類似這樣的問題如何解決呢？p 應用抽象工廠模式，是一種有效的解決途徑抽象工廠模式的意圖抽象工廠模式的意圖p意圖：提供一個創(chuàng)建一系列相關或相互依賴對象的接口，而無需指定他們具體的類p適用場合p一個系統(tǒng)由多個產(chǎn)品系列中的一個來配置時p強調(diào)一系列相關產(chǎn)品對象的設計以便進行聯(lián)合時p提供一個產(chǎn)品類庫，只想顯示其

22、接口而非實現(xiàn)時p需要創(chuàng)建的對象是一系列相互關聯(lián)或相互依賴的產(chǎn)品族時抽象工廠模式的結構抽象工廠模式的結構p Abstract Factory：聲明創(chuàng)建抽象產(chǎn)品對象的操作接口p ConcreteFactory：實現(xiàn)創(chuàng)建具體對象的操作p Abstract Product：為一類產(chǎn)品對象聲明一個接口p ConcreteProduct：定義一個被具體工廠創(chuàng)建的產(chǎn)品對象抽象工廠模式的參與者抽象工廠模式的參與者實例：需要設計一個花園布局 花園有三種風格：典雅型、實用型和懶人型 花園中有3個位置需要種植植物：花臺、墻角和花園中心抽象工廠模式的應用實例抽象工廠模式的應用實例風格/位置花臺中心墻角典雅型郁金香榕樹

23、蘭草實用型葡萄石榴絲瓜懶人型月季茶花竹子建造者（建造者（Builder）模式的由來）模式的由來p 在軟件系統(tǒng)中，有時面臨“復雜對象”的創(chuàng)建工作，該復雜對象通常由各個部分的子對象用一定的算法構成p 這個復雜對象的各個部分經(jīng)常面臨劇烈變化，但是將它們組合在一起的算法卻相對穩(wěn)定p 如何應對這種變化？如何提供一種“封裝機制”來隔離出“復雜對象的各個部分”的變化，從而保持系統(tǒng)中的“穩(wěn)定構建算法”不隨著需求改變而改變？建造者模式的意圖和適用性建造者模式的意圖和適用性p 意圖：將一個復雜的構建與表示相分離，使得同樣的構建過程可以創(chuàng)建不同的表示p 適用性場合p 需要生成的產(chǎn)品對象有復雜的內(nèi)部結構p 創(chuàng)建復雜對

24、象的算法穩(wěn)定，或可強迫生成一定順序p 當構造過程允許被構造的對象有不同的表示時建造者模式的結構建造者模式的結構建造者模式的參與者建造者模式的參與者p Builder：為創(chuàng)建一個Product對象的各個部件指定抽象接口p ConcreteBuilder：實現(xiàn)Builder接口來構造和裝配產(chǎn)品各個部件，提供一個檢索產(chǎn)品的接口p Director：構造一個使用Builder接口的對象p Product：表示被構造的復雜對象p 實例：設計游戲場景中的房屋p房屋由五個部分組成：地板、墻壁、窗戶、門和天花板p構建房屋的步驟固定，而具體組件（門、窗等）易變p采用建造者模式分離易變組件和穩(wěn)定的構建過程建造者模

25、式的應用示例建造者模式的應用示例public abstract class House /定義一個房屋抽象類 public abstract class Builder /這部分是易變的 public abstract void BuildFloor(); /地板 public abstract void BuildDoor(); /門 public abstract void BuildWindows(); /窗戶 public abstract void BuildWall(); /墻壁 public abstract void BuildHouseCeiling() /天花板 publi

26、c abstract House GetHouse(); 建造者模式的應用示例建造者模式的應用示例建造者模式的應用示例建造者模式的應用示例public abstract class GameManager /規(guī)定構建次序 public static House CreateHouse(Builder builder) builder.BuildFloor(); builder.BuildDoor(); builder.Buildwall(); builder.BuildWindows(); builder.BuildHouseCeiling(); return builder.GetHouse

27、(); 建造者模式的應用示例建造者模式的應用示例public class RomanHouseBuilder : Builder public override void BuildDoor() public override void BuildFloor() public override void BuildWindows() public override void BuildWall() public override void BuildHouseCeiling() public override House GetHouse() 建造者模式的應用示例建造者模式的應用示例class

28、 App public static void main() House house = GameManager.CreateHouse(new RomanHouseBuilder(); 建造者模式分析建造者模式分析p 建造者模式的使用使產(chǎn)品內(nèi)部表象可以獨立變化；可以使客戶端不必知道產(chǎn)品內(nèi)部組成細節(jié)p 每一個Builder都相對獨立，與其它Builder無關p 可對構造過程更加精細控制p 將構建代碼和表示代碼分開p 缺點：難于應付“分步驟構建算法”的需求變動單件（單件（SingletonSingleton）模式的由來）模式的由來p 單件模式的實例較為普遍：p 系統(tǒng)中只能有一個窗口管理器p 系統(tǒng)

29、中只能有一個文件系統(tǒng)p 一個數(shù)字濾波器只能有一個A/D轉換器p 一個會計系統(tǒng)只能用于一個公司單件模式的由來單件模式的由來p 如何才能保證一個類只有一個實例并且這個實例易于被訪問呢？全局變量使得一個對象可以被訪問，但不能防止實例化多個對象p 更好的辦法： 讓類自身保存其唯一實例，可以保證該類沒有其他實例可以被創(chuàng)建，并且它可以提供一個訪問該實例的方法單件模式的意圖和適用性單件模式的意圖和適用性p 意圖：保證一個類僅有一個實例，并提供一個全局訪問點p 適用場合：p 當類只能有一個實例而且需要使用戶可從一個統(tǒng)一訪問點訪問它時p 當這個唯一實例通過子類化可擴展，并且客戶應該無需更改代碼就能使用一個擴展實

30、例時單件模式的結構單件模式的結構p Singleton ：被調(diào)用的單件對象p 定義一個Instance操作，允許客戶訪問它的唯一實例。Instance是一個類操作（靜態(tài)成員函數(shù)） ，負責創(chuàng)建自己的唯一實例單件模式的應用示例單件模式的應用示例Class Singleton /單件模式的定義 public:static Singleton* Instance(); /通過該成員函數(shù)訪問單件 protected:Singleton(); /構造函數(shù)為受保護型，直接實例化將出錯 private:static Singleton* _instance; /指向本身唯一實例的指針;單件模式的應用示例單件模

31、式的應用示例Singleton * Singleton:_instance = 0; /初始化類成員Singleton* Singleton:Instance()If(_instance = 0) _instance =new Singleton; return _instance;單件模式的效果分析單件模式的效果分析p 可實現(xiàn)對唯一實例的受控訪問：因為Singleton類封裝唯一實例，所以它可以嚴格的控制客戶怎樣以及何時訪問它p 縮小了名空間：Singleton模式是對全局變量的一種改進。它避免了那些存儲唯一實例的全局變量污染名空間原型（原型（Prototype）模式的由來）模式的由來p 在

32、軟件系統(tǒng)中，客戶希望創(chuàng)建一個產(chǎn)品時，可能有三種情況：p 知道產(chǎn)品具體型號：使用new運算符創(chuàng)建p 不知道產(chǎn)品型號，知道特定的需求：使用工廠模式p 不知道需求，但想要一個和已知對象相同的對象：使用原型模式原型（原型（Prototype）模式的意圖和適用性）模式的意圖和適用性p 意圖：用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象p 適用性：p 一個系統(tǒng)獨立于其產(chǎn)品創(chuàng)建，構成和表示時p 要實例化的類在運行時刻指定時p 為避免創(chuàng)建一個與產(chǎn)品類層次平行的工廠類層次時原型模式的結構原型模式的結構p Client：客戶端向原型管理器提出創(chuàng)建對象請求p Prototype：是對各種具體原型的

33、抽象，通常由一個接口或抽象類實現(xiàn)p ConcretePrototype：被復制的對象。此角色需要實現(xiàn)抽象的原型角色所要求的接口p PrototypeManager：創(chuàng)建具體原型類的對象，記錄每一個被創(chuàng)建的對象原型模式的參與者原型模式的參與者p 開發(fā)一個調(diào)色板，用戶單擊調(diào)色板上任一個方塊，返回一個對應顏色的實例p 把每種顏色作為一個對象，并為他們抽象出一個公共父類原型模式應用示例原型模式應用示例原型模式應用示例原型模式應用示例p 優(yōu)點（1）對客戶隱藏具體產(chǎn)品類，減少了客戶知道的名字的數(shù)目（2）允許客戶只通過注冊原型實例就可以將一個具體產(chǎn)品類并入系統(tǒng)中，客戶可以在運行時刻建立和刪除原型（3）具有給

34、一個應用軟件動態(tài)加載新功能的能力。由于其獨立性較高，可以很容易動態(tài)加載新功能而不影響老系統(tǒng)（4）產(chǎn)品類不需要非得有任何事先確定的等級結構，適用于任何的等級結構p 缺點 Prototype模式的最主要缺點就是每個類必須配備一個克隆方法原型模式的應用效果分析原型模式的應用效果分析p 工廠模式是一種極端情況下的抽象工廠模式，而抽象工廠模式可以看成是工廠模式的一種推廣p 工廠模式的特點p一個抽象產(chǎn)品類，可以派生出多個具體產(chǎn)品類p一個抽象工廠類，可以派生出多個具體工廠類p每個具體工廠類只能創(chuàng)建一個具體的產(chǎn)品類實例p 抽象工廠模式的特點p多個抽象產(chǎn)品類，每個抽象產(chǎn)品類可以派生出多個具體產(chǎn)品類p一個抽象工廠

35、類，可以派生出多個具體工廠類p每個具體工廠類可以創(chuàng)建多個具體產(chǎn)品類的實例抽象工廠模式與工廠模式的區(qū)別抽象工廠模式與工廠模式的區(qū)別p抽象工廠允許客戶使用抽象接口來創(chuàng)建一組相關產(chǎn)品，而不需要關心具體產(chǎn)出產(chǎn)品是什么p總結p 所有工廠都是用來封裝對象的創(chuàng)建p 簡單工廠，可以把客戶程序從具體類解耦p 工廠方法使用繼承，把對象創(chuàng)建委托給子類，子類實現(xiàn)工廠方法來創(chuàng)建對象p 抽象工廠使用對象組合：對象的創(chuàng)建被實現(xiàn)在工廠接口所暴露出來的方法中p 所有工廠模式都通過減少應用程序與具體類之間的依賴關系促進松耦合p 工廠方法允許類將實例化延遲到子類進行p 抽象工廠創(chuàng)建相關的家族，而不需要依賴他們的具體類p 工廠幫助我

36、們針對抽象編程，而不是針對具體類編程抽象工廠模式與工廠模式的區(qū)別抽象工廠模式與工廠模式的區(qū)別p 工廠模式：定義一個創(chuàng)建對象的接口，由子類決定要實例化的具體類，工廠方法讓類把實例化推遲到子類p 抽象工廠模式：提供一個接口，用于創(chuàng)建相關或依賴對象的家族，而不需要明確指定具體類p 建造者模式：封裝一個產(chǎn)品（復雜對象）的構造過程，并允許按照步驟構造，向客戶隱藏了產(chǎn)品的內(nèi)部表現(xiàn)p 單件模式：確保一個類只有一個實例，并提供全局訪問點p 原型模式：當創(chuàng)建給定類實例的過程很昂貴或很復雜時，使用原型模式，向客戶隱藏制造新實例的復雜性創(chuàng)建型設計模式總結創(chuàng)建型設計模式總結結構型設計模式p 適配器模式p 外觀模式p

37、裝飾模式p 橋接模式p 享元模式p 代理模式p 組合模式結構型模式的主要內(nèi)容結構型模式的主要內(nèi)容軟件開發(fā)過程中常見的問題軟件開發(fā)過程中常見的問題p 系統(tǒng)組件更新問題：軟件系統(tǒng)的某組件過時了，要從廠商那里引進一個新的組件，但原系統(tǒng)的組件接口和新組件的接口不一致，同時又不想改變現(xiàn)有的代碼，如何實現(xiàn)從舊組件更新到新組件現(xiàn)有現(xiàn)有系統(tǒng)系統(tǒng)接口接口廠廠商商類類兩個接口兩個接口無法匹配，無法匹配，所以無法所以無法工作工作軟件開發(fā)過程中常見的問題軟件開發(fā)過程中常見的問題p 生活中相似問題的解決方案不合適的插座問題p 電腦的插頭是三相的p 墻上的插座只有兩相的p 插頭和插座的“接口”不匹配，怎么辦？組件更新問題

38、的可行解決方案組件更新問題的可行解決方案現(xiàn)有現(xiàn)有系統(tǒng)系統(tǒng)接口接口廠廠商商類類兩個接口兩個接口無法匹配，無法匹配，所以無法所以無法工作工作現(xiàn)有現(xiàn)有系統(tǒng)系統(tǒng)接口接口廠廠商商類類適適配配器器適配器模式的動機適配器模式的動機p 一個team要為外界提供S類服務，但team里面沒有能夠完成此項任務的member，只有team外的A可以完成這項服務。為保證對外服務類別的一致性（能提供S服務）p 將A招安到team內(nèi)，負責提供S類服務p A不準備接受招安，可安排B去完成這項任務，并讓B做好A的工作，讓B工作的時候向A請教，此時，B是一個復合體（提供S服務，是A的繼承弟子）p 動機：將一個類的接口，轉換成客戶

39、期望的另一個接口，適配器讓原本接口不兼容的類可以一起工作適配器模式使用過程適配器模式使用過程p 客戶（Client）通過目標接口調(diào)用適配器（Adapter）的方法對適配器發(fā)出請求p 適配器（Adapter）使用被適配者（Adaptee）接口把請求轉換成被適配者的一個或者多個調(diào)用接口p 客戶接收到調(diào)用的結果，但并未察覺這一切是適配器在起轉換作用適配器模式的適用性適配器模式的適用性p 適用場合：p 使用一個已經(jīng)存在的類，而它的接口不符合要求p 創(chuàng)建一個可以復用的類，該類可以與其他不相關的類或不可預見的類（即那些接口可能不一定兼容的類）協(xié)同工作p 使用一些已經(jīng)存在的子類，但不可能通過子類化以匹配各自

40、接口。對象適配器可以適配它的父類接口p 分類：p 類適配器：通過多重繼承匹配一個接口和另一個接口p 對象適配器：在一個類中定義另一個類的實例對象，實現(xiàn)類和對象的組合類適配器類適配器p 用一個具體的Adapter類對Adaptee和Target進行匹配，Adapter類多重繼承Adaptee和Target類p Adapter可重定義Adaptee的部分行為，因為Adapter是Adaptee的一個子類類適配器模式示例類適配器模式示例/Target：定義Client使用的與特定領域相關的接口 public interface Target void request(); /Adaptee:需要適配

41、的已經(jīng)存在的接口 public class Adaptee public void specificRequest() /Adapter:對對Adaptee 的接口與的接口與Target接口進行適配接口進行適配 public class Adapter extends Adaptee implements Target public void request() super. specificRequest(); 對象適配器對象適配器p 允許一個Adapter與多個Adaptee同時工作，即Adaptee本身以及它的所有子類（如果有子類的話）同時工作。Adapter可以一次給所有的Adapte

42、e添加功能p 使用組合，不僅可以適配某個類，也可以適配該類的任何子類對象適配器模式示例對象適配器模式示例/Target：定義Client使用的與特定領域相關的接口 public interface Target void request(); /Adaptee:現(xiàn)在需要適配的已經(jīng)存在的接口 public class Adaptee public void specificRequest() /Adapter:對對Adaptee 的接口與的接口與Target接口進行適配接口進行適配 public class Adapter implements Target private Adaptee ad

43、aptee; public Adapter(Adaptee adaptee) super(); this.adaptee = adaptee; public void request() adaptee.specificRequest(); 適配器模式效果分析適配器模式效果分析p 優(yōu)點p 方便設計者自由定義接口，不用擔心匹配問題p 缺點p 屬于靜態(tài)結構 ，由于只能單繼承，所以不適用于多種不同的源適配到同一個目標兩種適配器模式的比較兩種適配器模式的比較外觀（外觀（Facade）模式的由來）模式的由來畢業(yè)生教務處公安處后勤處圖書館飯卡飯卡余額借書證借書證押金身份證、學生證派遣證學生證畢業(yè)證、學位證

44、外觀（外觀（Facade）模式的由來）模式的由來畢業(yè)生畢業(yè)手續(xù)代辦處教務處后勤處圖書館公安處學生證 身份證 借書證 飯卡畢業(yè)證 學位證 派遣證 飯卡余額 借書證押金外觀（外觀（Facade）模式的由來）模式的由來外觀外觀(Faade)模式的由來模式的由來外觀（外觀（Facade）模式的意圖和適用性）模式的意圖和適用性p 提供了一個統(tǒng)一的接口，用來訪問子系統(tǒng)中的一群接口。外觀定義了一個高層接口，讓子系統(tǒng)更容易使用p 解除客戶程序對抽象類具體實現(xiàn)部分的依賴，有利于移植和更改p 當需要構建層次結構的子系統(tǒng)時，使用Faade模式定義每層入口點。如果子系統(tǒng)間相互依賴，只需通過Faade進行通訊p 外觀模

45、式的本質是讓接口變得更簡單外觀（外觀（Facade）模式的結構）模式的結構外觀（外觀（Facade）模式的參與者）模式的參與者p Faadep 知道哪些子系統(tǒng)類負責處理請求p 將客戶的請求代理給適當?shù)淖酉到y(tǒng)對象p Subsystem Classesp 實現(xiàn)子系統(tǒng)的功能p 處理由Faade 對象指派的任務p 沒有Faade的任何相關信息外觀（外觀（Facade）模式的效果分析）模式的效果分析p 根據(jù)“單一職責原則”，在軟件中將一個子系統(tǒng)劃分為若干個子系統(tǒng)有利于降低整個系統(tǒng)的復雜性，一個常見的設計目標是使子系統(tǒng)之間的通信和相互依賴關系達到最小，而達到該目標的途徑之一就是引入一個外觀對象，它為子系統(tǒng)

46、的訪問提供了一個簡單而單一的入口p 外觀模式也是“迪米特法則”的體現(xiàn)，通過引入一個新的外觀類可以降低原有系統(tǒng)的復雜度，同時降低客戶類與子系統(tǒng)類的耦合度外觀（外觀（Facade）模式的效果分析）模式的效果分析p 外觀模式要求一個子系統(tǒng)的外部與其內(nèi)部的通信通過一個統(tǒng)一的外觀對象進行，外觀類將客戶端與子系統(tǒng)的內(nèi)部復雜性分隔開，使得客戶端只需要與外觀對象打交道，而不需要與子系統(tǒng)內(nèi)部的很多對象打交道p 外觀模式的目的在于降低系統(tǒng)的復雜程度p 外觀模式從很大程度上提高了客戶端使用的便捷性，使得客戶端無須關心子系統(tǒng)的工作細節(jié)，通過外觀角色即可調(diào)用相關功能p 如何增加新的子系統(tǒng)？是否可能違背“開閉原則”外觀（

47、外觀（Facade）模式的缺點）模式的缺點p 不能很好的限制客戶使用子系統(tǒng)類，如果對客戶訪問子系統(tǒng)類做太多的限制，則減少了可變形和靈活性p 增加一個新的子系統(tǒng)，可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”，怎么辦？p 引入抽象外觀類，客戶端針對抽象外觀類編程裝飾（裝飾（Decorator）解決的問題）解決的問題p 新買一輛車，但外表不夠美觀p 對車的外表進行必要的裝飾裝飾（裝飾（Decorator）模式的由來）模式的由來p 動態(tài)給對象添加額外職責。比如：一幅畫有沒有畫框都可以掛在墻上，畫是被裝飾者。在掛在墻上之前，畫可以被蒙上玻璃，裝到框子里，玻璃畫框就是裝飾p 不改變接口，但加入了

48、責任。Decorator提供了一種給類增加職責的方法，不是通過繼承，而是通過組合實現(xiàn)的裝飾（裝飾（Decorator）模式的意圖和適用性）模式的意圖和適用性p 意圖p 動態(tài)地給一個對象添加一些額外的職責。就增加功能來說，Decorator 模式比生成子類更為靈活p 適用場合p 在不影響其他對象的情況下，以動態(tài)、透明的方式給單個對象添加職責p 當不能采用生成子類的方法進行擴充時。一種情況是，可能有大量獨立擴展，每一種組合將產(chǎn)生大量的子類，使得子類數(shù)目呈爆炸性增長。另一種情況是因為類定義被隱藏，或類定義不能用于生成子類裝飾（裝飾（Decorator）模式的結構）模式的結構p Component：定

49、義對象的接口，可以給對象動態(tài)添加職責p ConcreteComponent：定義具體對象，裝飾抽象類可以給它添加額外的職責p Decorator：維持一個指向Component對象的指針，并定義一個與Component接口一致的接口p ConcreteDecorator：具體裝飾對象，向具體對象添加職責p Decorator將請求轉發(fā)給它的Component對象，并有可能在轉發(fā)請求前后執(zhí)行一些附加的動作裝飾（裝飾（Decorator）模式的結構）模式的結構裝飾（裝飾（Decorator）模式的應用）模式的應用ComponentConcreteComponent裝飾（裝飾（Decorator）模

50、式的應用）模式的應用Decorator裝飾（裝飾（Decorator）模式的應用）模式的應用ConcreteDecorator裝飾（裝飾（Decorator）模式的應用）模式的應用裝飾（裝飾（Decorator）模式的評價）模式的評價p 使用Decorator模式可以很容易地向對象添加職責?？梢杂锰砑雍头蛛x的方法，在運行時添加和刪除職責p 使用Decorator模式可以很容易地重復添加一個特性，而兩次繼承則極容易出錯p 避免在層次結構高層的類有太多的特征：可以從簡單的部件組合出復雜的功能。具有低依賴性和低復雜性橋接（橋接（Bridge）模式的由來）模式的由來p 例子：設想如果要繪制矩形、圓形、

51、橢圓、正方形，至少需要4個形狀類，但是如果繪制的圖形需要具有不同的顏色，如紅色、綠色、藍色等，此時至少有如下兩種設計方案p 為每一種形狀都提供一套各種顏色的版本p 根據(jù)實際需要對形狀和顏色進行組合橋接（橋接（Bridge）模式的由來）模式的由來12方案表示橋接模式，將繼承關系轉換為關聯(lián)關系，降低了類與類之間的耦合，減少了代碼量橋接（橋接（Bridge）模式的由來）模式的由來p 例子：相同模塊的跨平臺使用p 設計模塊A和Bp 希望模塊A和B能應用在X操作系統(tǒng)上，讓A和B繼承X操作系統(tǒng)的接口p 希望模塊A和B能應用在Y操作系統(tǒng)上，讓A和B繼承Y操作系統(tǒng)的接口，以此類推p 問題：模塊A和B缺乏復用性

52、p 解決：抽象出統(tǒng)一的操作系統(tǒng)類的接口連接模塊A和B的平臺無關接口，通過橋接兩個抽象模塊來消除模塊間的繼承耦合，提高復用性擴展Window抽象使之用于不同種類的窗口或新的平臺很不方便繼承機制使得客戶代碼與平臺相關橋接（橋接（Bridge）模式的由來）模式的由來1將Window抽象和它的實現(xiàn)部分分別放在獨立的類層次結構中針對窗口接口針對平臺的窗口實現(xiàn)橋接（橋接（Bridge）模式的由來）模式的由來2u對于有兩個變化維度（即兩個變化的原因）的系統(tǒng)，采用方案二進行設計，系統(tǒng)中類的個數(shù)更少，且系統(tǒng)擴展更為方便u設計方案二即是橋接模式的應用。橋接模式將繼承關系轉換為關聯(lián)關系，從而降低了類與類之間的耦合，

53、減少了代碼量橋接（橋接（Bridge）模式的動機）模式的動機橋接（橋接（Bridge）模式的意圖和適用性）模式的意圖和適用性p 意圖：橋接模式的作用就是將抽象部分與實現(xiàn)部分分離，使它可以獨立的變化p 適用的情況p 不希望在抽象和它的實現(xiàn)部分之間有一個固定的綁定關系p 想對客戶完全隱藏抽象的實現(xiàn)部分橋接（橋接（Bridge）模式的結構）模式的結構橋接（橋接（Bridge）模式的參與者）模式的參與者p Abstractionp 定義抽象類的接口p 維護一個指向Implementor類型對象的指針p RefinedAbstractionp 擴充由Abstraction定義的接口p Implement

54、orp 定義實現(xiàn)類的接口，不一定要與Abstraction的接口完全一致，甚至可以完全不同p ConcreteImplementorp 實現(xiàn)Implementor接口并定義它的具體實現(xiàn)p Abstraction將Client的請求轉發(fā)給它的Implementor對象橋接（橋接（Bridge）模式的意義）模式的意義p 脫耦是指將抽象和實現(xiàn)之間的耦合解脫開，或者說將他們之間的強關聯(lián)改成若弱關聯(lián)p 強關聯(lián)是指在編譯時期已經(jīng)確定的，無法在運行時期動態(tài)改變的關聯(lián)p 弱關聯(lián)是可以動態(tài)確定并可在運行時刻動態(tài)改變的關聯(lián)p 繼承關系是強關聯(lián)，聚合關系是弱關聯(lián)，將兩個角色之間的繼承關系修改為聚合關系，就是將他們之

55、間的強關聯(lián)變換成弱關聯(lián)。橋模式中的所謂脫耦就是指在一個軟件系統(tǒng)的抽象和實現(xiàn)之間使用組合/聚合關系而不是繼承關系，從而可以使兩者可以相對獨立的變化橋接（橋接（Bridge）模式的優(yōu)點）模式的優(yōu)點p分離抽象接口及其實現(xiàn)部分 p橋接模式有時類似于多繼承方案，但是多繼承方案違背了類的單一職責原則（即一個類只有一個變化的原因），復用性比較差，而且多繼承結構中類的個數(shù)非常龐大，橋接模式是比多繼承方案更好的解決方法p橋接模式提高了系統(tǒng)的可擴充性，在兩個變化維度中任意擴展一個維度，都不需要修改原有系統(tǒng)p實現(xiàn)細節(jié)對客戶透明，可以對用戶隱藏實現(xiàn)細節(jié)橋接（橋接（Bridge）模式的缺點）模式的缺點p橋接模式的引入會

56、增加系統(tǒng)的理解與設計難度，由于聚合關聯(lián)關系建立在抽象層，要求開發(fā)者針對抽象進行設計與編程p橋接模式要求正確識別出系統(tǒng)中兩個獨立變化的維度，因此其使用范圍具有一定的局限性橋接（橋接（Bridge）模式的應用案例）模式的應用案例橋接（橋接（Bridge）模式的應用案例）模式的應用案例享元（享元（Flyweght）模式的由來）模式的由來享元（享元（Flyweght）模式的由來）模式的由來p 當大量使用同一種類型的實例（每個實例中包含部分相同的數(shù)據(jù)）,可能極大的耗費資源，使用Flyweight模式可以提高內(nèi)存效率p 以CD唱片為例，每個CD有三個屬性：出片日期、歌唱者姓名、唱片曲目p 姓名可能重復，可

57、能有同一個演唱者的多個不同時期不同曲目的CD。歌唱者姓名可共享，其他字段均不可共享p 當你有幾千張甚至更多CD時,Flyweight模式將節(jié)省更多空間，共享的flyweight越多，空間節(jié)省也就越大享元（享元（Flyweght）模式的意圖和適用性）模式的意圖和適用性p 意圖：避免大量擁有相同內(nèi)容的小類的開銷，共享一元類p 動機：通過共享技術實現(xiàn)相同或相似對象的重用p 適用性p 一個應用程序使用了大量的對象p 冗余使用了大量的對象，造成了很大的存儲開銷享元（享元（Flyweght）模式的結構）模式的結構享元（享元（Flyweght）模式的參與者）模式的參與者p Flyweight：描述一個接口，

58、可接受并作用于外部狀態(tài)p ConcreteFlyweight：實現(xiàn)Flyweight接口，并為內(nèi)部狀態(tài)增加存儲空間。必須是可共享的，存儲的狀態(tài)必須是內(nèi)部的p UnsharedConcreteFlyweight：不強制共享p FlyweightFactory：創(chuàng)建并管理flyweight對象；確保合理地共享flyweight，提供已創(chuàng)建的flyweight實例或者創(chuàng)建一個p Client：維持一個對flyweight的引用；計算或存儲一個(多個)flyweight的外部狀態(tài)享元（享元（Flyweght）模式的參與者）模式的參與者p Flyweight執(zhí)行時所需的狀態(tài)必定是內(nèi)部或外部的。內(nèi)部狀態(tài)存

59、儲在ConcreteFlyweight中，外部對象則由Client對象存儲或計算。當用戶調(diào)用flyweight對象操作時，將該狀態(tài)傳遞給它p 用戶不應直接對ConcreteFlyweight類進行實例化，而只能從FlyweightFactory對象得到ConcreteFlyweight對象，以保證對它們適當?shù)剡M行共享享元（享元（Flyweght）模式的效果分析）模式的效果分析p Flyweight模式的核心就是把大量共享的對象收集在一起使用簡單工廠模式進行管理，避免由于大量的小對象導致系統(tǒng)的內(nèi)存過渡消耗p 當重復對象較多時， Flyweight模式具有較好的空間性能，但在查找搜索上消耗了時間復

60、雜度代理（代理（Proxy）模式的幾個來源）模式的幾個來源代理（代理（Proxy）模式的由來）模式的由來p 某個客戶端不能直接操作到某個對象，但又必須和那個對象有所互動p 如果對象是一個大圖片,需要花費很長時間才能顯示出來，此時需要做個圖片Proxy來代替真正的圖片p 如果對象在某遠端服務器上,直接操作這個對象因為網(wǎng)絡速度原因可能比較慢，可以用Proxy來代替那個對象p 如何應對這種變化？如何提供一種機制讓原本交互起來比較困難的兩個對象實現(xiàn)暢通無阻地交流呢？如何保持系統(tǒng)的結構不隨著需求改變而輕易改變？這就是代理模式代理（代理（Proxy）模式的意圖和適用性）模式的意圖和適用性p 意圖：為其他對