设计模式课件

第1章統一建模語言基礎知識

UML簡介UML的誕生在一個現代化的工程中，人們要相互溝通和合作，就必須使用標準的工業化設計語言，用這些語言來對待開發的產品進行建模。建模過程把複雜的問題分解成為易於理解的小問題，以達到問題的求解。建模是開發優秀軟體的所有活動中核心部分之一，其目的是把所要設計的結構和系統的行為聯繫起來，並對系統的結構進行可視化控制。UML簡介UML的誕生從1994年起，GradyBooch和JamesRumbaugh在Rational軟體公司開始了UML的創建工作。1995年，OOSE方法和Objectory方法的創建者IvarJacobson也加入其中。UML三位創始人正式聯手，共同為創建一種標準的建模語言而一起工作，他們將開發出來的產品名稱定為UML（UnifiedModelingLanguage，統一建模語言）。UML簡介UML的誕生1997年11月，在IvarJacoboson、GradyBooch以及JamesRumbaugh的共同努力下，UML1.1版本提交給OMG（ObjectManagementGroup,對象管理組織）並獲得通過，UML1.1成為業界標準的建模語言。2003年6月，OMG技術會議上UML2.0獲得正式通過，UML的發展與應用也上升到一個新的高度，越來越多的人開始學習和使用UML來進行軟體建模。UML簡介UMLUnifiedModelingLanguage統一建模語言統一建模語言統一建模語言UML簡介IvarJacobosonGradyBoochJamesRumbaughObjectModelingTechnique(OMT)Booch開發方法Object-OrientedSoftwareEngineering(OOSE)UMLUML簡介你應該使用UML嗎？是！舊的面向對象符號正在快速消失，新的書、文章將全部採用UML作為符號。如果你正要開始使用建模符號，你就該直接學習UML。－－MartinFowlerUML簡介UML的結構視圖(View)用戶視圖：以用戶的觀點表示系統的目標，它是所有視圖的核心，該視圖描述系統的需求。結構視圖：表示系統的靜態行為，描述系統的靜態元素，如包、類與對象，以及它們之間的關係。行為視圖：表示系統的動態行為，描述系統的組成元素如對象在系統運行時的交互關係。實現視圖：表示系統中邏輯元素的分佈，描述系統中物理檔以及它們之間的關係。環境視圖：表示系統中物理元素的分佈，描述系統中硬體設備以及它們之間的關係。UML簡介UML的結構圖(Diagram)用例圖(UseCaseDiagram):

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

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

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

工程化

規範化

可視化

系統化

文檔化

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

loginButton;……}publicclassJButton{

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

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

this.engine=engine;}

publicvoidsetEngine(Engineengine){

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

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

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

car.move();}

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

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

……}publicvoidsay(){

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

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

類圖類之間的關係介面與實現關係publicinterfaceVehicle{publicvoidmove();}publicclassShipimplementsVehicle{publicvoidmove(){

……}}publicclassCarimplementsVehicle{publicvoidmove(){

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

順序圖順序圖定義

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

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

軟體的複用(Reuse)或重用擁有眾多優點，如可以提高軟體的開發效率，提高軟體品質，節約開發成本，恰當的複用還可以改善系統的可維護性。面向對象設計複用的目標在於實現支持可維護性的複用。

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

開閉原則開閉原則實例實例說明某圖形介面系統提供了各種不同形狀的按鈕，客戶端代碼可針對這些按鈕進行編程，用戶可能會改變需求要求使用不同的按鈕，原始設計方案如圖所示：現對該系統進行重構，使之滿足開閉原則的要求。開閉原則開閉原則實例實例解析裏氏代換原則裏氏代換原則定義裏氏代換原則(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年約翰.馮諾依曼獎得主，美國工程院院士，美國藝術與科學院院士，美國電腦協會會士。現任麻省理工學院電子電氣與電腦科學系教授。她是美國第一個電腦科學女博士。周以真（JeannetteM.Wing），美國電腦科學家，卡內基.梅隆大學教授，美國國家自然基金會計算與資訊科學工程部助理部長，ACM和IEEE會士。裏氏代換原則裏氏代換原則分析裏氏代換原則可以通俗表述為：在軟體中如果能夠使用基類對象，那麼一定能夠使用其子類對象。把基類都替換成它的子類，程式將不會產生任何錯誤和異常，反過來則不成立，如果一個軟體實體使用的是一個子類的話，那麼它不一定能夠使用基類。裏氏代換原則是實現開閉原則的重要方式之一，由於使用基類對象的地方都可以使用子類對象，因此在程式中儘量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。裏氏代換原則裏氏代換原則分析喜歡動物喜歡貓因為貓是動物

裏氏代換原則裏氏代換原則實例實例說明某系統需要實現對重要數據（如用戶密碼）的加密處理，在數據操作類(DataOperator)中需要調用加密類中定義的加密演算法，系統提供了兩個不同的加密類，CipherA和CipherB，它們實現不同的加密方法，在DataOperator中可以選擇其中的一個實現加密操作。如圖所示：裏氏代換原則裏氏代換原則實例實例說明如果需要更換一個加密演算法類或者增加並使用一個新的加密演算法類，如將CipherA改為CipherB，則需要修改客戶類Client和數據操作類DataOperator的源代碼，違背了開閉原則。現使用裏氏代換原則對其進行重構，使得系統可以靈活擴展，符合開閉原則。裏氏代換原則裏氏代換原則實例實例解析依賴倒轉原則依賴倒轉原則定義依賴倒轉原則(DependenceInversionPrinciple,DIP)的定義如下：高層模組不應該依賴低層模組，它們都應該依賴抽象。抽象不應該依賴於細節，細節應該依賴於抽象。其英文定義為：Highlevelmodulesshouldnotdependuponlowlevelmodules,bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails,detailsshoulddependuponabstractions.另一種表述為：要針對介面編程，不要針對實現編程。其英文定義為：Programtoaninterface,notanimplementation.依賴倒轉原則依賴倒轉原則分析依賴倒轉原則是RobertC.Martin在1996年為《C++Reporter》所寫的專欄EngineeringNotebook的第三篇，後來加入到他在2002年出版的經典著作《AgileSoftwareDevelopment,Principles,Patterns,andPractices》中。依賴倒轉原則依賴倒轉原則分析簡單來說，依賴倒轉原則就是指：代碼要依賴於抽象的類，而不要依賴於具體的類；要針對介面或抽象類編程，而不是針對具體類編程。實現開閉原則的關鍵是抽象化，並且從抽象化導出具體化實現，如果說開閉原則是面向對象設計的目標的話，那麼依賴倒轉原則就是面向對象設計的主要手段。依賴倒轉原則依賴倒轉原則分析依賴倒轉原則的常用實現方式之一是在代碼中使用抽象類，而將具體類放在配置檔中。“將抽象放進代碼，將細節放進元數據”PutAbstractionsinCode,DetailsinMetadata（《程式員修煉之道：從小工到專家》(ThePragmaticprogrammer:fromjourneymantomaster)）依賴倒轉原則依賴倒轉原則分析類之間的耦合零耦合關係具體耦合關係抽象耦合關係依賴倒轉原則要求客戶端依賴於抽象耦合，以抽象方式耦合是依賴倒轉原則的關鍵。依賴倒轉原則依賴倒轉原則分析依賴注入依賴倒轉原則依賴倒轉原則分析依賴注入構造注入(ConstructorInjection)：通過構造函數注入實例變數。設值注入(SetterInjection)：通過Setter方法注入實例變數。介面注入(InterfaceInjection)：通過介面方法注入實例變數。

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

sothatanyclientsoftheinterfacewillonlyknowaboutthemethodsthatpertaintothem.介面隔離原則介面隔離原則分析介面隔離原則是指使用多個專門的介面，而不使用單一的總介面。每一個介面應該承擔一種相對獨立的角色，不多不少，不幹不該幹的事，該幹的事都要幹。(1)一個介面就只代表一個角色，每個角色都有它特定的一個介面，此時這個原則可以叫做“角色隔離原則”。(2)介面僅僅提供客戶端需要的行為，即所需的方法，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的介面，而不要提供大的總介面。介面隔離原則介面隔離原則分析使用介面隔離原則拆分介面時，首先必須滿足單一職責原則，將一組相關的操作定義在一個介面中，且在滿足高內聚的前提下，介面中的方法越少越好。可以在進行系統設計時採用定制服務的方式，即為不同的客戶端提供寬窄不同的介面，只提供用戶需要的行為，而隱藏用戶不需要的行為。介面隔離原則介面隔離原則實例實例說明下圖展示了一個擁有多個客戶類的系統，在系統中定義了一個巨大的介面（胖介面）AbstractService來服務所有的客戶類。可以使用介面隔離原則對其進行重構。介面隔離原則介面隔離原則實例實例解析合成複用原則合成複用原則定義合成複用原則(CompositeReusePrinciple,CRP)又稱為組合/聚合複用原則(Composition/AggregateReusePrinciple,CARP)，其定義如下：儘量使用對象組合，而不是繼承來達到複用的目的。其英文定義為：Favorcompositionofobjectsoverinheritanceasareusemechanism.合成複用原則合成複用原則分析合成複用原則就是指在一個新的對象裏通過關聯關係（包括組合關係和聚合關係）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到複用其已有功能的目的。簡言之：要儘量使用組合/聚合關係，少用繼承。合成複用原則合成複用原則分析在面向對象設計中，可以通過兩種基本方法在不同的環境中複用已有的設計和實現，即通過組合/聚合關係或通過繼承。繼承複用：實現簡單，易於擴展。破壞系統的封裝性；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性；只能在有限的環境中使用。（“白箱”複用）組合/聚合複用：耦合度相對較低，選擇性地調用成員對象的操作；可以在運行時動態進行。（“黑箱”複用）合成複用原則合成複用原則分析組合/聚合可以使系統更加靈活，類與類之間的耦合度降低，一個類的變化對其他類造成的影響相對較少，因此一般首選使用組合/聚合來實現複用；其次才考慮繼承，在使用繼承時，需要嚴格遵循裏氏代換原則，有效使用繼承會有助於對問題的理解，降低複雜度，而濫用繼承反而會增加系統構建和維護的難度以及系統的複雜度，因此需要慎重使用繼承複用。合成複用原則合成複用原則實例實例說明某教學管理系統部分資料庫訪問類設計如圖所示：合成複用原則合成複用原則實例實例說明如果需要更換資料庫連接方式，如原來採用JDBC連接資料庫，現在採用資料庫連接池連接，則需要修改DBUtil類源代碼。如果StudentDAO採用JDBC連接，但是TeacherDAO採用連接池連接，則需要增加一個新的DBUtil類，並修改StudentDAO或TeacherDAO的源代碼，使之繼承新的資料庫連接類，這將違背開閉原則，系統擴展性較差。現使用合成複用原則對其進行重構。合成複用原則合成複用原則實例實例解析迪米特法則迪米特法則定義迪米特法則(LawofDemeter,LoD)又稱為最少知識原則(LeastKnowledgePrinciple,LKP)，它有多種定義方法，其中幾種典型定義如下：(1)不要和“陌生人”說話。英文定義為：Don'ttalktostrangers.(2)只與你的直接朋友通信。英文定義為：Talkonlytoyourimmediatefriends.(3)每一個軟體單位對其他的單位都只有最少的知識，而且局限於那些與本單位密切相關的軟體單位。英文定義為：Eachunitshouldhaveonlylimitedknowledgeaboutotherunits:onlyunits"closely"relatedtothecurrentunit.迪米特法則迪米特法則分析迪米特法則來自於1987年秋美國東北大學(NortheasternUniversity)一個名為“Demeter”的研究專案。簡單地說，迪米特法則就是指一個軟體實體應當盡可能少的與其他實體發生相互作用。這樣，當一個模組修改時，就會儘量少的影響其他的模組，擴展會相對容易，這是對軟體實體之間通信的限制，它要求限制軟體實體之間通信的寬度和深度。迪米特法則迪米特法則分析在迪米特法則中，對於一個對象，其朋友包括以下幾類：(1)當前對象本身(this)；(2)以參數形式傳入到當前對象方法中的對象；(3)當前對象的成員對象；(4)如果當前對象的成員對象是一個集合，那麼集合中的元素也都是朋友；(5)當前對象所創建的對象。任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。迪米特法則迪米特法則分析迪米特法則可分為狹義法則和廣義法則。在狹義的迪米特法則中，如果兩個類之間不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用，如果其中的一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。迪米特法則迪米特法則分析狹義的迪米特法則：可以降低類之間的耦合，但是會在系統中增加大量的小方法並散落在系統的各個角落，它可以使一個系統的局部設計簡化，因為每一個局部都不會和遠距離的對象有直接的關聯，但是也會造成系統的不同模組之間的通信效率降低，使得系統的不同模組之間不容易協調。廣義的迪米特法則：指對對象之間的資訊流量、流向以及資訊的影響的控制，主要是對資訊隱藏的控制。資訊的隱藏可以使各個子系統之間脫耦，從而允許它們獨立地被開發、優化、使用和修改，同時可以促進軟體的複用，由於每一個模組都不依賴於其他模組而存在，因此每一個模組都可以獨立地在其他的地方使用。一個系統的規模越大，資訊的隱藏就越重要，而資訊隱藏的重要性也就越明顯。迪米特法則迪米特法則分析迪米特法則的主要用途在於控制資訊的超載：在類的劃分上，應當儘量創建松耦合的類，類之間的耦合度越低，就越有利於複用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當儘量降低其成員變數和成員函數的訪問許可權；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。迪米特法則迪米特法則實例實例說明某系統介面類(如Form1、Form2等類)與數據訪問類(如DAO1、DAO2等類)之間的調用關係較為複雜，如圖所示：迪米特法則迪米特法則實例實例解析本章小結對於面向對象的軟體系統設計來說，在支持可維護性的同時，需要提高系統的可複用性。軟體的複用可以提高軟體的開發效率，提高軟體品質，節約開發成本，恰當的複用還可以改善系統的可維護性。單一職責原則要求在軟體系統中，一個類只負責一個功能領域中的相應職責。開閉原則要求一個軟體實體應當對擴展開放，對修改關閉，即在不修改源代碼的基礎上擴展一個系統的行為。裏氏代換原則可以通俗表述為在軟體中如果能夠使用基類對象，那麼一定能夠使用其子類對象。設計模式的誕生與發展模式的誕生與定義模式起源於建築業而非軟體業模式(Pattern)之父——美國加利佛尼亞大學環境結構中心研究所所長ChristopherAlexander博士《APatternLanguage:Towns,Buildings,Construction》——253個建築和城市規劃模式模式Context（模式可適用的前提條件）Theme或Problem（在特定條件下要解決的目標問題）Solution（對目標問題求解過程中各種物理關係的記述）設計模式的誕生與發展ChristopherAlexander設計模式的誕生與發展模式的誕生與定義Alexander給出了關於模式的經典定義：每個模式都描述了一個在我們的環境中不斷出現的問題，然後描述了該問題的解決方案的核心，通過這種方式，我們可以無數次地重用那些已有的解決方案，無需再重複相同的工作。Apatternisasolutiontoaprobleminacontext

模式是在特定環境中解決問題的一種方案設計模式的誕生與發展軟體模式1990年，軟體工程界開始關注ChristopherAlexander等在這一住宅、公共建築與城市規劃領域的重大突破，最早將該模式的思想引入軟體工程方法學的是1991-1992年以“四人組(GangofFour，GoF，分別是ErichGamma,RichardHelm,RalphJohnson和JohnVlissides)”自稱的四位著名軟體工程學者，他們在1994年歸納發表了23種在軟體開發中使用頻率較高的設計模式，旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。設計模式的誕生與發展GangofFour設計模式的誕生與發展ErichGamma蘇黎世大學電腦科學博士，是Eclipse、JUnit等專案主要技術負責人之一。JohnVlissides斯坦福大學電腦科學博士，原IBM研究員，於2005年11月24日因腦瘤去世，享年44歲。RalphJohnson

墨爾本大學電腦科學博士，原IBM研究員，現在波士頓顧問集團供職。RichardHelm康奈爾大學電腦科學博士，伊利諾伊大學教授。GangofFour設計模式的誕生與發展軟體模式軟體模式是將模式的一般概念應用於軟體開發領域，即軟體開發的總體指導思路或參照樣板。軟體模式並非僅限於設計模式，還包括架構模式、分析模式和過程模式等，實際上，在軟體生存期的每一個階段都存在著一些被認同的模式。軟體模式可以認為是對軟體開發這一特定“問題”的“解法”的某種統一表示，它和Alexander所描述的模式定義完全相同，即軟體模式等於一定條件下的出現的問題以及解法。軟體模式的基礎結構由4個部分構成：問題描述、前提條件（環境或約束條件）、解法和效果。設計模式的誕生與發展軟體模式設計模式的誕生與發展軟體模式軟體模式與具體的應用領域無關，在模式發現過程中需要遵循大三律(RuleofThree)，即只有經過三個以上不同類型（或不同領域）的系統的校驗，一個解決方案才能從候選模式升格為模式。設計模式的誕生與發展設計模式的發展1987年，KentBeck和WardCunningham借鑒Alexander的模式思想在程式開發中開始應用一些模式，在OOPSLA會議上發表了他們的成果。1990年，OOPSLA與ECOOP聯合舉辦，ErichGamma和RichardHelm等人開始討論有關模式的話題(BruceAnderson主持)，“四人組”正式成立，並開始著手進行設計模式的分類整理工作。1991年，OOPSLA，BruceAnderson主持了首次針對設計模式的研討會。1992年，OOPSLA，Anderson再度主持研討會，模式已經逐漸成為人們討論的話題。注:OOPSLA(Object-OrientedProgramming,Systems,Languages&Applications，面向對象編程、系統、語言和應用大會)，編程語言及軟體工程國際頂級會議，2010年改為SPLASH---Systems,Programming,LanguagesandApplications:SoftwareforHumanity設計模式的誕生與發展設計模式的發展1993年，KentBeck和GradyBooch贊助了第一次關於設計模式的會議，這個設計模式研究組織發展成為著名的HillsideGroup研究組。1994年，由HillsideGroup發起，在美國伊利諾伊州(Illinois)的AllertonPark召開了第1屆關於面向對象模式的世界性會議，名為PLoP(PatternLanguagesofPrograms,編程語言模式會議)，簡稱PLoP‘94。1995年，PLoP‘95仍在伊利諾伊州的AllertonPark舉行，“四人組”出版了《設計模式：可複用面向對象軟體的基礎》(DesignPatterns:ElementsofReusableObject-OrientedSoftware)一書，本書成為1995年最搶手的面向對象書籍，也成為設計模式的經典書籍。設計模式的誕生與發展設計模式的發展從1995年至今，設計模式在軟體開發中得以廣泛應用，在Sun的JavaSE/JavaEE平臺和Microsoft的.net平臺設計中就應用了大量的設計模式。誕生了越來越多的與設計模式相關的書籍和網站，設計模式也作為一門獨立的課程或作為軟體體系結構等課程的重要組成部分出現在國內外研究生和大學教育的課堂上。設計模式的定義與分類設計模式的定義設計模式(DesignPattern)是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結，使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。設計模式的定義與分類設計模式的基本要素設計模式一般有如下幾個基本要素：模式名稱、問題、目的、解決方案、效果、實例代碼和相關設計模式，其中的關鍵元素包括以下四個方面：模式名稱(Patternname)問題(Problem)解決方案(Solution)效果(Consequences)設計模式的定義與分類設計模式學習步驟本書將按照以下次序來學習設計模式：模式動機與定義模式結構與分析模式實例與解析模式效果與應用模式擴展設計模式的定義與分類設計模式的分類根據其目的（模式是用來做什麼的）可分為創建型(Creational)，結構型(Structural)和行為型(Behavioral)三種：創建型模式主要用於創建對象。結構型模式主要用於處理類或對象的組合。行為型模式主要用於描述對類或對象怎樣交互和怎樣分配職責。設計模式的定義與分類設計模式的分類根據範圍，即模式主要是用於處理類之間關係還是處理對象之間的關係，可分為類模式和對象模式兩種：類模式處理類和子類之間的關係，這些關係通過繼承建立，在編譯時刻就被確定下來，是屬於靜態的。對象模式處理對象間的關係，這些關係在運行時刻變化，更具動態性。GoF設計模式簡介範圍\目的創建型模式結構型模式行為型模式類模式工廠方法模式（類）適配器模式解釋器模式範本方法模式對象模式抽象工廠模式建造者模式原型模式單例模式（對象）適配器模式橋接模式組合模式裝飾模式外觀模式享元模式代理模式職責鏈模式命令模式迭代器模式仲介者模式備忘錄模式觀察者模式狀態模式策略模式訪問者模式GoF設計模式簡介創建型模式抽象工廠模式(AbstractFactory)建造者模式(Builder)工廠方法模式(FactoryMethod)原型模式(Prototype)單例模式(Singleton)GoF設計模式簡介結構型模式適配器模式(Adapter)橋接模式(Bridge)組合模式(Composite)裝飾模式(Decorator)外觀模式(Facade)享元模式(Flyweight)代理模式(Proxy)GoF設計模式簡介行為型模式職責鏈模式(ChainofResponsibility)命令模式(Command)解釋器模式(Interpreter)迭代器模式(Iterator)仲介者模式(Mediator)備忘錄模式(Memento)觀察者模式(Observer)狀態模式(State)策略模式(Strategy)範本方法模式(TemplateMethod)訪問者模式(Visitor)設計模式的優點

設計模式是從許多優秀的軟體系統中總結出的成功的、能夠實現可維護性複用的設計方案，使用這些方案將避免我們做一些重複性的工作，而且可以設計出高質量的軟體系統。設計模式的主要優點如下：設計模式融合了眾多專家的經驗，並以一種標準的形式供廣大開發人員所用，它提供了一套通用的設計辭彙和一種通用的語言以方便開發人員之間溝通和交流，使得設計方案更加通俗易懂。對於使用不同編程語言的開發和設計人員可以通過設計模式來交流系統設計方案，每一個模式都對應一個標準的解決方案，設計模式可以降低開發人員理解系統的複雜度。設計模式的優點設計模式使人們可以更加簡單方便地複用成功的設計和體系結構，將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。設計模式使得重用成功的設計更加容易，並避免那些導致不可重用的設計方案。設計模式使得設計方案更加靈活，且易於修改。設計模式的使用將提高軟體系統的開發效率和軟體品質，且在一定程度上節約設計成本。設計模式有助於初學者更深入地理解面向對象思想，一方面可以幫助初學者更加方便地閱讀和學習現有類庫與其他系統中的源代碼，另一方面還可以提高軟體的設計水準和代碼品質。本章小結模式是在特定環境中解決問題的一種方案。GoF(ErichGamma,RichardHelm,RalphJohnson和JohnVlissides)最先將模式的概念引入軟體工程領域，他們歸納發表了23種在軟體開發中使用頻率較高的設計模式，旨在用模式來統一溝通面向對象方法在分析、設計和實現間的鴻溝。軟體模式是將模式的一般概念應用於軟體開發領域，即軟體開發的總體指導思路或參照樣板。軟體模式可以認為是對軟體開發這一特定“問題”的“解法”的某種統一表示，即軟體模式等於一定條件下的出現的問題以及解法。本章教學內容

創建型模式創建型模式概述創建型模式簡介簡單工廠模式模式動機與定義模式結構與分析模式實例與解析模式效果與應用模式擴展創建型模式創建型模式概述創建型模式(CreationalPattern)對類的實例化過程進行了抽象，能夠將軟體模組中對象的創建和對象的使用分離。為了使軟體的結構更加清晰，外界對於這些對象只需要知道它們共同的介面，而不清楚其具體的實現細節，使整個系統的設計更加符合單一職責原則。創建型模式創建型模式概述創建型模式在創建什麼(What)，由誰創建(Who)，何時創建(When)等方面都為軟體設計者提供了盡可能大的靈活性。創建型模式隱藏了類的實例的創建細節，通過隱藏對象如何被創建和組合在一起達到使整個系統獨立的目的。創建型模式想吃蘋果!?創建型模式概述創建型模式概述創建型模式獲取蘋果的兩種方式自己種蘋果樹去超市買創建型模式簡單工廠模式（SimpleFactory）

工廠方法模式（FactoryMethod）抽象工廠模式（AbstractFactory）建造者模式（Builder）原型模式（Prototype）單例模式（Singleton）創建型模式簡介簡單工廠模式模式動機只需要知道水果的名字則可得到相應的水果簡單工廠模式模式動機考慮一個簡單的軟體應用場景，一個軟體系統可以提供多個外觀不同的按鈕（如圓形按鈕、矩形按鈕、菱形按鈕等），這些按鈕都源自同一個基類，不過在繼承基類後不同的子類修改了部分屬性從而使得它們可以呈現不同的外觀，如果我們希望在使用這些按鈕時，不需要知道這些具體按鈕類的名字，只需要知道表示該按鈕類的一個參數，並提供一個調用方便的方法，把該參數傳入方法即可返回一個相應的按鈕對象，此時，就可以使用簡單工廠模式。簡單工廠模式模式定義簡單工廠模式(SimpleFactoryPattern)：又稱為靜態工廠方法(StaticFactoryMethod)模式，它屬於類創建型模式。在簡單工廠模式中，可以根據參數的不同返回不同類的實例。簡單工廠模式專門定義一個類來負責創建其他類的實例，被創建的實例通常都具有共同的父類。簡單工廠模式模式結構簡單工廠模式模式結構簡單工廠模式包含如下角色：Factory：工廠角色Product：抽象產品角色ConcreteProduct：具體產品角色簡單工廠模式模式分析分析如下代碼：publicvoidpay(Stringtype){if(type.equalsIgnoreCase("cash")){//現金支付處理代碼}elseif(type.equalsIgnoreCase("creditcard")){//信用卡支付處理代碼}elseif(type.equalsIgnoreCase("voucher")){//代金券支付處理代碼}else{……}}代碼複雜，難以維護簡單工廠模式模式分析重構後的代碼：publicabstractclassAbstractPay{publicabstractvoidpay();}publicclassCashPayex