第一篇設(shè)計(jì)模式概述

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

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

等項(xiàng)目主要技術(shù)負(fù)責(zé)人之一。JohnVlissides斯坦福大學(xué)計(jì)算機(jī)科學(xué)博士，原IBM研究員，于2005年11月24日因腦瘤去世，享年44歲。RalphJohnson

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

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

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

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

UML是一種分析設(shè)計(jì)語言，即一種建模語言。UML是由圖形符號表達(dá)的建模語言，其結(jié)構(gòu)主要包括視圖、圖、模型元素和通用機(jī)制四部分。UML結(jié)構(gòu)

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

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

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

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

工程化

規(guī)范化

可視化

系統(tǒng)化

文檔化

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

loginButton;……}publicclassJButton{

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

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

this.engine=engine;}

publicvoidsetEngine(Engineengine){

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

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

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

car.move();}

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

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

……}publicvoidsay(){

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

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

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

……}}publicclassCarimplementsVehicle{publicvoidmove(){

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

順序圖順序圖定義

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

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

軟件的復(fù)用(Reuse)或重用擁有眾多優(yōu)點(diǎn)，如可以提高軟件的開發(fā)效率，提高軟件質(zhì)量，節(jié)約開發(fā)成本，恰當(dāng)?shù)膹?fù)用還可以改善系統(tǒng)的可維護(hù)性。面向?qū)ο笤O(shè)計(jì)復(fù)用的目標(biāo)在于實(shí)現(xiàn)支持可維護(hù)性的復(fù)用。

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

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

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

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