第一篇設計模式概述

軟件設計模式課程說明平時30%，期末70%平時：上機作業(yè)、考勤使用語言：java開發(fā)工具：Jcreator或者MyEclipce、JDK第一篇設計模式概述1.設計模式基礎2.設計模式的描述語言：ＵＭＬ３.設計模式的原則1.設計模式基礎設計模式的誕生與發(fā)展設計模式的定義與分類GoF設計模式簡介設計模式的優(yōu)點設計模式的誕生與發(fā)展模式的誕生與定義模式起源于建筑業(yè)而非軟件業(yè)模式(Pattern)之父——美國加利佛尼亞大學環(huán)境結構中心研究所所長ChristopherAlexander博士《APatternLanguage:Towns,Buildings,Construction》——253個建筑和城市規(guī)劃模式模式Context（模式可適用的前提條件）Theme或Problem（在特定條件下要解決的目標問題）Solution（對目標問題求解過程中各種物理關系的記述）設計模式的誕生與發(fā)展ChristopherAlexander設計模式的誕生與發(fā)展模式的誕生與定義Alexander給出了關于模式的經(jīng)典定義：每個模式都描述了一個在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心，通過這種方式，我們可以無數(shù)次地重用那些已有的解決方案，無需再重復相同的工作。Apatternisasolutiontoaprobleminacontext

模式是在特定環(huán)境中解決問題的一種方案設計模式的誕生與發(fā)展軟件模式1990年，軟件工程界開始關注ChristopherAlexander等在這一住宅、公共建筑與城市規(guī)劃領域的重大突破，最早將該模式的思想引入軟件工程方法學的是1991-1992年以“四人組(GangofFour，GoF，分別是ErichGamma,RichardHelm,RalphJohnson和JohnVlissides)”自稱的四位著名軟件工程學者，他們在1994年歸納發(fā)表了23種在軟件開發(fā)中使用頻率較高的設計模式，旨在用模式來統(tǒng)一溝通面向對象方法在分析、設計和實現(xiàn)間的鴻溝。設計模式的誕生與發(fā)展GangofFour設計模式的誕生與發(fā)展ErichGamma蘇黎世大學計算機科學博士，是Eclipse、JUnit

等項目主要技術負責人之一。JohnVlissides斯坦福大學計算機科學博士，原IBM研究員，于2005年11月24日因腦瘤去世，享年44歲。RalphJohnson

墨爾本大學計算機科學博士，原IBM研究員，現(xiàn)在波士頓顧問集團供職。RichardHelm康奈爾大學計算機科學博士，伊利諾伊大學教授。GangofFour設計模式的誕生與發(fā)展軟件模式軟件模式是將模式的一般概念應用于軟件開發(fā)領域，即軟件開發(fā)的總體指導思路或參照樣板。軟件模式并非僅限于設計模式，還包括架構模式、分析模式和過程模式等，實際上，在軟件生存期的每一個階段都存在著一些被認同的模式。軟件模式可以認為是對軟件開發(fā)這一特定“問題”的“解法”的某種統(tǒng)一表示，它和Alexander所描述的模式定義完全相同，即軟件模式等于一定條件下的出現(xiàn)的問題以及解法。軟件模式的基礎結構由4個部分構成：問題描述、前提條件（環(huán)境或約束條件）、解法和效果。設計模式的誕生與發(fā)展軟件模式設計模式的誕生與發(fā)展軟件模式軟件模式與具體的應用領域無關，在模式發(fā)現(xiàn)過程中需要遵循大三律(RuleofThree)，即只有經(jīng)過三個以上不同類型（或不同領域）的系統(tǒng)的校驗，一個解決方案才能從候選模式升格為模式。設計模式的誕生與發(fā)展設計模式的發(fā)展1987年，KentBeck和WardCunningham借鑒Alexander的模式思想在程序開發(fā)中開始應用一些模式，在OOPSLA會議上發(fā)表了他們的成果。1990年，OOPSLA與ECOOP聯(lián)合舉辦，ErichGamma和RichardHelm等人開始討論有關模式的話題(BruceAnderson主持)，“四人組”正式成立，并開始著手進行設計模式的分類整理工作。1991年，OOPSLA，BruceAnderson主持了首次針對設計模式的研討會。1992年，OOPSLA，Anderson再度主持研討會，模式已經(jīng)逐漸成為人們討論的話題。注:OOPSLA(Object-OrientedProgramming,Systems,Languages&Applications，面向對象編程、系統(tǒng)、語言和應用大會)，編程語言及軟件工程國際頂級會議，2010年改為SPLASH---Systems,Programming,LanguagesandApplications:SoftwareforHumanity設計模式的誕生與發(fā)展設計模式的發(fā)展1993年，KentBeck和GradyBooch

贊助了第一次關于設計模式的會議，這個設計模式研究組織發(fā)展成為著名的HillsideGroup研究組。1994年，由HillsideGroup發(fā)起，在美國伊利諾伊州(Illinois)的AllertonPark召開了第1屆關于面向對象模式的世界性會議，名為PLoP(PatternLanguagesofPrograms,編程語言模式會議)，簡稱PLoP‘94。1995年，PLoP‘95仍在伊利諾伊州的AllertonPark舉行，“四人組”出版了《設計模式：可復用面向對象軟件的基礎》(DesignPatterns:ElementsofReusableObject-OrientedSoftware)一書，本書成為1995年最搶手的面向對象書籍，也成為設計模式的經(jīng)典書籍。設計模式的誕生與發(fā)展設計模式的發(fā)展從1995年至今，設計模式在軟件開發(fā)中得以廣泛應用，在Sun的JavaSE/JavaEE平臺和Microsoft的.net平臺設計中就應用了大量的設計模式。誕生了越來越多的與設計模式相關的書籍和網(wǎng)站，設計模式也作為一門獨立的課程或作為軟件體系結構等課程的重要組成部分出現(xiàn)在國內外研究生和大學教育的課堂上。設計模式的定義與分類設計模式的定義設計模式(DesignPattern)是一套被反復使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設計經(jīng)驗的總結，使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。設計模式的定義與分類設計模式的基本要素設計模式一般有如下幾個基本要素：模式名稱、問題、目的、解決方案、效果、實例代碼和相關設計模式，其中的關鍵元素包括以下四個方面：模式名稱(Patternname)問題(Problem)解決方案(Solution)效果(Consequences)設計模式的定義與分類設計模式學習步驟本書將按照以下次序來學習設計模式：模式動機與定義模式結構與分析模式實例與解析模式效果與應用模式擴展設計模式的定義與分類設計模式的分類根據(jù)其目的（模式是用來做什么的）可分為創(chuàng)建型(Creational)，結構型(Structural)和行為型(Behavioral)三種：創(chuàng)建型模式主要用于創(chuàng)建對象。結構型模式主要用于處理類或對象的組合。行為型模式主要用于描述對類或對象怎樣交互和怎樣分配職責。設計模式的定義與分類設計模式的分類根據(jù)范圍，即模式主要是用于處理類之間關系還是處理對象之間的關系，可分為類模式和對象模式兩種：類模式處理類和子類之間的關系，這些關系通過繼承建立，在編譯時刻就被確定下來，是屬于靜態(tài)的。對象模式處理對象間的關系，這些關系在運行時刻變化，更具動態(tài)性。GoF設計模式簡介范圍\目的創(chuàng)建型模式結構型模式行為型模式類模式工廠方法模式（類）適配器模式解釋器模式模板方法模式對象模式抽象工廠模式建造者模式原型模式單例模式（對象）適配器模式橋接模式組合模式裝飾模式外觀模式享元模式代理模式職責鏈模式命令模式迭代器模式中介者模式備忘錄模式觀察者模式狀態(tài)模式策略模式訪問者模式GoF設計模式簡介創(chuàng)建型模式抽象工廠模式(AbstractFactory)建造者模式(Builder)工廠方法模式(FactoryMethod)原型模式(Prototype)單例模式(Singleton)GoF設計模式簡介結構型模式適配器模式(Adapter)橋接模式(Bridge)組合模式(Composite)裝飾模式(Decorator)外觀模式(Facade)享元模式(Flyweight)代理模式(Proxy)GoF設計模式簡介行為型模式職責鏈模式(ChainofResponsibility)命令模式(Command)解釋器模式(Interpreter)迭代器模式(Iterator)中介者模式(Mediator)備忘錄模式(Memento)觀察者模式(Observer)狀態(tài)模式(State)策略模式(Strategy)模板方法模式(TemplateMethod)訪問者模式(Visitor)設計模式的優(yōu)點

設計模式是從許多優(yōu)秀的軟件系統(tǒng)中總結出的成功的、能夠實現(xiàn)可維護性復用的設計方案，使用這些方案將避免我們做一些重復性的工作，而且可以設計出高質量的軟件系統(tǒng)。設計模式的主要優(yōu)點如下：設計模式融合了眾多專家的經(jīng)驗，并以一種標準的形式供廣大開發(fā)人員所用，它提供了一套通用的設計詞匯和一種通用的語言以方便開發(fā)人員之間溝通和交流，使得設計方案更加通俗易懂。對于使用不同編程語言的開發(fā)和設計人員可以通過設計模式來交流系統(tǒng)設計方案，每一個模式都對應一個標準的解決方案，設計模式可以降低開發(fā)人員理解系統(tǒng)的復雜度。設計模式的優(yōu)點設計模式使人們可以更加簡單方便地復用成功的設計和體系結構，將已證實的技術表述成設計模式也會使新系統(tǒng)開發(fā)者更加容易理解其設計思路。設計模式使得重用成功的設計更加容易，并避免那些導致不可重用的設計方案。設計模式使得設計方案更加靈活，且易于修改。設計模式的使用將提高軟件系統(tǒng)的開發(fā)效率和軟件質量，且在一定程度上節(jié)約設計成本。設計模式有助于初學者更深入地理解面向對象思想，一方面可以幫助初學者更加方便地閱讀和學習現(xiàn)有類庫與其他系統(tǒng)中的源代碼，另一方面還可以提高軟件的設計水平和代碼質量。２.設計模式的描述語言：ＵＭＬUML簡介UMLUnifiedModelingLanguage統(tǒng)一建模語言統(tǒng)一建模語言統(tǒng)一建模語言UML簡介UML的起源在一個現(xiàn)代化的工程中，人們要相互溝通和合作，就必須使用標準的工業(yè)化設計語言，用這些語言來對待開發(fā)的產(chǎn)品進行建模。建模過程把復雜的問題分解成為易于理解的小問題，以達到問題的求解。建模是開發(fā)優(yōu)秀軟件的所有活動中核心部分之一，其目的是把所要設計的結構和系統(tǒng)的行為聯(lián)系起來，并對系統(tǒng)的結構進行可視化控制。UML發(fā)展歷程從1994年起，GradyBooch和JamesRumbaugh在Rational軟件公司開始了UML的創(chuàng)建工作。1995年，OOSE方法和Objectory方法的創(chuàng)建者IvarJacobson也加入其中。UML三位創(chuàng)始人正式聯(lián)手，共同為創(chuàng)建一種標準的建模語言而一起工作，他們將開發(fā)出來的產(chǎn)品名稱定為UML（UnifiedModelingLanguage，統(tǒng)一建模語言）。UML簡介1997年11月，在IvarJacoboson、Grady

Booch以及JamesRumbaugh的共同努力下，UML1.1版本提交給OMG（ObjectManagementGroup,對象管理組織）并獲得通過，UML1.1成為業(yè)界標準的建模語言。2003年6月，OMG技術會議上UML2.0獲得正式通過，UML的發(fā)展與應用也上升到一個新的高度，越來越多的人開始學習和使用UML來進行軟件建模。UML

UML是一種分析設計語言，即一種建模語言。UML是由圖形符號表達的建模語言，其結構主要包括視圖、圖、模型元素和通用機制四部分。UML結構

（5-13）５類視圖視圖(View)用戶視圖：以用戶的觀點表示系統(tǒng)的目標，它是所有視圖的核心，該視圖描述系統(tǒng)的需求。結構視圖：表示系統(tǒng)的靜態(tài)行為，描述系統(tǒng)的靜態(tài)元素，如包、類與對象，以及它們之間的關系。行為視圖：表示系統(tǒng)的動態(tài)行為，描述系統(tǒng)的組成元素如對象在系統(tǒng)運行時的交互關系。實現(xiàn)視圖：表示系統(tǒng)中邏輯元素的分布，描述系統(tǒng)中物理文件以及它們之間的關系。環(huán)境視圖：表示系統(tǒng)中物理元素的分布，描述系統(tǒng)中硬件設備以及它們之間的關系。13種圖用例圖類圖對象圖包圖組合結構圖狀態(tài)圖活動圖順序圖通信圖定時圖交互概覽圖組件圖部署圖UML常用圖類圖順序圖狀態(tài)圖UML簡介UML的結構圖(Diagram)用例圖(UseCaseDiagram):

又稱為用況圖，對應于用戶視圖。在用例圖中，使用用例來表示系統(tǒng)的功能需求，用例圖用于表示多個外部執(zhí)行者與系統(tǒng)用例之間以及用例與用例之間的關系。用例圖與用例說明文檔(UseCaseSpecification)是常用的需求建模工具，也稱之為用例建模。類圖類圖(ClassDiagram)：對應于結構視圖。類圖使用類來描述系統(tǒng)的靜態(tài)結構，類圖包含類和它們之間的關系，它描述系統(tǒng)內所聲明的類，但它沒有描述系統(tǒng)運行時類的行為。用例圖與類圖是UML13種圖中使用頻率最高的兩種圖。UML簡介UML的結構圖(Diagram)對象圖(ObjectDiagram)：對應于結構視圖。對象圖是類圖在某一時刻的一個實例，用于表示類的對象實例之間的關系。包圖(PackageDiagram)：UML2.0新增圖，對應于結構視圖。包圖用于描述包與包之間的關系，包是一種把元素組織到一起的通用機制，如可以將多個類組織成一個包。狀態(tài)圖狀態(tài)圖(StateDiagram)：對應于行為視圖。狀態(tài)圖用來描述一個特定對象的所有可能狀態(tài)及其引起狀態(tài)轉移的事件。一個狀態(tài)圖包括一系列對象的狀態(tài)及狀態(tài)之間的轉換。順序圖順序圖(SequenceDiagram)：又稱為時序圖或序列圖，對應于行為視圖。順序圖用于表示對象之間的交互，重點表示對象之間發(fā)送消息的時間順序。UML簡介UML的結構圖(Diagram)通信圖(CommunicationDiagram)：在UML1.x中稱為協(xié)作圖，對應于行為視圖。通信圖展示了一組對象、這些對象間的連接以及它們之間收發(fā)的消息。它與順序圖是同構圖，也就是它們包含了相同的信息，只是表達方式不同而已，通信圖與順序圖可以相互轉換。

定時圖(TimingDiagram)：UML2.0新增圖，對應于行為視圖。定時圖采用一種帶數(shù)字刻度的時間軸來精確地描述消息的順序，而不是像順序圖那樣只是指定消息的相對順序，而且它還允許可視化地表示每條生命線的狀態(tài)變化，當需要對實時事件進行定義時，定時圖可以很好地滿足要求。

UML簡介UML的結構圖(Diagram)交互概覽圖(InteractionOverviewDiagram)：UML2.0新增圖，對應于行為視圖。交互概覽圖是交互圖與活動圖的混合物，可以把交互概覽圖理解為細化的活動圖，在其中的活動都通過一些小型的順序圖來表示；也可以將其理解為利用標明控制流的活動圖分解過的順序圖。在UML中，順序圖、通信圖、定時圖和交互概覽圖又統(tǒng)稱交互圖(InteractiveDiagram)，交互圖是表示各對象如何依據(jù)某種行為進行協(xié)作的模型，通常可以使用一個交互圖來表示和說明一個用例的行為。UML簡介UML的結構圖(Diagram)組件圖(ComponentDiagram)：又稱為構件圖，對應于實現(xiàn)視圖。組件圖用于描述每個功能所在的組件位置以及它們之間的關系。部署圖(DeploymentDiagram)：又稱為實施圖，對應于環(huán)境視圖。部署圖用于描述軟件中各個組件駐留的硬件位置以及這些硬件之間的交互關系。UML簡介UML的結構模型元素(Modelelement)在UML中，模型元素包括事物以及事物與事物之間的聯(lián)系。事物是UML的重要組成部分，它代表任何可以定義的東西。事物之間的關系把事物聯(lián)系在一起，組成有意義的結構模型。每一個模型元素都有一個與之相對應的圖形元素。同一個模型元素可以在不同的UML圖中使用，但是，無論在哪個圖中，同一個模型元素都保持相同的意義和符號。UML簡介UML的結構通用機制(Generalmechanism)UML提供的通用機制為模型元素提供額外的注釋、修飾和語義等，主要包括規(guī)格說明、修飾、公共分類和擴展機制四種。擴展機制允許用戶對UML進行擴展，以便一個特定的方法、過程、組織或用戶來使用。UML簡介UML的特點

工程化

規(guī)范化

可視化

系統(tǒng)化

文檔化

智能化文字能描述的需求UML能描述的需求其他符號能描述的需求類圖類與類圖類(Class)封裝了數(shù)據(jù)和行為，是面向對象的重要組成部分，它是具有相同屬性、操作、關系的對象集合的總稱。在系統(tǒng)中，每個類具有一定的職責，職責指的是類所擔任的任務，即類要完成什么樣的功能，要承擔什么樣的義務。一個類可以有多種職責，設計得好的類一般只有一種職責，在定義類的時候，將類的職責分解成為類的屬性和操作（即方法）。類的屬性即類的數(shù)據(jù)職責，類的操作即類的行為職責。類圖類與類圖在UML類圖中，類一般由三部分組成：類名：每個類都必須有一個名字，類名是一個字符串。屬性(Attributes)：屬性是指類的性質，即類的成員變量。類可以有任意多個屬性，也可以沒有屬性。操作(Operations)：操作是類的任意一個實例對象都可以使用的行為，操作是類的成員方法。可見性名稱:類型[=默認值]可見性名稱(參數(shù)列表):返回類型類圖類之間的關系關聯(lián)關系關聯(lián)關系(Association)是類與類之間最常用的一種關系，它是一種結構化關系，用于表示一類對象與另一類對象之間有聯(lián)系。在UML類圖中，用實線連接有關聯(lián)的對象所對應的類，在使用Java、C#和C++等編程語言實現(xiàn)關聯(lián)關系時，通常將一個類的對象作為另一個類的屬性。在使用類圖表示關聯(lián)關系時可以在關聯(lián)線上標注角色名。類圖類之間的關系關聯(lián)關系publicclassLoginForm{privateJButton

loginButton;……}publicclassJButton{

……}類圖類之間的關系雙向關聯(lián)默認情況下，關聯(lián)是雙向的。publicclassCustomer{privateProduct[]products;……}publicclassProduct{privateCustomercustomer;……}類圖類之間的關系單向關聯(lián)類的關聯(lián)關系也可以是單向的，單向關聯(lián)用帶箭頭的實線表示。publicclassCustomer{privateAddressaddress;……}publicclassAddress{……}類圖類之間的關系自關聯(lián)在系統(tǒng)中可能會存在一些類的屬性對象類型為該類本身，這種特殊的關聯(lián)關系稱為自關聯(lián)。publicclassNode{privateNodesubNode;……}類圖類之間的關系重數(shù)性關聯(lián)重數(shù)性關聯(lián)關系又稱為多重性關聯(lián)關系(Multiplicity)，表示一個類的對象與另一個類的對象連接的個數(shù)。在UML中多重性關系可以直接在關聯(lián)直線上增加一個數(shù)字表示與之對應的另一個類的對象的個數(shù)。表示方式多重性說明1..1表示另一個類的一個對象只與一個該類對象有關系0..*表示另一個類的一個對象與零個或多個該類對象有關系1..*表示另一個類的一個對象與一個或多個該類對象有關系0..1表示另一個類的一個對象沒有或只與一個該類對象有關系m..n表示另一個類的一個對象與最少m、最多n個該類對象有關系(m<=n)類圖類之間的關系重數(shù)性關聯(lián)publicclassForm{

privateButtonbuttons[];……}publicclassButton{…}類圖類之間的關系聚合關系聚合關系(Aggregation)表示一個整體與部分的關系。通常在定義一個整體類后，再去分析這個整體類的組成結構，從而找出一些成員類，該整體類和成員類之間就形成了聚合關系。在聚合關系中，成員類是整體類的一部分，即成員對象是整體對象的一部分，但是成員對象可以脫離整體對象獨立存在。在UML中，聚合關系用帶空心菱形的直線表示。類圖類之間的關系聚合關系publicclassCar{privateEngineengine;publicCar(Engineengine){

this.engine=engine;}

publicvoidsetEngine(Engineengine){

this.engine=engine;}……}publicclassEngine{

……}類圖類之間的關系組合關系組合關系(Composition)也表示類之間整體和部分的關系，但是組合關系中部分和整體具有統(tǒng)一的生存期。一旦整體對象不存在，部分對象也將不存在，部分對象與整體對象之間具有同生共死的關系。在組合關系中，成員類是整體類的一部分，而且整體類可以控制成員類的生命周期，即成員類的存在依賴于整體類。在UML中，組合關系用帶實心菱形的直線表示。類圖類之間的關系組合關系publicclassHead{privateMouthmouth;publicHead(){ mouth=newMouth();}……}publicclassMouth{

……}類圖類之間的關系依賴關系依賴關系(Dependency)是一種使用關系，特定事物的改變有可能會影響到使用該事物的其他事物，在需要表示一個事物使用另一個事物時使用依賴關系。大多數(shù)情況下，依賴關系體現(xiàn)在某個類的方法使用另一個類的對象作為參數(shù)。在UML中，依賴關系用帶箭頭的虛線表示，由依賴的一方指向被依賴的一方。類圖類之間的關系依賴關系publicclassDriver{publicvoiddrive(Carcar){

car.move();}

……}publicclassCar{publicvoidmove(){......}

……}類圖類之間的關系泛化關系泛化關系(Generalization)也就是繼承關系，也稱為“is-a-kind-of”關系，泛化關系用于描述父類與子類之間的關系，父類又稱作基類或超類，子類又稱作派生類。在UML中，泛化關系用帶空心三角形的直線來表示。在代碼實現(xiàn)時，使用面向對象的繼承機制來實現(xiàn)泛化關系，如在Java語言中使用extends關鍵字、在C++/C#中使用冒號“：”來實現(xiàn)。類圖類之間的關系泛化關系publicclassPerson{protectedStringname;protectedintage;publicvoidmove(){

……}publicvoidsay(){

……}}publicclassStudentextendsPerson{privateStringstudentNo;publicvoidstudy(){

……}}類圖類之間的關系接口與實現(xiàn)關系接口之間也可以有與類之間關系類似的繼承關系和依賴關系，但是接口和類之間還存在一種實現(xiàn)關系(Realization)，在這種關系中，類實現(xiàn)了接口，類中的操作實現(xiàn)了接口中所聲明的操作。在UML中，類與接口之間的實現(xiàn)關系用帶空心三角形的虛線來表示。

類圖類之間的關系接口與實現(xiàn)關系publicinterfaceVehicle{publicvoidmove();}publicclassShipimplementsVehicle{publicvoidmove(){

……}}publicclassCarimplementsVehicle{publicvoidmove(){

……}}類圖類圖實例實例說明某基于Java語言的C/S軟件需要提供注冊功能，該功能簡要描述如下：用戶通過注冊界面(RegisterForm)輸入個人信息，用戶點擊“注冊”按鈕后將輸入的信息通過一個封裝用戶輸入數(shù)據(jù)的對象(UserDTO)傳遞給操作數(shù)據(jù)庫的數(shù)據(jù)訪問類(DAO)，為了提高系統(tǒng)的擴展性，針對不同的數(shù)據(jù)庫可能需要提供不同的數(shù)據(jù)訪問類，因此提供了數(shù)據(jù)訪問類接口，如IUserDAO，每一個具體數(shù)據(jù)訪問類都是某一個數(shù)據(jù)訪問類接口的實現(xiàn)類，如OracleUserDAO就是一個專門用于訪問Oracle數(shù)據(jù)庫的數(shù)據(jù)訪問類。根據(jù)以上描述繪制類圖。為了簡化類圖，個人信息僅包括賬號(userAccount)和密碼(userPassword)，且界面類無須涉及界面細節(jié)元素。類圖類圖實例實例解析類圖注釋(Comment)順序圖順序圖是最常用的系統(tǒng)動態(tài)建模工具之一，也是使用頻率最高的交互圖。它用于表示對象之間的動態(tài)交互，而且以圖形化的方式描述了對象間消息傳遞的時間順序。

順序圖順序圖定義

順序圖(SequenceDiagram)是一種強調對象間消息傳遞次序的交互圖，又稱為時序圖或序列圖。順序圖以圖形化的方式描述了在一個用例或操作的執(zhí)行過程中對象如何通過消息相互交互，說明了消息如何在對象之間被發(fā)送和接收以及發(fā)送的順序。順序圖允許直觀地表示出對象的生存期，在生存期內，對象可以對輸入消息做出響應，還可以發(fā)送信息。順序圖順序圖定義

在軟件系統(tǒng)建模中，順序圖的使用很靈活，通常包括如下兩種順序圖：需求分析階段的順序圖：主要用于描述用例中對象之間的交互，可以使用自然語言來繪制，用于細化需求，它從業(yè)務的角度進行建模，用描述性的文字敘述消息的內容。系統(tǒng)設計階段的順序圖：確切表示系統(tǒng)設計中對象之間的交互，考慮到具體的系統(tǒng)實現(xiàn)，對象之間通過方法調用傳遞消息。順序圖順序圖組成元素與繪制在UML中，順序圖將交互關系表示為一個二維圖，縱向是時間軸，時間沿豎線向下延伸；橫向軸表示了在交互過程中的獨立對象，對象的活動用生命線表示。順序圖由執(zhí)行者(Actor)、生命線(Lifeline)、對象(Object)、激活框(Activation)和消息(Message)等元素組成。順序圖順序圖組成元素與繪制執(zhí)行者是交互的發(fā)起人，使用與用例圖一樣的“小人”符號表示，在有些交互過程中無須使用執(zhí)行者。生命線用一條縱向虛線表示。對象表示為一個矩形，其中對象名稱標有下劃線。激活是過程的執(zhí)行，包括等待過程執(zhí)行的時間。在順序圖中激活部分替換生命線，使用長條的矩形表示。消息是對象之間的通信，是兩個對象之間的單路通信，是從發(fā)送者到接收者之間的控制信息流。消息在順序圖中由有標記的箭頭表示，箭頭從一個對象的生命線指向另一個對象的生命線，消息按時間順序在圖中從上到下排列。順序圖順序圖組成元素與繪制一個復雜的順序圖可以劃分為幾個小塊，每一個小塊稱為一個交互片段(InteractionFragment)。每個交互片段由一個大方框包圍，在方框左上角的間隔區(qū)內標注該交互片段的操作類型，該操作類型用操作符表示，常用的操作符包括：1)alt:多條路徑，條件為真時執(zhí)行。2)opt:任選，僅當條件為真時執(zhí)行。3)par:并行，每一片段都并發(fā)執(zhí)行。4)loop:循環(huán)，片段可多次執(zhí)行。順序圖順序圖組成元素與繪制實例順序圖順序圖組成元素與繪制在順序圖中，有的消息對應于激活，表示它將會激活一個對象，這種消息稱為調用消息(CallMessage)；如果消息沒有對應激活框，表示它不是一個調用消息，不會引發(fā)其他對象的活動，這種消息稱為發(fā)送消息(SendMessage)；如果對象的一個方法調用了自己的另一個方法時，消息是由對象發(fā)送給自身，這種消息稱為自身消息(SelfCallMessage)。順序圖中的消息還包括創(chuàng)建消息和銷毀消息，創(chuàng)建消息用于使用new關鍵字創(chuàng)建另一個對象，而銷毀消息用于調用對象的銷毀方法將一個對象從內存中銷毀。順序圖順序圖實例實例說明某基于JavaEE的B/S系統(tǒng)需要提供登錄功能，該功能簡要描述如下：用戶打開登錄界面login.jsp輸入數(shù)據(jù)，向系統(tǒng)提交請求，系統(tǒng)通過Servlet獲取請求數(shù)據(jù)，將數(shù)據(jù)傳遞給業(yè)務對象，業(yè)務對象接收數(shù)據(jù)后再將數(shù)據(jù)傳遞給數(shù)據(jù)訪問對象，數(shù)據(jù)訪問對象對數(shù)據(jù)庫進行操作，查詢用戶信息，再返回查詢結果。根據(jù)以上描述繪制順序圖。順序圖順序圖實例實例解析需求分析順序圖順序圖實例實例解析-系統(tǒng)設計狀態(tài)圖對于系統(tǒng)中那些具有多種狀態(tài)的對象，狀態(tài)圖是一種常用的建模手段。狀態(tài)圖用于描述對象的各種狀態(tài)以及狀態(tài)之間的轉換。右圖：某OA系統(tǒng)請假條對象狀態(tài)圖狀態(tài)圖狀態(tài)圖定義狀態(tài)圖(StatechartDiagram)用來描述一個特定對象的所有可能狀態(tài)及其引起狀態(tài)轉移的事件。我們通常用狀態(tài)圖來描述單個對象的行為，它確定了由事件序列引出的狀態(tài)序列，但并不是所有的類都需要使用狀態(tài)圖來描述它的行為，只有那些具有重要交互行為的類，我們才會使用狀態(tài)圖來描述，一個狀態(tài)圖包括一系列的狀態(tài)及狀態(tài)之間的轉移。狀態(tài)圖狀態(tài)圖定義大多數(shù)面向對象技術都使用狀態(tài)圖來描述一個對象在其生命周期中的行為，對象從產(chǎn)生到結束，可以處于一系列不同的狀態(tài)。狀態(tài)影響對象的行為，當這些狀態(tài)的數(shù)目有限時，就可以用狀態(tài)圖來建模對象的行為，狀態(tài)圖顯示了單個類的生命周期，在不同狀態(tài)下對象可能具有不同的行為。狀態(tài)圖適用于描述在不同用例之間的對象行為，但并不適合于描述包括若干協(xié)作的對象行為，因為一個狀態(tài)圖只能用于描述一個類的對象狀態(tài)，如果涉及到多個不同類的對象，則需要使用活動圖。狀態(tài)圖狀態(tài)圖組成元素與繪制狀態(tài)(State)：又稱為中間狀態(tài)，用圓角矩形框表示，在一個狀態(tài)圖中可有多個狀態(tài)，每個狀態(tài)包含兩格：上格放置狀態(tài)名稱，下格說明處于該狀態(tài)時對象可以進行的活動(Action)。初始狀態(tài)(InitialState)：又稱為初態(tài)，用一個黑色的實心圓圈表示，在一個狀態(tài)圖中只能夠有一個初始狀態(tài)。結束狀態(tài)(FinalState)：又稱為終止狀態(tài)或終態(tài)，用一個實心圓外加一個圓圈表示，在一個狀態(tài)圖中可能有多個結束狀態(tài)。轉移(Transition)：用從一個狀態(tài)到另一個狀態(tài)之間的連線和箭頭說明狀態(tài)的轉移情況，并用文字說明引發(fā)這個狀態(tài)變化的相應事件是什么。事件有可能在特定的條件下發(fā)生，在UML中這樣的條件稱為守護條件(GuardCondition)，發(fā)生事件時的處理也稱為動作(Action)。狀態(tài)之間的轉移可帶有標注，由三部分組成（每一部分都可省略），其語法為：事件名[條件]/動作名。狀態(tài)圖狀態(tài)圖組成元素與繪制在一個狀態(tài)圖中，一個狀態(tài)也可以被細分為多個子狀態(tài)，包含多個子狀態(tài)的狀態(tài)稱為復合狀態(tài)。狀態(tài)圖狀態(tài)圖組成元素與繪制在繪制對象的狀態(tài)圖時，需要考慮如下三個問題：對象有哪些有意義的狀態(tài)？不同狀態(tài)下對象具有哪些行為？這些狀態(tài)之間如何轉換？狀態(tài)圖狀態(tài)圖實例實例說明某信用卡系統(tǒng)賬戶具有使用狀態(tài)和凍結狀態(tài)，其中使用狀態(tài)又包括正常狀態(tài)和透支狀態(tài)兩種子狀態(tài)。如果賬戶余額小于零則進入透支狀態(tài)，透支狀態(tài)時既可以存款又可以取款，但是透支金額不能超過5000元；如果余額大于零則進入正常狀態(tài)，正常狀態(tài)時既可以存款又可以取款；如果連續(xù)透支100天，則進入凍結狀態(tài)，凍結狀態(tài)下既不能存款又不能取款，必須要求銀行工作人員解凍。用戶可以在使用狀態(tài)或凍結狀態(tài)下請求注銷賬戶。根據(jù)上述要求，繪制賬戶類的狀態(tài)圖。狀態(tài)圖狀態(tài)圖實例實例解析３.設計模式的原則設計原則概述單一職責原則開閉原則里氏代換原則依賴倒轉原則接口隔離原則合成復用原則迪米特法則為什么要有原則軟件的可維護性和可復用性知名軟件大師RobertC.Martin認為一個可維護性(Maintainability)較低的軟件設計，通常由于如下4個原因造成：過于僵硬(Rigidity)過于脆弱(Fragility)復用率低(Immobility)黏度過高(Viscosity)RobertC.Martin為什么要有原則軟件的可維護性和可復用性軟件工程和建模大師PeterCoad認為，一個好的系統(tǒng)設計應該具備如下三個性質：可擴展性(Extensibility)靈活性(Flexibility)可插入性(Pluggability)PeterCoad為什么要有原則軟件的可維護性和可復用性

軟件的復用(Reuse)或重用擁有眾多優(yōu)點，如可以提高軟件的開發(fā)效率，提高軟件質量，節(jié)約開發(fā)成本，恰當?shù)膹陀眠€可以改善系統(tǒng)的可維護性。面向對象設計復用的目標在于實現(xiàn)支持可維護性的復用。

在面向對象的設計里面，可維護性復用都是以面向對象設計原則為基礎的，這些設計原則首先都是復用的原則，遵循這些設計原則可以有效地提高系統(tǒng)的復用性，同時提高系統(tǒng)的可維護性。面向對象設計原則概述軟件的可維護性和可復用性面向對象設計原則和設計模式也是對系統(tǒng)進行合理重構的指南針，重構(Refactoring)是在不改變軟件現(xiàn)有功能的基礎上，通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性。MartinFowler七大原則相互依賴互相補充設計原則名稱設計原則簡介重要性單一職責原則(SingleResponsibilityPrinciple,SRP)類的職責要單一，不能將太多的職責放在一個類中★★★★☆開閉原則(Open-ClosedPrinciple,OCP)軟件實體對擴展是開放的，但對修改是關閉的，即在不修改一個軟件實體的基礎上去擴展其功能★★★★★里氏代換原則(LiskovSubstitutionPrinciple,LSP)在軟件系統(tǒng)中，一個可以接受基類對象的地方必然可以接受一個子類對象★★★★☆依賴倒轉原則(DependencyInversionPrinciple,DIP)要針對抽象層編程，而不要針對具體類編程★★★★★接口隔離原則(InterfaceSegregationPrinciple,ISP)使用多個專門的接口來取代一個統(tǒng)一的接口★★☆☆☆合成復用原則(CompositeReusePrinciple,CRP)在系統(tǒng)中應該盡量多使用組合和聚合關聯(lián)關系，盡量少使用甚至不使用繼承關系★★★★☆迪米特法則(LawofDemeter,LoD)一個軟件實體對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通信，那么這兩個類就不應當發(fā)生直接的相互作用，而是通過引入一個第三者發(fā)生間接交互★★★☆☆單一職責原則單一職責原則定義單一職責原則(SingleResponsibilityPrinciple,SRP)定義如下：一個對象應該只包含單一的職責，并且該職責被完整地封裝在一個類中。其英文定義為：Everyobjectshouldhaveasingleresponsibility,andthatresponsibilityshouldbeentirelyencapsulatedbytheclass.另一種定義方式如下：就一個類而言，應該僅有一個引起它變化的原因。其英文定義為：Thereshouldneverbemorethanonereasonforaclasstochange.單一職責原則單一職責原則分析一個類（或者大到模塊，小到方法）承擔的職責越多，它被復用的可能性越小，而且如果一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作。類的職責主要包括兩個方面：數(shù)據(jù)職責和行為職責，數(shù)據(jù)職責通過其屬性來體現(xiàn)，而行為職責通過其方法來體現(xiàn)。單一職責原則是實現(xiàn)高內聚、低耦合的指導方針，在很多代碼重構手法中都能找到它的存在，它是最簡單但又最難運用的原則，需要設計人員發(fā)現(xiàn)類的不同職責并將其分離，而發(fā)現(xiàn)類的多重職責需要設計人員具有較強的分析設計能力和相關重構經(jīng)驗。單一職責原則單一職責原則實例實例說明某基于Java的C/S系統(tǒng)的“登錄功能”通過如下登錄類(Login)實現(xiàn)：現(xiàn)使用單一職責原則對其進行重構。單一職責原則單一職責原則實例實例解析開閉原則開閉原則定義開閉原則(Open-ClosedPrinciple,OCP)定義如下：一個軟件實體應當對擴展開放，對修改關閉。也就是說在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展，即實現(xiàn)在不修改源代碼的情況下改變這個模塊的行為。其英文定義為：Softwareentitiesshouldbeopenforextension,butclosedformodification.開閉原則開閉原則分析開閉原則由BertrandMeyer于1988年提出，它是面向對象設計中最重要的原則之一。在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類。開閉原則開閉原則分析抽象化是開閉原則的關鍵。開閉原則還可以通過一個更加具體的“對可變性封裝原則”來描述，對可變性封裝原則(PrincipleofEncapsulationofVariation,EVP)要求找到系統(tǒng)的可變因素并將其封裝起來。

開閉原則開閉原則實例實例說明某圖形界面系統(tǒng)提供了各種不同形狀的按鈕，客戶端代碼可針對這些按鈕進行編程，用戶可能會改變需求要求使用不同的按鈕，原始設計方案如圖所示：現(xiàn)對該系統(tǒng)進行重構，使之滿足開閉原則的要求。開閉原則開閉原則實例實例解析里氏代換原則里氏代換原則定義里氏代換原則(LiskovSubstitutionPrinciple,LSP)有兩種定義方式，第一種定義方式相對嚴格，其定義如下：如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1都代換成o2時，程序P的行為沒有變化，那么類型S是類型T的子類型。其英文定義為：Ifforeachobjecto1oftypeSthereisanobjecto2oftypeTsuchthatforallprogramsPdefinedintermsofT,thebehaviorofPisunchangedwheno1issubstitutedforo2thenSisasubtypeofT.第二種更容易理解的定義方式如下：所有引用基類（父類）的地方必須能透明地使用其子類的對象。其英文定義為：Functionsthatusepointersorreferencestobaseclassesmustbeabletouseobjectsofderivedclasseswithoutknowingit.里氏代換原則里氏代換原則分析里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士、麻省理工學院教授BarbaraLiskov和卡內基.梅隆大學JeannetteWing教授于1994年提出。其原文如下：Letq(x)beapropertyprovableaboutobjectsxoftypeT.Thenq(y)shouldbetrueforobjectsyoftypeSwhereSisasubtypeofT.芭芭拉·利斯科夫（BarbaraLiskov），美國計算機科學家，2008年圖靈獎得主，2004年約翰.馮諾依曼獎得主，美國工程院院士，美國藝術與科學院院士，美國計算機協(xié)會會士?，F(xiàn)任麻省理工學院電子電氣與計算機科學系教授。她是美國第一個計算機科學女博士。周以真（JeannetteM.Wing），美國計算機科學家，卡內基.梅隆大學教授，美國國家自然基金會計算與信息科學工程部助理部長，ACM和IEEE會士。里氏代換原則里氏代換原則分析里氏代換原則可以通俗表述為：在軟件中如果能夠使用基類對象，那么一定能夠使用其子類對象。把基類都替換成它的子類，程序將不會產(chǎn)生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類的話，那么它不一定能夠使用基類。里氏代換原則是實現(xiàn)開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。里氏代換原則里氏代換原則分析喜歡動物喜歡貓因為貓是動物里氏代換原則里氏代換原則實例實例說明某系統(tǒng)需要實現(xiàn)對重要數(shù)據(jù)（如用戶密碼）的加密處理，在數(shù)據(jù)操作類(DataOperator)中需要調用加密類中定義的加密算法，系統(tǒng)提供了兩個不同的加密類，CipherA和CipherB，它們實現(xiàn)不同的加密方法，在DataOperator中可以選擇其中的一個實現(xiàn)加密操作。如圖所示：里氏代換原則里氏代換原則實例實例說明如果需要更換一個加密算法類或者增加并使用一個新的加密算法類，如將CipherA改為CipherB，則需要修改客戶類Client和數(shù)據(jù)操作類DataOperator的源代碼，違背了開閉原則?，F(xiàn)使用里氏代換原則對其進行重構，使得系統(tǒng)可以靈活擴展，符合開閉原則。里氏代換原則里氏代換原則實例實例解析依賴倒轉原則依賴倒轉原則定義依賴倒轉原則(DependenceInversionPrinciple,DIP)的定義如下：高層模塊不應該依賴低層模塊，它們都應該依賴抽象。抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象。其英文定義為：Highlevelmodulesshouldnotdependuponlowlevelmodules,bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails,detailsshoulddependuponabstractions.另一種表述為：要針對接口編程，不要針對實現(xiàn)編程。其英文定義為：Programtoaninterface,notanimplementation.依賴倒轉原則依賴倒轉原則分析依賴倒轉原則是RobertC.Martin在1996年為《C++Reporter》所寫的專欄EngineeringNotebook的第三篇，后來加入到他在2002年出版的經(jīng)典著作《AgileSoftwareDevelopment,Principles,Patterns,andPractices》中。依賴倒轉原則依賴倒轉原則分析簡單來說，依賴倒轉原則就是指：代碼要依賴于抽象的類，而不要依賴于具體的類；要針對接口或抽象類編程，而不是針對具體類編程。實現(xiàn)開閉原則的關鍵是抽象化，并且從抽象化導出具體化實現(xiàn)，如果說開閉原則是面向對象設計的目標的話，那么依賴倒轉原則就是面向對象設計的主要手段。依賴倒轉原則依賴倒轉原則分析依賴倒轉原則的常用實現(xiàn)方式之一是在代碼中使用抽象類，而將具體類放在配置文件中。“將抽象放進代碼，將細節(jié)放進元數(shù)據(jù)”PutAbstractionsinCode,DetailsinMetadata（《程序員修煉之道：從小工到專家》(ThePragmaticprogrammer:fromjourneymantomaster)）依賴倒轉原則依賴倒轉原則分析類之間的耦合零耦合關系具體耦合關系抽象耦合關系依賴倒轉原則要求客戶端依賴于抽象耦合，以抽象方式耦合是依賴倒轉原則的關鍵。依賴倒轉原則依賴倒轉原則分析依賴注入構造注入(ConstructorInjection)：通過構造函數(shù)注入實例變量。設值注入(SetterInjection)：通過Setter方法注入實例變量。接口注入(InterfaceInjection)：通過接口方法注入實例變量。

依賴倒轉原則依賴倒轉原則實例實例說明某系統(tǒng)提供一個數(shù)據(jù)轉換模塊，可以將來自不同數(shù)據(jù)源的數(shù)據(jù)轉換成多種格式，如可以轉換來自數(shù)據(jù)庫的數(shù)據(jù)(DatabaseSource)、也可以轉換來自文本文件的數(shù)據(jù)(TextSource)，轉換后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。依賴倒轉原則依賴倒轉原則實例實例說明由于需求的變化，該系統(tǒng)可能需要增加新的數(shù)據(jù)源或者新的文件格式，每增加一個新的類型的數(shù)據(jù)源或者新的類型的文件格式，客戶類MainClass都需要修改源代碼，以便使用新的類，但違背了開閉原則?，F(xiàn)使用依賴倒轉原則對其進行重構。依賴倒轉原則依賴倒轉原則實例實例解析接口隔離原則接口隔離原則定義接口隔離原則(InterfaceSegregationPrinciple,ISP)的定義如下：客戶端不應該依賴那些它不需要的接口。其英文定義為：Clientsshouldnotbeforcedtodependuponinterfacesthattheydonotuse.注意，在該定義中的接口指的是所定義的方法。另一種定義方法如下：一旦一個接口太大，則需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。其英文定義為：Onceaninterfacehasgottentoo'fat'itneedstobesplitintosmallerandmorespecificinterfaces

sothatanyclientsoftheinterfacewillonlyknowaboutthemethodsthatpertaintothem.接口隔離原則接口隔離原則分析接口隔離原則是指使用多個專門的接口，而不使用單一的總接口。每一個接口應該承擔一種相對獨立的角色，不多不少，不干不該干的事，該干的事都要干。(1)一個接口就只代表一個角色，每個角色都有它特定的一個接口，此時這個原則可以叫做“角色隔離原則”。(2)接口僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的接口，而不要提供大的總接口。接口隔離原則接口隔離原則分析使用接口隔離原則拆分接口時，首先必須滿足單一職責原則，將一組相關的操作定義在一個接口中，且在滿足高內聚的前提下，接口中的方法越少越好?？梢栽谶M行系統(tǒng)設計時采用定制服務的方式，即為不同的客戶端提供寬窄不同的接口，只提供用戶需要的行為，而隱藏用戶不需要的行為。接口隔離原則接口隔離原則實例實例說明下圖展示了一個擁有多個客戶類的系統(tǒng)，在系統(tǒng)中定義了一個巨大的接口（胖接口）AbstractService來服務所有的客戶類?？梢允褂媒涌诟綦x原則對其進行重構。接口隔離原則接口隔離原則實例實例解析合成復用原則合成復用原則定義合成復用原則(CompositeReusePrinciple,CRP)又稱為組合/聚合復用原則(Composition/AggregateReusePrinciple,CARP)，其定義如下：盡量使用對象組合，而不是繼承來達到復用的目的。其英文定義為：Favorcompositionofobjectsoverinheritanceasareusemechanism.合成復用原則合成復用原則分析合成復用原則就是指在一個新的對象里通過關聯(lián)關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到復用其已有功能的目的。簡言之：要盡量使用組合/聚合關系，少用繼承。合成復用原則合成復用原則分析在面向對象設計中，可以通過兩種基本方法在不同的環(huán)境中復用已有的設計和實現(xiàn)，即通過組合/聚合關系或通過繼承。繼承復用：實現(xiàn)簡單，易于擴展。破壞系統(tǒng)的封裝性；從基類繼承而來的實現(xiàn)是靜態(tài)的，不可能在運行時發(fā)生改變，沒有足夠的靈活性；只能在有限的環(huán)境中使用。（“白箱”復用）組合/聚合復用：耦合度相對較低，選擇性地調用成員對象的操作；可以在運行時動態(tài)進行。（“黑箱”復用）合成復用原則合成復用原則分析組合/聚合可以使系統(tǒng)更加靈活，類與類之間的耦合度降低，一個類的變化對其他類造成的影響相對較少，因此一般首選使用組合/聚合來實現(xiàn)復用；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助于對問題的理解，降低復雜度，而濫用繼承反而會增加系統(tǒng)構建和維護的難度以及系統(tǒng)的復雜度，因此需要慎重使用繼承復用。合成復用原則合成復用原則實例實例說明某教學管理系統(tǒng)部分數(shù)據(jù)庫訪問類設計如圖所示：合成復用原則合成復用原則實例實例說明如果需要更換數(shù)據(jù)庫連接方式，如原來采用JDBC連接數(shù)據(jù)庫，現(xiàn)在采用數(shù)據(jù)庫連接池連接，則需要修改DBUtil類源代碼。如果StudentDAO采用JDBC連接，但是TeacherDAO采用連接池連接，則需要增加一個新的DBUtil類，并修改StudentDAO或TeacherDAO的源代碼，使之繼承新的數(shù)據(jù)庫連接類，這將違背開閉原則，系統(tǒng)擴展性較差?，F(xiàn)使用合成復用原則對其進行重構。合成復用原則合成復用原則實例實例解析迪米特法則迪米特法則定義迪米特法則(LawofDemeter,LoD)又稱為最少知識原則(LeastKnowledgePrinciple,LKP)，它有多種定義方法，其中幾種典型定義如下：(1)不要和“陌生人”說話。英文定義為：Don'ttalktostrangers.(2)只與你的直接朋友通信。英文定義為：Talkonlytoyourimmediatefriends.(3)每一個軟件單位對其他的單位都只有最少的知識，而且局限于那些與本單位密切相關的軟件單位。英文定義為：Eachunitshouldhaveonlylimitedknowledgeaboutotherunits:onlyunits"closely"relatedtothecurrentunit.迪米特法則迪米特法則分析迪米特法則來自于1987年秋美國東北大學(NortheasternUniversity)一個名為“Demeter”的研究項目。簡單地說，迪米特法則就是指一個軟件實體應當盡可能少的與其他實體發(fā)生相互作用。這樣，當一個模塊修改時，就會盡量少的影響其他的模塊，擴展會相對容易，這是對軟件實體之間通信的限制，它要求限制軟件實體之間通信的寬度和深度。迪米特法則迪米特法則分析在迪米特法則中，對于一個對象，其朋友包括以下幾類：(1)當前對象本身(this)；(2)以參數(shù)形式傳入到當前對象方法中的對象；(3)當前對象的成