設計模式期末考試復習

1、一What is design pattern ？模式 是在物體或事件上，產(chǎn)生的一種規(guī)律變化與自我重復的樣式與過程。在模式之中,某些固定的元素不斷以可預測的方式周期性重現(xiàn)。What is design pattern ？廣義講，軟件設計模式是可解決一類軟件問題并能重復使用的軟件設計方案;狹義講，設計模式是對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述.是在類和對象的層次描述的可重復使用的軟件設計問題的解決方案；面向?qū)ο笤O計模式體現(xiàn)的是程序整體的構思，所以有時候它也會出現(xiàn)在分析或者是概要設計階段 設計模式的核心思想是通過增加抽象層，把變化部分從那些不變部分里分離出來GOF（Gan

2、g of Four）的設計模式定義:設計模式是在一個 上下文 中，對一個問題 的 解決方案，及其能夠達到的效果.即模式的四要素:名稱、上下文與問題、解決方案、效果.分類：23種設計模式：創(chuàng)建型:5種結構型：7種行為型：11種四要素：模式名稱(Pattern Name)問題(Problem）：描述應該在何時使用模式.解釋了設計問題和問題存在的前因后果,可能還描述模式必須滿足的先決條件；解決方案（Solution)：描述了設計的組成成分、相互關系及各自的職責和協(xié)作方式。模式就像一個模板，可應用于多種場合，所以解決方案并不描述一個具體的設計或?qū)崿F(xiàn)，而是提供設計問題的抽象描述和解決問題所采用的元素組合

3、（類和對象）；效果（consequences )：描述模式的應用效果及使用模式應權衡的問題都有哪些設計模式？GOF共提出23種設計模式：創(chuàng)建型：5種結構型：7種行為型：11種Creational Patterns用來創(chuàng)建對象的模式，抽象了實例化過程 Factory Method 工廠模式 父類負責定義創(chuàng)建對象的公共接口,而子類則負責生成具體對象，將類的實例化操作延遲到子類中完成；Abstract Factory 抽象工廠模式 為一個產(chǎn)品族提供統(tǒng)一的創(chuàng)建接口。當需要這個產(chǎn)品族的某一系列的時候，可以從抽象工廠中選出相應的系列創(chuàng)建一個具體的工廠類；Singleton 單例模式 保證一個類有且僅有一個

4、實例,提供一個全局訪問點；Builder 建造者模式 將復雜對象創(chuàng)建與表示分離，同樣的創(chuàng)建過程可創(chuàng)建不同的表示.允許用戶通過指定復雜對象類型和內(nèi)容來創(chuàng)建對象,用戶不需要知道對象內(nèi)部的具體構建細節(jié);Prototype 原型模式 通過“復制”一個已經(jīng)存在的實例來返回新的實例（不新建實例）。被復制的實例就是“原型”,這個原型是可定制的.原型模式多用于創(chuàng)建復雜的或者耗時的實例，因為這種情況下,復制一個已經(jīng)存在的實例使程序運行更高效;或者創(chuàng)建值相等，只是命名不一樣的同類數(shù)據(jù)；Structural Patterns結構型模式討論的是類和對象的結構，它采用繼承機制來組合接口或?qū)崿F(xiàn)（類結構型模式），或者通過組

5、合一些對象來實現(xiàn)新的功能(對象結構型模式）Adapter 適配器模式將一個類的接口適配成用戶所期待的接口.一個適配器允許因為接口不兼容而不能在一起工作的類工作在一起，做法是將類自己的接口包裝在一個已存在的類中;Bridge 橋接模式橋接模式的用意是將問題的抽象和實現(xiàn)分離開來實現(xiàn)，通過用聚合代替繼承來解決子類爆炸性增長的問題；Composite 組合模式 定義一個接口，使之用于單一對象,也可以應用于多個單一對象組成的對象組；Decorator 裝飾模式 給對象動態(tài)添加額外的職責，就好像給一個物體加上裝飾物，完善其功能；Faade 外觀模式 外觀模式為子系統(tǒng)提供了一個更高層次、更簡單的接口,從而降

6、低了子系統(tǒng)的復雜度，使子系統(tǒng)更易于使用和管理。外觀承擔了子系統(tǒng)中類交互的責任Flyweight 享元模式 Flyweight是一個共享對象，它可以同時在不同上下文(Context)使用;Proxy 代理模式 在軟件系統(tǒng)中，有些對象有時候由于跨越網(wǎng)絡或者其他障礙,而不能夠或者不想直接訪問另一個對象,直接訪問會給系統(tǒng)帶來不必要的復雜性，這時候可以在客戶程序和目標對象之間增加一層中間層，讓代理對象來代替目標對象打點一切,這就是代理(Proxy）模式;Behavioral Patterns著力解決的是類實體之間的通訊關系，希望以面向?qū)ο蟮姆绞矫枋鲆粋€控制流程。Chain of Responsibili

7、ty 責任鏈模式 很多對象由每一個對象對其下一個對象的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發(fā)出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使系統(tǒng)可以在不影響客戶端的情況下動態(tài)的重新組織鏈和分配責任；Command 命令模式 將請求及其參數(shù)封裝成一個對象，作為命令發(fā)起者和接收者的中介，可以對這些請求排隊或記錄請求日志，以及支持可撤銷操作;Interpreter 解釋器模式 給定一個語言,定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子；Iterator 迭代器模式 提供一種方法順序訪問一個聚合對象中各個

8、元素， 而又不需暴露該對象的內(nèi)部表示；Mediator 中介者模式 用一個中介對象來封裝一系列的對象交互;Memento 備忘錄模式 在不破壞封裝性的前提下,捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復到原先保存的狀態(tài)；Observer 觀察者模式 定義了對象之間一對多的依賴,當這個對象的狀態(tài)發(fā)生改變的時候,多個對象會接受到通知，有機會做出反饋；State 狀態(tài)模式 允許一個“對象”在其內(nèi)部狀態(tài)改變的時候改變其行為，即不同的狀態(tài)，不同的行為Strategy 策略模式 定義一組算法，將每個算法都封裝起來，并且使它們之間可以互換.策略模式使這些算法在客戶端調(diào)用它們的

9、時候能夠互不影響地變化；Template 模板模式 定義了一個算法步驟，并允許子類為一個或多個步驟提供實現(xiàn)。子類在不改變算法架構的情況下，可重新定義算法中某些步驟;Visitor 訪問者模式 表示一個作用于某對象結構中的各元素的操作.可以在不改變各元素的類的前提下定義作用于這些元素的新操作；面向?qū)ο蠓椒ǔ橄螅ˋbstraction）封裝（Encapsulation）多態(tài)（Polymorphism）繼承(Inheritance）Object-Oriented Method類的功能要單一，體現(xiàn)了抽象加強內(nèi)聚，松散耦合好的封裝性類的粒度要合理實現(xiàn)類不能依賴使用類應考慮靈活性,也就是可配置，可維護要考

10、慮性能，可伸縮性要考慮后續(xù)的變化,也就是可擴展性要考慮合理的復用，這是平衡的藝術要合理的考慮接口和抽象類的使用盡量減少類間的交互次數(shù)和交互的信息量訪問對象必須通過接口，不能繞過接口直接訪問OO design principles開閉原則 （OCP)單一職責原則（SRP)里氏替換原則(LSP)依賴倒置原則（DIP)接口隔離原則（ISP)迪米特原則（LoD）單一職責原則（Single Responsibility Principle, SRP）定義：就一個類而言，應該僅有一個引起它變化的原因；每一個引起類變化的原因就是一個職責，當類具有多職責時，應把多余職責分離出去,分別創(chuàng)建一些類來完成每一個職責

11、；每一個職責都是一個變化的軸線，當需求變化時會反映為類的職責的變化；里氏替換原則（Liskov Substitution Principle， LSP）定義：所有引用基類的地方必須能透明地使用其子類的對象里氏替換原則是繼承復用的基石，只有當派生類可以替換掉其基類，而軟件功能不受影響時，基類才能真正被復用，派生類也才能夠在基類的基礎上增加新的行為LSP本質(zhì)：在同一個繼承體系中的對象應該有共同的行為特征里氏替換原則包含了兩層重要含義:子類必須完全的實現(xiàn)父類的方法；子類可以有自己的個性依賴倒置原則（Dependence Inversion Principle， DIP）定義：高層模塊不應依賴低層模塊

12、，二者都應該依賴于抽象高層模塊只應該包含重要的業(yè)務模型和策略選擇，低層模塊則是不同業(yè)務和策略的實現(xiàn)；高層抽象不依賴高層和低層模塊的具體實現(xiàn),最多只依賴于低層的抽象;低層抽象和實現(xiàn)也只依賴于高層抽象 ；輔助原則 任何變量都不應該持有一個指向具體類的引用;任何類都不應該從具體類派生；任何方法都不應覆蓋其任何基類中已經(jīng)實現(xiàn)了的方法 ;DIP引例 駕駛汽車依賴倒置原則（DIP）另一種理解：客戶類和服務類都應該依賴于抽象（接口），并且客戶類擁有接口。依賴是有方向的，客戶類依賴于服務類。DIP引例 駕駛汽車DIP引例 駕駛汽車接口隔離原則（Interface Separate Principle, ISP

13、）定義：類間的依賴關系應該建立在最小的接口上。多個和客戶相關的接口要好于一個通用接口；如果一個類有幾個使用者，與其讓這個類載入所有使用者需要使用的所有方法，還不如為每個使用者創(chuàng)建一個特定接口,并讓該類分別實現(xiàn)這些接口；ISP引例 - 星探查詢ISP引例 - 星探查詢接口隔離原則（ISP）迪米特原則（Law of Demeter，LoD)LoD引例 人數(shù)清點LoD引例 - 人數(shù)清點LoD引例 人數(shù)清點開閉原則（Open-Closed Principle , OCP）定義：軟件對擴展是開放的，對修改是關閉的。開發(fā)一個軟件時,應可以對其進行功能擴展(開放),在進行擴展的時候，不需要對原來的程序進行修

14、改（關閉）好處：在軟件可用性上非常靈活?？梢栽谲浖瓿珊髮浖M行擴展，加入新的功能。這樣，軟件就可通過不斷的增加新模塊滿足不斷變化的新需求由于不修改軟件原來的模塊，不用擔心軟件的穩(wěn)定性實現(xiàn)的主要原則抽象原則：把系統(tǒng)的所有可能的行為抽象成一個底層；由于可從抽象層導出一個或多個具體類來改變系統(tǒng)行為，因此對于可變部分，系統(tǒng)設計對擴展是開放的；可變性封裝原則：對系統(tǒng)所有可能發(fā)生變化的部分進行評估和分類，每一個可變的因素都單獨進行封裝;COP引例 - 書店銷售書籍COP引例 書店銷售書籍項目投產(chǎn)了，書籍正常銷售出去，書店也盈利了。從2008年開始，全球經(jīng)濟都開始下滑，對零售業(yè)影響還是比較大，書店為了生

15、存開始打折銷售：所有40元以上的書籍9折銷售,其他的8折銷售。對已經(jīng)投產(chǎn)的項目來說，這就是一個變化，我們來看看這樣的一個需求變化，我們該怎么去應對，有三種方法可以解決這個問題：修改接口：在IBook上新增加一個方法getOffPrice()；修改實現(xiàn)類：修改NovelBook類中的方法，直接在getPrice（)中實現(xiàn)打折處理；通過擴展實現(xiàn)變化。增加一個子類OffNovelBook，覆寫getPrice方法；COP引例 書店銷售書籍二 The Strategy Pattern策略模式： 定義了算法族，分別封裝起來，讓他們之間可以互相替換，此模式讓算法的變化獨立于使用算法的客戶.傳統(tǒng)策略算法實現(xiàn)

16、的缺點：使用算法的類復雜而難于維護；不同的時候需要不同的算法;算法的實現(xiàn)和使用算法的對象緊緊耦合在一起；將每種算法的實現(xiàn)都剝離出來構成一個個獨立算法對象，再從這些對象中抽象出公共算法接口，最后將算法接口組合到使用算法類中。策略模式的意圖和適用性意圖：定義一系列算法，一個個進行封裝，并使其可相互替換.策略模式使得算法可獨立于使用它的客戶而變化適用場合在軟件構建過程中，某些對象使用的算法可能多種多樣,經(jīng)常改變，如果將這些算法都編碼到對象中，將會使得對象變得異常復雜;而且有時候支持不同的算法也是一個性能負擔；如何在運行時根據(jù)需要透明地更改對象的算法？如何將算法與對象本身解耦，從而避免上述問題？策略模

17、式很好地解決了這兩個問題；策略模式的結構策略模式的參與者Strategy定義所有支持算法的公共接口Context使用該接口調(diào)用某ConcreteStrategy定義的算法ConcreteStrategy以Strategy接口實現(xiàn)某具體算法Context用一個ConcreteStrategy對象來配置維護一個對Strategy對象的引用可定義一個接口來讓Strategy訪問它的數(shù)據(jù)策略模式的效果分析算法和使用算法的對象相互分離，客戶程序可以在運行時動態(tài)選擇算法,代碼復用性好，便于修改和維護；用組合替代繼承,效果更好。若從Context直接生成子類，也可以實現(xiàn)對象的多種算法，但繼承使子類和父類緊密

18、耦合,使Context類難以理解、難以維護和難以擴展。策略模式采用組合方式，使Context和Strategy之間的依賴很小，更利于代碼復用；消除了冗長的條件語句序列，將不同的算法硬編碼進一個類中，選擇不同的算法必然要使用冗長的條件語句序列,采用策略模式將算法封裝在一個個獨立的Strategy類中消除了這些條件語句;策略模式的效果分析算法的動態(tài)選擇，Strategy模式可以提供相同行為的不同實現(xiàn),客戶可以根據(jù)不同的上下文從不同的策略中選擇算法;客戶必須了解不同的Strategy,一個客戶要選擇一個合適的Strategy就必須知道這些Strategy到底有什么不同；Strategy和Contex

19、t之間的通信開銷加大，根據(jù)算法的需要，Context必須向每個不同的具體Strategy類實例傳遞不同的參數(shù)，因此Strategy接口就要傳遞所有這些不同參數(shù)的集合，導致Context會創(chuàng)建和傳遞一些永遠用不到的參數(shù)；增加了類和對象數(shù)目，因為各種算法被抽取出來單獨成類,導致了對象數(shù)目增加，這種情況在算法較多時更加嚴重；使用的設計原則“開-閉”原則(OCP） 單一職責原則(SRP） 里氏替換原則(LSP) 接口隔離原則（ISP）PracticePractice三Observer PatternDesigning the Weather StationImplementing the Weathe

20、r Station建立接口；在WeatherData中實現(xiàn)主題接口；建立布告板；構造環(huán)境,啟動氣象站； push and pull Pull VS Push推方式：當狀態(tài)發(fā)生變化時，一次性將所有數(shù)據(jù)推給觀察者;不向觀察者開放內(nèi)部數(shù)據(jù)接口；只要是觀察者被注冊，觀察者將始終收到數(shù)據(jù)；拉方式：觀察者可根據(jù)需要取Subject提供的數(shù)據(jù);Subject必須提供數(shù)據(jù)接口（getter)；觀察者可按自己的要求決定是否接收數(shù)據(jù)；BULLET POINTSThe Observer Pattern defines a one-to-many relationship between objects。Subjec

21、ts, or as we also know them, Observables, update Observers using a common interface.Observers are loosely coupled in that the Observable knows nothing about them， other than that they implement the Observer Interface。You can push or pull data from the Observable when using the pattern （pull is consi

22、dered more “correct”）。BULLET POINTSDont depend on a specific order of notification for your Observers.Java has several implementations of the Observer Pattern， including the general purpose java。util.Observable。Watch out for issues with the java.util.Observable implementation.Dont be afraid to creat

23、e your own Observable implementation if needed.觀察者模式的由來將系統(tǒng)分割成一系列相互協(xié)作的類有也存在一些不足:需要維護相關對象間的一致性;為維持一致性而使各類緊密耦合，可能降低其可重用性；沒有理由限定依賴于某數(shù)據(jù)對象的對象數(shù)目, 對相同的數(shù)據(jù)對象可以有任意數(shù)目的不同用戶界面；觀察者模式的意圖和適用性意圖：定義對象間的一種一對多的依賴關系，當一個對象的狀態(tài)發(fā)生改變時,所有依賴于它的對象都得到通知并被自動更新適用場合當一個抽象模型有兩個方面， 一方面依賴于另一方面。將二者封裝在獨立對象中以使它們可以獨立被改變和復用;一個對象的改變需要同時改變其它對象

24、， 但不知道具體有多少對象有待改變；當一個對象必須通知其它對象,而它又不能假定其它對象是誰。換言之， 不希望這些對象是緊密耦合的；觀察者模式的結構觀察者模式的參與者Subject：抽象的主題，即被觀察的對象Observer:抽象的觀察者Concrete Subject：具體被觀察對象Concrete Observer：具體的觀察者注意：在觀察者模式中,Subject通過Attach和Detach方法添加或刪除所關聯(lián)的觀察者,并通過Notify進行更新，讓每個觀察者觀察到最新的狀態(tài);觀察者模式的效果分析應用場景對一個對象狀態(tài)的更新,需要其他對象同步更新,而且其他對象的數(shù)量動態(tài)可變；對象僅需要將自

25、己的更新通知給其他對象而不需要知道其他對象細節(jié)；優(yōu)點Subject和Observer之間是松偶合的,可以各自獨立改變；Subject在發(fā)送廣播通知時，無須指定具體的Observer，Observer可以自己決定是否要訂閱Subject的通知；高內(nèi)聚、低偶合；缺陷松偶合導致代碼關系不明顯，有時可能難以理解；如果一個Subject被大量Observer訂閱的話，在廣播通知的時候可能會有效率問題；四 Decorator PatternBULLET POINTSInheritance is one form of extension， but not necessarily the best way

26、to achieve flexibility in our designs。In our designs we should allow behavior to be extended without the need to modify existing code.Composition and delegation can often be used to add new behaviors at runtime。The Decorator Pattern provides an alternative to subclassing for extending behavior.The D

27、ecorator Pattern involves a set of decorator classes that are used to wrap concrete components.BULLET POINTSDecorator classes mirror the type of the components they decorate。 （In fact, they are the same type as the components they decorate， either through inheritance or interface implementation.)Decorators change the behavior of their components by adding new functionality before and/or after (or even in place of) method calls to the component.You can wrap a component with any number of decorators.Decorators are typically transparent to the client of the component； that is， u