軟件設(shè)計模式

軟件設(shè)計模式設(shè)計模式01簡介模式格式模式原則創(chuàng)作歷史相近術(shù)語四個要素目錄0305020406基本信息軟件設(shè)計模式（Designpattern），又稱設(shè)計模式，是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計經(jīng)驗(yàn)的總結(jié)。使用設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程序的重用性。簡介簡介設(shè)計模式(英語designpattern)是對面向?qū)ο笤O(shè)計中反復(fù)出現(xiàn)的問題的解決方案。這個術(shù)語是在1990年代由ErichGamma等人從建筑設(shè)計領(lǐng)域引入到計算機(jī)科學(xué)中來的。這個術(shù)語的含義還存有爭議。算法不是設(shè)計模式，因?yàn)樗惴ㄖ铝τ诮鉀Q問題而非設(shè)計問題。設(shè)計模式通常描述了一組相互緊密作用的類與對象。設(shè)計模式提供一種討論軟件設(shè)計的公共語言，使得熟練設(shè)計者的設(shè)計經(jīng)驗(yàn)可以被初學(xué)者和其他設(shè)計者掌握。設(shè)計模式還為軟件重構(gòu)提供了目標(biāo)。隨著軟件開發(fā)社群對設(shè)計模式的興趣日益增長，已經(jīng)出版了一些相關(guān)的專著，定期召開相應(yīng)的研討會，而且WardCunningham為此發(fā)明了WikiWiki用來交流設(shè)計模式的經(jīng)驗(yàn)。創(chuàng)作歷史創(chuàng)作歷史肯特·貝克和沃德·坎寧安在1987年利用克里斯托佛·亞歷山大在建筑設(shè)計領(lǐng)域里的思想開發(fā)了設(shè)計模式并把此思想應(yīng)用在Smalltalk中的圖形用戶接口的生成中。一年后ErichGamma在他的蘇黎世大學(xué)博士畢業(yè)論文中開始嘗試把這種思想改寫為適用于軟件開發(fā)。與此同時JamesCoplien在1989年至1991年也在利用相同的思想致力于C++的開發(fā)，而后于1991年發(fā)表了他的著作AdvancedC++Idioms。就在這一年ErichGamma得到了博士學(xué)位，然后去了美國，在那與RichardHelm,RalphJohnson,JohnVlissides合作出版了DesignPatterns-ElementsofReusableObject-OrientedSoftware一書，在此書中共收錄了23個設(shè)計模式。這四位作者在軟件開發(fā)領(lǐng)域里也以他們的匿名著稱GangofFour(四人幫，簡稱GoF),并且是他們在此書中的協(xié)作導(dǎo)致了軟件設(shè)計模式的突破。有時這個匿名GoF也會用于指代前面提到的那本書。模式格式模式格式盡管名稱和順序在不同的資料中各有不同，描述模式的格式大致分為以下四個主要部分：模式名稱（PatternName）：每一個模式都有自己的名字，模式的名字使得我們可以討論我們的設(shè)計。問題（Problem）：在面向?qū)ο蟮南到y(tǒng)設(shè)計過程中反復(fù)出現(xiàn)的特定場合，它導(dǎo)致我們采用某個模式。解決方案（Solution）：上述問題的解決方案，其內(nèi)容給出了設(shè)計的各個組成部分，它們之間的關(guān)系、職責(zé)劃分和協(xié)作方式。效果（Consequence）：采用該模式對軟件系統(tǒng)其他部分的影響，比如對系統(tǒng)的擴(kuò)充性、可移植性的影響。影響也包括負(fù)面的影響。別名（AlsoKnownAs）：一個模式可以有超過一個以上的名稱。這些名稱應(yīng)該要在這一節(jié)注明。動機(jī)（Motivation）：該模式應(yīng)該利用在哪種情況下是本節(jié)提供的方案（包括問題與來龍去脈）的責(zé)任。應(yīng)用（Applicability）結(jié)構(gòu)（Structure）：這部分常用類圖與互動圖闡述此模式。參與者（Participants）：這部分提供一份本模式用到的類與物件清單，與它們在設(shè)計下扮演的角色。相近術(shù)語模式列表創(chuàng)建模式結(jié)構(gòu)模式行為模式相近術(shù)語并發(fā)模式其他實(shí)時模式相近術(shù)語模式列表基礎(chǔ)模式委托模式接口模式代理模式創(chuàng)建模式抽象工廠模式(AbstractFactory),提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。生成器模式(Builder)，將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。工廠方法模式(FactoryMethod)，定義一個用于創(chuàng)建對象的接口，讓子類決定將哪一個類實(shí)例化。FactoryMethod使一個類的實(shí)例化延遲到其子類。原型模式(Prototype)，用原型實(shí)例指定創(chuàng)建對象的種類，并且通過拷貝這個原型來創(chuàng)建新的對象。單例模式(Singleton)，保證一個類僅有一個實(shí)例，并提供一個訪問它的全局訪問點(diǎn)。結(jié)構(gòu)模式適配器模式(Adapter)，將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。橋接模式(Bridge)，將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。組合模式(Composite)，將對象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。它使得客戶對單個對象和復(fù)合對象的使用具有一致性。容器模式修飾模式(Decorator)，動態(tài)地給一個對象添加一些額外的職責(zé)。就擴(kuò)展功能而言，它比生成子類方式更為靈活。擴(kuò)展性模式外觀模式享元模式管道與過濾器模式行為模式責(zé)任鏈模式(ChainofResponsibility)，為解除請求的發(fā)送者和接收者之間耦合，而使多個對象都有機(jī)會處理這個請求。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它。命令模式(Command)，將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進(jìn)行參數(shù)化；對請求排隊(duì)或記錄請求日志，以及支持可取消的操作?？吕锘Ｊ绞录O(jiān)聽器模式解釋器模式迭代器模式中介者模式備忘錄模式(Memento)，在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復(fù)到保存的狀態(tài)。觀察者模式(Observer)，定義對象間的一種一對多的依賴關(guān)系,以便當(dāng)一個對象的狀態(tài)發(fā)生改變時,所有依賴于并發(fā)模式模式Actionatadistance模式Balking模式Guardedsuspension模式Scheduler模式Readwritelock模式Doublecheckedlocking模式Disablejobrequestswhilerunningjob實(shí)時模式模式Scheduledtask模式Userinterface模式Disablejobrequestswhilerunningjob其他模型—視圖—控制器模式模式原則開－閉原則里氏代換原則合成復(fù)用原則依賴倒轉(zhuǎn)原則模式原則接口隔離原則迪米特法則單一職責(zé)原則模式原則開－閉原則此原則是由"BertrandMeyer"提出的。原文是："Softwareentitiesshouldbeopenforextension,butclosedformodification"。就是說模塊應(yīng)對擴(kuò)展開放，而對修改關(guān)閉。模塊應(yīng)盡量在不修改原(是"原"，指原來的代碼)代碼的情況下進(jìn)行擴(kuò)展。那么怎么擴(kuò)展呢?我們看工廠模式"factorypattern":假設(shè)中關(guān)村有一個賣盜版盤和毛片的小子，我們給他設(shè)計一"光盤銷售管理軟件"。我們應(yīng)該先設(shè)計一"光盤"接口。而盜版盤和毛片是其子類。小子通過"DiscFactory"來管理這些光盤。代碼為：有人要買盜版盤，怎么實(shí)現(xiàn)呢?如果有一天，這小子良心發(fā)現(xiàn)了，開始賣正版軟件。沒關(guān)系，我們只要再創(chuàng)建一個"光盤"的子類"正版軟件"就可以了。不需要修改原結(jié)構(gòu)和代碼。怎么樣?對擴(kuò)展開放，對修改關(guān)閉。"開-閉原則"工廠模式是對具體產(chǎn)品進(jìn)行擴(kuò)展，有的項(xiàng)目可能需要更多的擴(kuò)展性，要對這個"工廠"也進(jìn)行擴(kuò)展，那就成了"抽象工廠模式"。里氏代換原則里氏代換原則是由"BarbaraLiskov"提出的。如果調(diào)用的是父類的話，那么換成子類也完全可以運(yùn)行。比如：光盤d=new盜版盤();d.賣();要將"盜版盤"類改為"毛片"類，沒問題，完全可以運(yùn)行。Java編譯程序會檢查程序是否符合里氏代換原則。還記得java繼承的一個原則嗎?子類override方法的訪問權(quán)限不能小于父類對應(yīng)方法的訪問權(quán)限。比如"光盤"中的方法"賣"訪問權(quán)限是"public"，那么"盜版盤"和"毛片"中的"賣"方法就不能是protected或private，編譯不能通過。為什么要這樣呢?你想?。喝绻?盜版盤"的"賣"方法是private。那么下面這段代碼就不能執(zhí)行了：光盤d=new盜版盤();d.賣();可以說：里氏代換原則是繼承復(fù)用的一個基礎(chǔ)。合成復(fù)用原則就是說要少用繼承，多用合成關(guān)系來實(shí)現(xiàn)。我曾經(jīng)這樣寫過程序：有幾個類要與數(shù)據(jù)庫打交道，就寫了一個數(shù)據(jù)庫操作的類，然后別的跟數(shù)據(jù)庫打交道的類都繼承這個。結(jié)果后來，我修改了數(shù)據(jù)庫操作類的一個方法，各個類都需要改動。"牽一發(fā)而動全身"!面向?qū)ο笫且巡▌酉拗圃诒M量小的范圍。在Java中，應(yīng)盡量針對Interface編程，而非實(shí)現(xiàn)類。這樣，更換子類不會影響調(diào)用它方法的代碼。要讓各個類盡可能少的跟別人，"不要與陌生人說話"。這樣，城門失火，才不至于殃及池魚。擴(kuò)展性和維護(hù)性才能提高理解了這些原則，再看設(shè)計模式，只是在具體問題上怎么實(shí)現(xiàn)這些原則而已。張無忌學(xué)太極拳，忘記了所有招式，打倒了"玄冪二老"，所謂"心中無招"。設(shè)計模式可謂招數(shù)，如果先學(xué)通了各種模式，又忘掉了所有模式而隨心所欲，可謂OO之最高境界。呵呵，搞笑，搞笑依賴倒轉(zhuǎn)原則抽象不應(yīng)該依賴與細(xì)節(jié)，細(xì)節(jié)應(yīng)當(dāng)依依賴倒轉(zhuǎn)原則要針對接口編程，而不是針對實(shí)現(xiàn)編程。傳遞參數(shù)，或者在組合聚合關(guān)系中，盡量引用層次高的類。主要是在構(gòu)造對象時可以動態(tài)的創(chuàng)建各種具體對象，當(dāng)然如果一些具體類比較穩(wěn)定，就不必在弄一個抽象類做它的父類，這樣有畫舌添足的感覺接口隔離原則定制服務(wù)的例子，每一接口隔離原則一種角色，不多不少，不干不該干的事，該干的事都要干抽象類抽象類不會有實(shí)例單一職責(zé)原則概念：就一個類而言，應(yīng)該僅有一個引起它變化的原因。做編程的時候，如果講每一個類加上各種各樣的功能就意味著，無論任何需求要來，你都需要更改這個類，這樣會讓維護(hù)非常麻煩，復(fù)用不可能，也缺乏靈活性。如果一個類承擔(dān)的職責(zé)過多，就等于把這些職責(zé)耦合起來，一個職責(zé)變化可能會削弱或者抑制這個類完成其他職責(zé)的能力。這種耦合會導(dǎo)致脆弱的設(shè)計，當(dāng)變化發(fā)生時，設(shè)計會遭到很多意想不到的破壞。迪米特法則(也稱為最小知識原則)概念：一個軟件實(shí)體應(yīng)當(dāng)盡可能的少與其他實(shí)體發(fā)生相互作用。每一個軟件單位對其他軟件單位都只有最少的知識，而且局限于那些與本單位密切相關(guān)的軟件單位。迪米特法則的初衷在于降低類之間的耦合。由于每個類盡量減少對其他類的依賴，因此，很容易使得系統(tǒng)的功能模塊功能獨(dú)立，相互之間不存在（或很少有）依賴關(guān)系。迪米特法則不希望類之間建立直接的。如果有真的需要建立的，也希望能通過他的友元類來轉(zhuǎn)達(dá)。因此，應(yīng)用迪米特法則有可能造成一個后果就是：系統(tǒng)中存在大量的中介類，這些類之所以存在完全是為了傳遞類之間的相互關(guān)系，這在一定程度上增加了系統(tǒng)的復(fù)雜度。四個要素四個要素設(shè)計模式使人們可以更加簡單方便地復(fù)用成功的設(shè)計和體系結(jié)構(gòu)。將已證實(shí)的技術(shù)表述成設(shè)計模式也會使新系統(tǒng)開發(fā)者更加容易理解其設(shè)計思路。模式名稱一個助記名，它用一兩個詞來描述模式的問題、解決方案和效果。命名一個新的模式增加了我們的設(shè)計詞匯。設(shè)計模式允