面向對象系統(tǒng)設計

面向對象系統(tǒng)設計第一頁，共一百五十一頁，編輯于2023年，星期二本章主要內(nèi)容11.1軟件架構的設計11.2高層結構設計11.3面向對象設計方法11.4對象持久化與數(shù)據(jù)庫11.5設計原則11.6設計模式第二頁，共一百五十一頁，編輯于2023年，星期二11.1軟件架構的設計11.1.1什么是軟件架構11.1.2多層應用架構設計11.1.3軟件框架第三頁，共一百五十一頁，編輯于2023年，星期二1.架構的概念建筑、文學、音樂、機械、電子、計算機軟硬件等領域都會使用“架構（architecture）”這一概念。架構都提供了系統(tǒng)最高層的設計方案，以確保建筑、小說、樂曲、設備、計算機等系統(tǒng)滿足期望的特性。好的建筑應該美觀、堅固、實用好的計算機應用系統(tǒng)應該實用、好維護、可靠、性價比高架構師（architect）需要發(fā)現(xiàn)特定系統(tǒng)的最重要的關注點，設計某種折衷的總體方案以滿足關注點。架構包含系統(tǒng)的一組基本結構（structure），每種結構都有各種類型的部件（component）及其關系構成，架構描述了這些部件的組合、相互調(diào)用參照、通信以及其他動態(tài)交互。第四頁，共一百五十一頁，編輯于2023年，星期二架構和結構的關系架構是抽象無形的，體現(xiàn)高層全局的決策，就像文章的中心思想和提綱。結構是具體有形的，體現(xiàn)決策的貫徹，如同文章的每個段落及細節(jié)描述。架構包含了結構的初步描述和決策。相同架構的系統(tǒng)，具體結構允許有差異。第五頁，共一百五十一頁，編輯于2023年，星期二使用橋梁來比喻橋梁的架構設計可以使用草圖描述，架構決定了橋梁的基本結構部件。橋梁有梁式橋、拱橋、斜拉橋、懸索橋等架構斜拉橋的基本結構：索塔主梁斜拉索第六頁，共一百五十一頁，編輯于2023年，星期二使用橋梁來比喻橋梁的結構設計則需要考慮各種部件的數(shù)量、材料、重量、形態(tài)等方面，是可以施工的嚴謹?shù)慕Y構圖。架構是抽象的，對結構進行了設計和限定，每座橋的結構是具體有形的、元素組合千變?nèi)f化第七頁，共一百五十一頁，編輯于2023年，星期二2.軟件架構軟件架構（softwarearchitecture）的定義沒有統(tǒng)一的版本，一般認為：一個應用程序或計算系統(tǒng)的軟件架構是一個或一組結構，它包含組成系統(tǒng)的軟件元素、這些元素對外可見的性質以及它們之間的關系。對外可見的性質指軟件元素能夠提供的服務、性能特征、錯誤處理、共享資源的用法等。軟件的一個結構元素可能是一個子系統(tǒng)、構件、進程、庫、數(shù)據(jù)庫、計算結點、遺留系統(tǒng)等等。軟件架構是最高層次的系統(tǒng)分解，它不會囊括所有的結構和行為的定義，它只關注那些被認為是重要的元素。架構難以更改，一旦修改，意味著整個系統(tǒng)重建，而結構修改只影響局部。第八頁，共一百五十一頁，編輯于2023年，星期二3.軟件架構模式大部分的架構來源于有相似關注點的系統(tǒng)的總結和抽象，這些相似性被描述成某種特殊模式的架構風格，也就是架構模式（architecturalpattern）。一種架構模式就是一個經(jīng)驗秘籍，架構師在設計不同系統(tǒng)時可以重復使用這些先進經(jīng)驗。圖10.1就是橋梁的四種常用架構模式。中國建筑有一種攢尖模式，被廣泛應用在古典園林中，如三角、四角、五角、八角等亭子，宮殿、壇廟大量應用。第九頁，共一百五十一頁，編輯于2023年，星期二軟件架構模式軟件架構模式就是可重復使用的軟件結構風格。第十頁，共一百五十一頁，編輯于2023年，星期二10.1.2多層應用架構模式分層的含義三層多層MVC架構模式多層的物理配置第十一頁，共一百五十一頁，編輯于2023年，星期二1.分層的含義基于組件的軟件開發(fā)，組件根據(jù)橫向位置劃分為多層（N-Layer）：下層組件負責對上層組件提供服務上層組件可以使用下層組件定義的服務，但下層組件對上層組件一無所知。層與層之間通常是不透明的，每一層都具有獨立的職責不同層的軟件構件可以分布在多臺機器上，也可以部署在同一臺機器上，形成物理上的多層（N-Tier）第十二頁，共一百五十一頁，編輯于2023年，星期二理解分層概念層次模型的理念就是將整個任務橫向劃分為不同級別，而不是縱向比如學校管理縱向劃分有教學、人事、財務、后勤等任務橫向劃分有主管校長（高層）、部門領導（中層）、普通員工（基層），或處、科、室計算機程序的組織結構也可以有縱向劃分和橫向劃分縱向：教師管理功能、學生管理功能、課程管理功能……橫向：界面窗體、業(yè)務邏輯類、數(shù)據(jù)訪問類……第十三頁，共一百五十一頁，編輯于2023年，星期二理解分層概念自從C/S出現(xiàn)之后，軟件就被分層了：Client端的軟件完成前臺任務，Server端的軟件完成后臺任務（一般是DBServer）；Client使用Server端的服務，依賴于Server端。自從Internet出現(xiàn)之后，軟件進一步分層：Client端的軟件（IE瀏覽器）完成輸入輸出任務，WebServer上的程序提供業(yè)務邏輯處理，后臺DBServer完成數(shù)據(jù)的存取。C/S常被稱為傳統(tǒng)的兩層，B/S稱為三層。本書的分層將不包含有關系統(tǒng)軟件（屏蔽如IE、DBMS等內(nèi)容），僅討論應用系統(tǒng)本身的設計，即應用架構設計。第十四頁，共一百五十一頁，編輯于2023年，星期二2.三個基本層次應用軟件內(nèi)部也可以進行多層的劃分。比如一個用戶注冊程序可以劃分為兩層：Register.aspx/Register.aspx.cs窗體：負責界面數(shù)據(jù)的輸入和格式檢驗，結果的輸出等。Person類：負責數(shù)據(jù)庫訪問和注冊規(guī)則檢查等。從應用層面上看，如果整個應用軟件都是采用這種方式編程（如訂單處理由PlaceOrder.aspx窗體負責界面交互，由Order、Product等類負責數(shù)據(jù)庫訪問和訂單金額計算等業(yè)務邏輯處理），那么稱之為兩層的應用架構?？梢杂袃蓪?、三層、四層等不同分層模式。Register.aspx/Register.aspx.cs窗體PersonBll類：負責注冊規(guī)則檢查等業(yè)務邏輯。PersonDal類：負責數(shù)據(jù)庫訪問。第十五頁，共一百五十一頁，編輯于2023年，星期二傳統(tǒng)的C/S應用程序界面窗口程序中包含所有的內(nèi)容，如輸入輸出、界面邏輯控制、業(yè)務邏輯運算等。系統(tǒng)架構是兩層，應用架構沒有分層。數(shù)據(jù)庫第十六頁，共一百五十一頁，編輯于2023年，星期二經(jīng)典的三層架構數(shù)據(jù)庫借還書組件讀者管理組件表示層（UI）業(yè)務邏輯層（BLL）數(shù)據(jù)訪問層（DAL）數(shù)據(jù)庫訪問組件第十七頁，共一百五十一頁，編輯于2023年，星期二經(jīng)典的三層架構表現(xiàn)層：處理用戶和信息系統(tǒng)之間的交互?？梢允呛唵蔚拿钚写翱?，也可以功能完善的圖形用戶界面（胖客戶端程序），如基于HTML的瀏覽器界面（瘦客戶端程序），也可以是手機界面。業(yè)務邏輯層：也稱為領域層或應用層，是信息系統(tǒng)所有和領域相關的工作。如根據(jù)輸入數(shù)據(jù)或已有數(shù)據(jù)進行計算，可以是類庫或Web服務。依賴于數(shù)據(jù)訪問層獲取數(shù)據(jù)或保存數(shù)據(jù)。數(shù)據(jù)訪問層：一般指與數(shù)據(jù)庫的交互，主要責任是數(shù)據(jù)庫記錄的存取。如組件中包含專門的數(shù)據(jù)訪問類，或每個表對應一個數(shù)據(jù)訪問類第十八頁，共一百五十一頁，編輯于2023年，星期二3.擴展的五層架構表現(xiàn)層：等同于三層中的表現(xiàn)層?？刂茖?中介層：是表現(xiàn)層和領域層的中介層，也稱應用控制器。主要表示業(yè)務邏輯中的工作流，一般針對于用例的事件流控制。此外還負責會話狀態(tài)、數(shù)據(jù)的合成或分解等事務。領域層：業(yè)務邏輯中的領域類的集合，不包含復雜工作流。數(shù)據(jù)映射層：負責將基于對象的領域層數(shù)據(jù)映射到數(shù)據(jù)庫關系表中的記錄。也稱為數(shù)據(jù)持久層，可自行開發(fā)或采用持久化框架。數(shù)據(jù)訪問層：負責數(shù)據(jù)庫表的增刪改查等操作。持久化框架中包含該層組件。第十九頁，共一百五十一頁，編輯于2023年，星期二4.MVC架構模式模型（Model）代表數(shù)據(jù)，使用對象及其屬性實現(xiàn)。控制器（Controller）是模型與視圖的聯(lián)系紐帶，客戶的請求由控制器處理，它根據(jù)客戶的請求調(diào)用模型的方法，完成數(shù)據(jù)更新，然后調(diào)用視圖的方法將響應結果展示給客戶。相應的，模型的更新與修改將通過控制器通知視圖，保持視圖與模型的一致性視圖（View）是模型的外在表現(xiàn)形式，視圖可以直接訪問模型；查詢數(shù)據(jù)信息，當模型中數(shù)據(jù)發(fā)生變化時，它會通知視圖刷新界面，顯示更新后的數(shù)據(jù)。第二十頁，共一百五十一頁，編輯于2023年，星期二MVC架構示意圖MVC模式和三層模式有共同特點（業(yè)務邏輯、數(shù)據(jù)和表示的分離），但不完全遵守分層約定。第二十一頁，共一百五十一頁，編輯于2023年，星期二MVC架構模式工作流程控制器對象負責頁面轉向，并傳遞頁面數(shù)據(jù)第二十二頁，共一百五十一頁，編輯于2023年，星期二5.多層的物理配置由于應用軟件封裝成不同層次的獨立組件，這給軟件部署帶來了靈活性：物理一層：所有應用軟件的組件都安裝配置在一臺機器上。比如全部Web程序、DBMS都在Web服務器上。物理兩層：應用軟件的組件配置在兩臺機器上，比如一部分安裝在客戶端，另一部分配置在應用服務器上。物理多層：客戶端、一臺或多臺應用服務器、數(shù)據(jù)庫服務器，即多臺服務器的方式，這是分布式結構的一種形式。第二十三頁，共一百五十一頁，編輯于2023年，星期二多層體系結構的優(yōu)勢客戶對數(shù)據(jù)的訪問通過中間層進行了隔離，數(shù)據(jù)庫的安全性提高了。應用程序分布部署在多個物理節(jié)點上成為可能，從而增強了處理大量的用戶負載或計算任務的能力，系統(tǒng)可靠性和響應速度得到了提高。業(yè)務邏輯處于不同的中間服務器，當業(yè)務規(guī)則變化后，客戶端程序基本不做改動，當組件接口不變時，某一層的改動不會影響其它層，這也意味著更好的重用和可維護性（如從窗口界面變更到Web界面）。將不同層的開發(fā)任務在開發(fā)者之間適當?shù)胤峙洌ㄈ缫恍┤藢Ｗ㈨撁姹憩F(xiàn)，另一些人專注于業(yè)務邏輯），有效地利用開發(fā)人員的專長和開發(fā)技巧，并且能夠提高并行開發(fā)能力。第二十四頁，共一百五十一頁，編輯于2023年，星期二11.1.3軟件框架“不要重復發(fā)明輪子”軟件復用：從代碼角度（開發(fā)態(tài)）看有子過程、函數(shù)、類等從部署角度（運行態(tài)）看有類庫、Web服務等二進制可執(zhí)行組件、中間件和平臺架構模式同樣可以復用，當架構模式的復用形式不僅僅停留在邏輯層面，而以物理的二進制組件的方式提供重用時，就產(chǎn)生了框架。第二十五頁，共一百五十一頁，編輯于2023年，星期二1.軟件框架的概念軟件框架（softwareframework）是對整個或部分系統(tǒng)可重用的設計和實現(xiàn)?？蚣芸梢赃x擇對某種架構模式的基本結構和接口機制進行編程實現(xiàn)，不僅封裝該架構模式的基本元素對外提供類庫，還封裝底層公用的流程控制邏輯，從而直接為應用軟件提供了最初的骨架。框架就是一個半成品軟件平臺，軟件框架和應用軟件：八股文/元芳體與具體文章汽車流水線與汽車第二十六頁，共一百五十一頁，編輯于2023年，星期二基于框架的軟件開發(fā)引入軟件框架之后，整個開發(fā)過程變成了“分三步走”：決定應用架構選擇實現(xiàn)應用架構的框架基于框架之下編寫程序（簡單、統(tǒng)一）優(yōu)點：代碼具有相同規(guī)范和結構，易于理解和維護；提高效率；更穩(wěn)定更可靠。局限：囿于框架所限定的“框框”之內(nèi)構建應用程序，比較死板，缺乏靈活性第二十七頁，共一百五十一頁，編輯于2023年，星期二典型框架產(chǎn)品支持MVC架構模式的框架：Java開源MVC框架Struts微軟平臺的MVC4框架PHP的Zend框架多種框架產(chǎn)品的組合使用：如SSH（Struts、Spring、Hibernate）第二十八頁，共一百五十一頁，編輯于2023年，星期二Struts2簡介MVC：View：由JSP頁面實現(xiàn)Model：由自行編寫的Action對象完成，Action類就是一個普通的Java類，里面封裝了領域對象的屬性和方法，可以用于存取數(shù)據(jù)和執(zhí)行有關業(yè)務邏輯。屬性和方法也可以分開到不同類中。Controller：由Struts2的內(nèi)置過濾器（dispatcherfilter）、攔截器（interceptor）或自行編寫的攔截器來實現(xiàn)，過濾器和攔截器可以截獲JSP頁面請求，解析http請求中的參數(shù)，賦值給Action對象中對應的屬性，還可以在調(diào)用Action之前或之后進行預處理或后處理。第二十九頁，共一百五十一頁，編輯于2023年，星期二11.2高層結構設計高層結構討論系統(tǒng)比較大的組成部件（如包、構件、子系統(tǒng)等）及其接口設計。11.2.1包11.2.2子系統(tǒng)及接口11.2.3構件及接口第三十頁，共一百五十一頁，編輯于2023年，星期二11.2.1包包（Package）是一種邏輯分組手段，可以取UML模型中的任何一種事物，將相關成分聚在一起，以構成更高層的組織單元——包。最常用的方法是將類以包為單位進行分組，比如上一節(jié)提到的層，每一層中的所有類組成一個包。一個包可以包含其它的包，高層包被分成若干子包，子包又可以在分成更小的包。但在Java中，包還指代了物理的組織手段第三十一頁，共一百五十一頁，編輯于2023年，星期二如何分包分包（軟件類的分組）有兩種原則：共同封閉原則（CommonClosurePrinciple）。一個包中的各個類應該是由于相似的原則而改變，即將一組職責相似、但以不同方式實現(xiàn)的類歸為一個包中。比如按照層來進行分包就是這種類型。共同復用原則（CommonReusePrinciple）。一個包中的各個類應該一起被復用，復用其中一個可能需要同時考慮同一個包中的其它協(xié)作類。通常和業(yè)務功能相關。第三十二頁，共一百五十一頁，編輯于2023年，星期二包圖包圖用來描述包及其依賴關系。當表現(xiàn)層包中的類要使用領域包中的領域類提供的服務時，表示包就依賴于領域包。第三十三頁，共一百五十一頁，編輯于2023年，星期二11.2.2子系統(tǒng)及接口當按照相對完整和獨立的業(yè)務功能或管理職能組織包，并對這樣的包進行封裝后，一個高層的具有特定功能的可以運行的獨立構件就產(chǎn)生了，稱為子系統(tǒng)（Subsystem）。子系統(tǒng)對外可以提供有限的接口，只要接口不改變，不管子系統(tǒng)內(nèi)部發(fā)生什么變化，也不會影響到依賴于該子系統(tǒng)接口的其它子系統(tǒng)。子系統(tǒng)及其關系使用UML構件圖（componentdiagram）描述。第三十四頁，共一百五十一頁，編輯于2023年，星期二理解接口概念詞典釋義兩個不同系統(tǒng)(或子程序)交接并通過它彼此作用的部分。人類與計算機之間的接口稱為用戶接口。計算機硬件元件間的接口叫硬件接口。計算機軟件元件間的接口叫軟件接口。內(nèi)部接口：系統(tǒng)內(nèi)部各元件間的接口外部接口：系統(tǒng)對外提供給其他系統(tǒng)使用的接口API：應用編程接口（ApplicationProgrammingInterface），一種應用程序提供的外部接口的說法第三十五頁，共一百五十一頁，編輯于2023年，星期二區(qū)分子系統(tǒng)和包子系統(tǒng)與包在語義上具有差異：子系統(tǒng)是一種通過一個或多個它所實現(xiàn)的接口來提供行為的軟件單位，可運行，具有物理意義。包并不提供行為，包只不過是用來容納各種其他模型元素的容器，一般是邏輯意義上的。第三十六頁，共一百五十一頁，編輯于2023年，星期二子系統(tǒng)的關系財務子系統(tǒng)將內(nèi)部操作進行了封裝，但對外提供必要的接口（比如一組函數(shù)）銷售子系統(tǒng)在執(zhí)行銷售業(yè)務過程中可以使用該接口對銷售數(shù)據(jù)執(zhí)行某些財務操作。對于銷售子系統(tǒng)而言，依賴的是財務子系統(tǒng)的接口，并不需要關心財務子系統(tǒng)的具體實現(xiàn)。采用UML2.0的構件圖表示如下：第三十七頁，共一百五十一頁，編輯于2023年，星期二子系統(tǒng)的關系子系統(tǒng)之間的關系：數(shù)據(jù)接口：定義相互可以理解的數(shù)據(jù)格式和數(shù)據(jù)文件，子系統(tǒng)之間采用數(shù)據(jù)文件進行通信。服務接口：定義相互可以理解的軟件服務（操作、消息），子系統(tǒng)之間采用發(fā)送服務請求和響應來進行通信。思考：教務管理系統(tǒng)（基礎數(shù)據(jù)子系統(tǒng)、排課子系統(tǒng)、成績管理子系統(tǒng)、畢設管理子系統(tǒng)），各子系統(tǒng)是否有關系？第三十八頁，共一百五十一頁，編輯于2023年，星期二不同系統(tǒng)的關系子系統(tǒng)及接口關系也可以擴展到不同系統(tǒng)及接口關系，如學籍管理系統(tǒng)與其他系統(tǒng)的關系需要服務：高招系統(tǒng)（獲取學生信息）、教委學位系統(tǒng)（學位數(shù)據(jù)上報）本系統(tǒng)需要提供的服務：提供學生學籍信息同樣可采用UML構件圖描述：學籍管理系統(tǒng)高招系統(tǒng)教委系統(tǒng)發(fā)布錄取學生學位授予上報檔案系統(tǒng)提供學籍信息第三十九頁，共一百五十一頁，編輯于2023年，星期二11.2.2構件及接口構件（component）是系統(tǒng)中實際存在的可更換部分，它實現(xiàn)特定的功能，符合一套接口標準并實現(xiàn)一組接口。構件是可復用的軟件組成成份，可被用來構造其他軟件。在系統(tǒng)中采用構件軟件程序不需要重新編譯，也不需要構件自身的源代碼并且不局限于某一種編程語言，所以構件的復用也稱為二進制復用（binaryreuse），因為它是建立在接口而不是源代碼級別的復用。構件及其關系使用UML構件圖描述。第四十頁，共一百五十一頁，編輯于2023年，星期二構件圖1構件之間存在依賴關系：DataAccess構件用于實現(xiàn)數(shù)據(jù)存取訪問，對外提供接口名為SearchInDB（查詢數(shù)據(jù)庫，接口參數(shù)等細節(jié)省略）。Book構件實現(xiàn)圖書的管理，對外提供SearchBook（查詢圖書）和ExportToXml（導出圖書為XML文件）兩個接口。Book構件需要使用DataAccess構件提供的接口，即構件Book依賴于DataAccess構件。

DataAccessBookSearchBookExportToXmlSearchInDB第四十一頁，共一百五十一頁，編輯于2023年，星期二區(qū)分子系統(tǒng)和構件子系統(tǒng)和構件在結構上具有差異：子系統(tǒng)是一個系統(tǒng)，是有特定功能的整體，可以直接使用，不會被復用。構件只是構成系統(tǒng)的元素，不具備單獨使用的能力，用于復用。第四十二頁，共一百五十一頁，編輯于2023年，星期二11.3面向對象設計方法10.4.1根據(jù)架構設計軟件類10.4.2設計類的屬性10.4.3設計類的方法10.4.4設計類的關系第四十三頁，共一百五十一頁，編輯于2023年，星期二11.3.1根據(jù)架構設計軟件類一種3層的分層模式：從分析模型的領域類導出設計階段中的實體類增加邊界類和控制類完成程序的交互和控制。為了分辨出類的這三種不同類型，可以采用UML提供的擴展機制——構造型（stetreotype）及其表達符號來定義模型元素構造型第四十四頁，共一百五十一頁，編輯于2023年，星期二Rose中不同構造型的圖符<<邊界類>><<實體類>><<控制類>>系統(tǒng)邊界對象行為的控制和協(xié)調(diào)系統(tǒng)服務和信息第四十五頁，共一百五十一頁，編輯于2023年，星期二分層的軟件類協(xié)作實現(xiàn)一個用例第四十六頁，共一百五十一頁，編輯于2023年，星期二1、邊界類邊界類的職責是完成系統(tǒng)與其參與者之間的交互。接收來自用戶和外部系統(tǒng)的信息與請求將信息與請求提交給用戶和外部系統(tǒng)通過用例圖可以得知每個邊界類至少應該與一個參與者有關，參與者類型不同，邊界類的設計也不同邊界類包括屏幕窗口、通信接口、打印機接口、傳感器、終端以及專用API（應用程序編程接口）等軟件對象。對于圖書館系統(tǒng)來說，參與者都是系統(tǒng)用戶，因此邊界類只有窗口界面這一種形式。假如考慮提供館際互借業(yè)務，那么系統(tǒng)就會產(chǎn)生與其它外部合作的圖書館系統(tǒng)的交互，這時與外部系統(tǒng)間的通信接口也是一種邊界類第四十七頁，共一百五十一頁，編輯于2023年，星期二識別邊界類：圖書管理員?boundary?：借書用戶界面圖書管理員借出圖書根據(jù)用例圖，每個參與者與一個用例交互，必定導出一個邊界類第四十八頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的用例圖第四十九頁，共一百五十一頁，編輯于2023年，星期二2、實體類實體類來源于領域模型中的類。實體類是一個軟件對象，表示了領域對象的信息，以及具有與它所表示的信息有關的操作。實體類反映的信息需要在系統(tǒng)中進行處理，并需要進行持久化存儲。持久化存儲可以由實體類來實現(xiàn)，也可以設計專門的數(shù)據(jù)訪問類來完成。第五十頁，共一百五十一頁，編輯于2023年，星期二邊界類和實體類的交互邊界類僅負責數(shù)據(jù)的輸入和輸出，不應承擔和數(shù)據(jù)處理有關的業(yè)務邏輯，可負責部分不太復雜的數(shù)據(jù)校驗功能（如非空檢查、多個輸入域之間的約束和聯(lián)動）。邊界類通過與實體類的交互，獲得有關數(shù)據(jù)處理的結果：圖書管理員驗證?boundary?：借書用戶界面?entity?：讀者第五十一頁，共一百五十一頁，編輯于2023年，星期二3、控制類控制類代表協(xié)調(diào)、排序、事務處理以及對其它對象的控制，經(jīng)常用于封裝與某個具體用例有關的控制流?？刂祁愄幚砗蛥f(xié)調(diào)用例事件流中的主要動作和控制流，并將部分任務委派給其它對象。根據(jù)分層原則，控制類不封裝與參與者交互有關的內(nèi)容，也不封裝與系統(tǒng)處理的長效持久的信息有關的問題，這些問題分別由邊界類和實體類進行封裝。第五十二頁，共一百五十一頁，編輯于2023年，星期二識別控制類當用例邏輯較為復雜，并涉及到多個實體類時，可以考慮采用控制類簡化方案：控制類的職責合并給邊界類獲取驗證：圖書管理員創(chuàng)建?boundary?：借書用戶界面?control?：借書控制類?entity?：讀者?entity?：資源項目?entity?：借書記錄第五十三頁，共一百五十一頁，編輯于2023年，星期二不同類的職責分配向下依賴的關系：邊界類負責與參與者的交互（輸入數(shù)據(jù)、顯示數(shù)據(jù)）為GUI的每個彈出式屏幕創(chuàng)建一個邊界對象?？刂祁悾蛇x）負責一個用例的事件流，或部分復雜數(shù)據(jù)流實體類負責數(shù)據(jù)的封裝為每個領域類創(chuàng)建一個實體類第五十四頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的界面類第五十五頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的控制類第五十六頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的實體類第五十七頁，共一百五十一頁，編輯于2023年，星期二其他架構方案上述三層架構：表現(xiàn)層/控制層/實體層MVC框架：每個功能對應一個頁面類，即View（邊界類）每個頁面的請求都由Control類負責處理（控制類）Control類使用Model類存取數(shù)據(jù)（實體類）架構不同，要設計的軟件類也不同第五十八頁，共一百五十一頁，編輯于2023年，星期二11.3.2設計類的屬性屬性類型和初值屬性的類型和默認的初始值應該在設計模型中表示出來。類型和屬性名之間用冒號隔開，等號之后寫初值。選擇的數(shù)據(jù)類型最好是目標語言中可用的。關聯(lián)屬性屬性的可見性類中的每個屬性可以有可見性定義，指定該屬性可以被其它類利用的程度，UML定義了4種屬性可見性：公有（public）“+”受保護（protected）“#”私有（private）“-”包（package）“~”第五十九頁，共一百五十一頁，編輯于2023年，星期二圖書館類圖第六十頁，共一百五十一頁，編輯于2023年，星期二11.3.3建立用戶界面原型用戶界面原型是一個草圖，包含用例提到的系統(tǒng)和用戶進行交互的必要元素界面原型不描述太多細節(jié)，通常包含以下內(nèi)容：需要由用戶輸入到系統(tǒng)中的數(shù)據(jù)窗口或表格；需要由系統(tǒng)執(zhí)行的操作按鈕；系統(tǒng)應及時做出回應的事件；需要由系統(tǒng)輸出給用戶的數(shù)據(jù)窗口或消息。第六十一頁，共一百五十一頁，編輯于2023年，星期二借書界面設計第六十二頁，共一百五十一頁，編輯于2023年，星期二借書界面設計界面數(shù)據(jù)說明第六十三頁，共一百五十一頁，編輯于2023年，星期二借書界面設計界面事件及響應說明第六十四頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的還書界面第六十五頁，共一百五十一頁，編輯于2023年，星期二11.3.4設計類的方法交互圖中的消息映射為接受消息的對象類的方法（操作）消息表達式中的參數(shù)和返回值等映射為類方法函數(shù)的參數(shù)和返回值同義詞釋疑：操作是關于行為的定義，方法是行為的實現(xiàn)，服務是行為的對外表現(xiàn)，消息是行為如何協(xié)作，它們用于不同的角度、場合、時機和模型中，但可以將它們認為是同義詞第六十六頁，共一百五十一頁，編輯于2023年，星期二1.職責類的方法是對象應該執(zhí)行的操作，也稱為對象的職責和義務。職責是在設計過程中分配給每個類的，可以采取的方法有：使用交互圖使用CRC技術第六十七頁，共一百五十一頁，編輯于2023年，星期二職責完成的兩種情況一項職責的完成有以下兩種情況：1.由某個對象獨立承擔，比如“計算超期天數(shù)”由一個Loan對象負責。2.主要由一個對象負責，但該對象將職責進行了二次分配或分解。比如“負責計算訂單總額”應該由一個Order對象負責，Order類為了完成該職責，需求OrderItem對象的協(xié)作，OrderItem對象負責提供每個訂單項的小計金額（數(shù)量*單價）。軟件對象的職責分配可以映射到現(xiàn)實世界中的分工和協(xié)作，例如：部門經(jīng)理A布置業(yè)務人員B完成一項任務x，B可能一個人獨立承擔該任務，B也可能將任務分解為x1、x2、x3，自己負責x1和x2，請C負責x3。第六十八頁，共一百五十一頁，編輯于2023年，星期二職責的兩種類型職責有兩種類型：1.行為型：即對象本身的方法。比如進行一項計算、被創(chuàng)建時的初始化、執(zhí)行控制或協(xié)調(diào)的各項活動。2.了解型：對象應掌握的信息。比如對象自身的數(shù)據(jù)和屬性、相關聯(lián)的對象以及能夠派生或計算的對象（set/get方法），如Loan類需要了解借出和歸還日期（屬性），以及所借資源的有關情況，即ResourceItem或ResourceTitle對象（關聯(lián)對象）。第六十九頁，共一百五十一頁，編輯于2023年，星期二CRC卡片法CRC卡片法是一種職責分配技術，CRC是類-職責-協(xié)作（Class-Responsibility-Collaboration）的簡稱。具體實踐過程：首先為系統(tǒng)中每個軟件類制作一張卡片選取一個用例，確定該用例的參與類取出上述確定的類卡片通過移動卡片來討論類如何協(xié)作完成用例功能最后將形成的職責概念記錄在類所在的卡片上。雖然它不是UML的組成部分，但也是一種快捷有效的的OO設計技術。直接建模（繪制順序圖）同理。第七十頁，共一百五十一頁，編輯于2023年，星期二2.對象交互建模交互模型的設計內(nèi)容：對象職責的識別，意味著對象協(xié)作過程中消息的分發(fā)定義消息的完整格式將消息映射為類的操作，并在實現(xiàn)時轉化為類的方法第七十一頁，共一百五十一頁，編輯于2023年，星期二3.消息的設計消息規(guī)范化設計，需要使用以下表達式語法：return:=message(parameter:parameterType):returnType如果類型信息非常明顯或不重要的話，可以省略書寫，如：reader:=getReader(cardID:String)消息的序號消息的次序用自小到大的順序號來表示。按照消息的完成情況，消息可以有嵌套消息（代表任務分解）。嵌套消息的序號按照層次編號，所有嵌套的子消息都是服務于其上層消息。第七十二頁，共一百五十一頁，編輯于2023年，星期二嵌套消息嵌套消息含義與結構化方法中的模塊調(diào)用相同結構化方法中模塊都是單個的，沒有分組。面向對象方法也強調(diào)模塊的概念，但模塊都有一個主人——對象OOD中的模塊劃分要解決兩個問題：任務如何分解為子任務？各個任務應由誰承擔？第七十三頁，共一百五十一頁，編輯于2023年，星期二嵌套消息示例計算超期罰金，最高不超過書價Loan對象在計算超期罰金時還需要獲取資源的價格和罰金標準，因此向ResourceItem發(fā)送請求價格的消息，向FineRule發(fā)送超期罰金標準，而ResourceItem對象并不記錄價格，因此請求價格的消息還需要發(fā)送給ResourceTitle對象。第七十四頁，共一百五十一頁，編輯于2023年，星期二嵌套消息示例代碼Loan::getTotalFine():double{ titlePrice=itemObject.getTitlePrice(); finePerDay=fineObject.getOverDueFine();

doublefineAmount=finePerDay*(this.returnDate–this.dueDate); if(fineAmount<titlePrice) returnfineAmount; else returntitlePrice;}ResourceItem::getTitlePrice():double{ returnitsTitleObject.getPrice();}第七十五頁，共一百五十一頁，編輯于2023年，星期二返回消息很多消息發(fā)送之后，消息的接收對象會在響應后產(chǎn)生一些結果回傳給發(fā)送者，這就是返回消息。在UML交互圖中，返回消息以虛線箭頭線表示。為了簡潔，一般省略返回消息。第七十六頁，共一百五十一頁，編輯于2023年，星期二自身消息有些消息是對象發(fā)給自己的。比如借書界面中要增加一個借閱項目，首先發(fā)送消息給控制類請求業(yè)務邏輯的處理（makeNewLoan消息），然后在窗口的列表中將新的借閱記錄添加進來（addListItem）以備瀏覽和打印，添加列表的功能是界面類的職責，消息應發(fā)給窗口對象自身通常是一個類內(nèi)部的private方法第七十七頁，共一百五十一頁，編輯于2023年，星期二兩類特殊的消息對象創(chuàng)建UML中使用create消息表示對象實例化和初始化。例如，在C#和Java中，使用new操作符接構造函數(shù)的調(diào)用方式來實現(xiàn)實例的自動分配和初始化。常在設計類圖中忽略相關的方法。屬性存取在某些語言中，所有屬性都聲明為私有的，因此需要發(fā)送消息實現(xiàn)屬性的存取。例如getPrice和setPrice。為了模型的簡潔，有時也省略這些消息，但在類圖中可以通過屬性的可見性來明確它們是否存在。第七十八頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的借書界面第七十九頁，共一百五十一頁，編輯于2023年，星期二圖書館順序圖1借書（分析階段，消息使用中文）第八十頁，共一百五十一頁，編輯于2023年，星期二設計階段——圖書館順序圖示例loop借書（消息對應為類的方法）第八十一頁，共一百五十一頁，編輯于2023年，星期二圖書館系統(tǒng)的還書界面第八十二頁，共一百五十一頁，編輯于2023年，星期二圖書館順序圖2還書（備選事件流使用opt框架，表示可選分支）：loop第八十三頁，共一百五十一頁，編輯于2023年，星期二圖書館順序圖2還書（主事件流，簡單的備選事件流可以畫在一張圖上，復雜的備選事件流可以另畫一張順序圖）loop第八十四頁，共一百五十一頁，編輯于2023年，星期二4.為類添加方法對象職責體現(xiàn)為順序圖中類所收到的消息，也就是類的方法。類的方法可以定義可見性，當然順序圖中的絕大多數(shù)消息是公有方法。第八十五頁，共一百五十一頁，編輯于2023年，星期二實體類的方法類圖（包含屬性和方法）：第八十六頁，共一百五十一頁，編輯于2023年，星期二11.3.5設計類的關系設計四種關系的具體實現(xiàn)：泛化（類）關聯(lián)（對象）實現(xiàn)（類）依賴（對象）第八十七頁，共一百五十一頁，編輯于2023年，星期二1.泛化設計泛化在面向對象語言中使用繼承來實現(xiàn)，繼承機制實現(xiàn)了子類擁有父類特性的這一過程。泛化設計還有一個更重要的目的在于如何實現(xiàn)多態(tài)性。第八十八頁，共一百五十一頁，編輯于2023年，星期二2.關聯(lián)設計實現(xiàn)對象關聯(lián)的一個簡單策略就是：在關聯(lián)的源類中聲明一個屬性來保存對目標類的實例的引用，這種屬性稱為關聯(lián)屬性或引用屬性。根據(jù)關聯(lián)的導航性，有單向關聯(lián)和雙向關聯(lián)。根據(jù)關聯(lián)重數(shù)，有一對一、一對多和多對多關聯(lián)，多對多關聯(lián)通過建立關聯(lián)類分解成1對多的關聯(lián)。限定關聯(lián)。第八十九頁，共一百五十一頁，編輯于2023年，星期二單向關聯(lián)//實現(xiàn)代碼對照：publicclassResourceTitle{ privateReservationr1; privateMapitems=newHaspMap();

…}第九十頁，共一百五十一頁，編輯于2023年，星期二重數(shù)為0..1的關聯(lián)對于可選關聯(lián)，源對象雖然定義了目標對象，但目標對象可能為空值（通常為null值），意味著沒有關聯(lián)對象。如某種書當前不存在預定記錄。關聯(lián)屬性的值可以在源對象的構造函數(shù)中被創(chuàng)建，也可能在運行過程中通過方法賦值。publicclassResourceTitle{ privateReservationtheReserve; //關聯(lián)屬性

publicReservationgetReservation(){//獲取關聯(lián)對象

returntheReserve; } publicvoidsetReservation(Reservationrs){ theReserve=rs; }}第九十一頁，共一百五十一頁，編輯于2023年，星期二重數(shù)為多的關聯(lián)對于重數(shù)為多的關聯(lián)，源對象應該能夠管理多個目標對象。實現(xiàn)這種關聯(lián)最簡單的方法是使用開發(fā)語言提供的類庫中的容器類來保存多個對象引用，如Map、List類等。示例代碼如下：publicclassResourceTitle{ privateMapitems=newHaspMap(); //集合關聯(lián)屬性

publicvoidaddItem(StringitemID){ //對象也可作參數(shù)

ResourceItemaCopy=newResourceItem(itemID); items.put(itemID,aCopy); } publicvoidremoveItem(StringitemID){ items.remove(itemID); }}第九十二頁，共一百五十一頁，編輯于2023年，星期二雙向關聯(lián)當關聯(lián)雙方需要相互都能訪問到對方時，就是雙向關聯(lián)。比如Loan能知道所借的是哪一個ResourceItem，并且ResourceItem能夠訪問到對應的Loan。具體實現(xiàn)有多種辦法，以下代碼是一種示例。publicclassResourceItem{ privateLoantheLoan; //關聯(lián)屬性

publicvoidaddLoan(Loanloan){ //建立雙向關聯(lián)

theLoan=newLoan(this); }

……}publicclassLoan{ privateResourceItemtheItem; //關聯(lián)屬性

publicLoan(ResourceItemr){ //Loan的構造函數(shù)

theItem=r; //建立和ResourceItem的關聯(lián)

}

……}第九十三頁，共一百五十一頁，編輯于2023年，星期二關聯(lián)的創(chuàng)建或解除關聯(lián)可以在對象一產(chǎn)生就已經(jīng)存在，也可以在運行期間動態(tài)建立。對于那些比較持久并且不會發(fā)生變化的關聯(lián)，或者具有很強歸屬關系的聚集關聯(lián)，一般在主對象的構造函數(shù)中創(chuàng)建關聯(lián)對象或記錄下關聯(lián)對象的引用較為松散的對象關聯(lián)，一般當某項業(yè)務邏輯發(fā)生時，兩個對象的關聯(lián)才被確立，可以設計特定方法建立或解除關聯(lián)。第九十四頁，共一百五十一頁，編輯于2023年，星期二動態(tài)創(chuàng)建關聯(lián)舉例publicClassCar

privateDrivertheDriver;

…… publicvoidassignDriver(Driverdr){theDriver=dr }}Carc1=newCar(“京B58888”,“紅旗”);Driverd1=NewDriver("Wang");Driverd2

=NewDriver("Zhao");c1.assignDriver(d1); //建立c1和d1之間的關聯(lián)……c1.assignDriver(d2); //建立c1和d2之間的關聯(lián)，c1和d1的關聯(lián)被解除第九十五頁，共一百五十一頁，編輯于2023年，星期二3.接口與實現(xiàn)的設計所有的實體類都具有這些數(shù)據(jù)庫操作行為，將這些操作抽象出來封裝到一個IEntityOperate接口中public

interface

IEntityOperate{

int

InsertEntity(); //插入對象數(shù)據(jù)到數(shù)據(jù)庫中int

UpdateEntity(); //更新對象數(shù)據(jù)到數(shù)據(jù)庫中

int

DeleteEntity(); //刪除數(shù)據(jù)庫中指定對象數(shù)據(jù)}第九十六頁，共一百五十一頁，編輯于2023年，星期二4.依賴設計在類圖中依賴關系通常指明一個類的對象實例使用了另一個類的屬性和方法。界面層使用了控制層對象，控制層對象使用了數(shù)據(jù)訪問層對象。第九十七頁，共一百五十一頁，編輯于2023年，星期二類的耦合類之間的聯(lián)系的緊密程度就是類之間的耦合度。四種關系的耦合程度從高至低：泛化實現(xiàn)關聯(lián)依賴（上層對象依賴于下層對象）第九十八頁，共一百五十一頁，編輯于2023年，星期二類的內(nèi)聚類的合理封裝內(nèi)部屬性和方法的關系緊密單一職責的類不要雜湊類不要大而全的類第九十九頁，共一百五十一頁，編輯于2023年，星期二11.4對象持久化與數(shù)據(jù)庫軟件中的對象在程序中定義的對象，在系統(tǒng)運行期間其生命周期包含創(chuàng)建、使用和消亡三個階段。因為程序所有代碼和數(shù)據(jù)在運行時載入到內(nèi)存，程序運行結束它們都要從內(nèi)存中釋放，所以這些對象實例都是瞬時的或暫時性的。信息系統(tǒng)中的對象一個信息系統(tǒng)中的領域類指代了系統(tǒng)中有意義的事物，這些領域對象及其所承載的信息是長期的，甚至是永久的。這些持久對象就是指生存期可以超越軟件的一次執(zhí)行時間而長期存在的對象。軟件對象如何持久化？第一百頁，共一百五十一頁，編輯于2023年，星期二持久化對象持久對象就是指生存期可以超越程序的任意一次執(zhí)行時間而長期存在的對象。比如新建了一名讀者對象，程序結束后該讀者的基本信息將轉化為持久保存的讀者數(shù)據(jù)，這個過程也是通常所說的“物化”。反過來，持久后的數(shù)據(jù)需要取出并重新生成對象，這個過程稱為“反物化”。通常實體對象都會成為持久對象，實體類也稱為持久類。第一百零一頁，共一百五十一頁，編輯于2023年，星期二11.4.1幾種持久化方案文件從文件查詢有關數(shù)據(jù)來初始化對象或創(chuàng)建一個新對象。對象發(fā)生改變或需要保存，則將對象數(shù)據(jù)寫入到文件中（如XML文件）。但復雜靈活的數(shù)據(jù)存取和查詢難以實現(xiàn)。面向對象數(shù)據(jù)庫管理系統(tǒng)（OODBMS）一種理想的基于存儲和管理永久對象的對象管理系統(tǒng)，只要程序員聲明某個對象是永久的，OODBMS中數(shù)據(jù)庫模型和對象模型一致。對象的存儲、恢復、轉換等問題由OODBMS自動解決。但目前尚未達到廣泛應用的階段。成熟的關系型數(shù)據(jù)庫系統(tǒng)（RDBMS）關系型數(shù)據(jù)庫以二維表中的一條記錄來保存某個對象，記錄的字段對應對象屬性，繼承關系或關聯(lián)關系通過表之間的聯(lián)系表現(xiàn)。對象與關系兩個概念之間存在“阻抗”，因此需要進行映射。該方案是目前最普及的選擇。其他的存儲機制還有層次數(shù)據(jù)庫、網(wǎng)狀數(shù)據(jù)庫等等第一百零二頁，共一百五十一頁，編輯于2023年，星期二持久化設計的步驟確定持久類及其持久屬性確定持久化方案設計XML文件模式（Schema）或設計關系數(shù)據(jù)庫的模型根據(jù)持久化方案設計持久化方法或持久化組件第一百零三頁，共一百五十一頁，編輯于2023年，星期二關系型數(shù)據(jù)庫的持久化方案在確定持久類及其持久屬性之后，還要解決以下問題：實體類如何對應到關系中的表呢？類的繼承關系和對象關聯(lián)如何體現(xiàn)？關系數(shù)據(jù)庫的操作總結起來就是CRUD操作：創(chuàng)建記錄（Create）、查詢記錄（Retrieve）、修改記錄（Update）和刪除記錄（Delete），這些操作應該由誰來實現(xiàn)？什么時候使用？對象實例是內(nèi)存的一個單元，使用實例名來標識，表中的記錄則采用唯一的主鍵碼來識別，如何實現(xiàn)特定對象實例和記錄的一一對應呢？第一百零四頁，共一百五十一頁，編輯于2023年，星期二11.4.2ORM設計問題無論自己編寫代碼實現(xiàn)持久化，還是使用持久化組件，都要解決一個問題，那就是：對象與數(shù)據(jù)庫的映射關系。采用關系型數(shù)據(jù)庫實現(xiàn)對象的數(shù)據(jù)存儲，這種映射也稱為對象-關系映射ORM（ObjectRelationalMapping）。ORM的設計包括：確定對象和表的映射關系確定軟件實現(xiàn)構架第一百零五頁，共一百五十一頁，編輯于2023年，星期二1、對象-關系的映射類映射到表關聯(lián)關系的映射繼承關系的映射第一百零六頁，共一百五十一頁，編輯于2023年，星期二持久類映射到表在一個第三范式的關系數(shù)據(jù)庫中，表中每一行（每個“元組”）都被認為是一個對象。表中的列則對應于持久類的持久屬性（注意：持久類也可能有臨時屬性）。在沒有其他關聯(lián)類的簡單情況下，這兩種模型間的映射將會很簡單。類的屬性對應于列，其數(shù)據(jù)類型轉換為列允許的數(shù)據(jù)類型之一。

第一百零七頁，共一百五十一頁，編輯于2023年，星期二關聯(lián)關系的映射兩個持久對象間的關聯(lián)關系在OOAD中通常表現(xiàn)為一個對象存放了另一個對象的對象引用（也稱為關聯(lián)屬性），而在表中則表現(xiàn)為外鍵。外鍵是一個表中的一列，其中存放所關聯(lián)對象的主鍵值。對于對象關聯(lián)中的特殊類型——組成聚集，因為整體對象和部分對象具有相同的生存周期，因此為了在數(shù)據(jù)模型中實現(xiàn)引用完整性，數(shù)據(jù)庫詳細設計時還需要實施刪除約束，比如刪除圖書館某個資源品種就必須同時刪除所有的資源項。以及參照完整性的設計第一百零八頁，共一百五十一頁，編輯于2023年，星期二ReaderLoan借閱1*讀者：

讀者編號，讀者姓名，讀者單位，當前限額借書記錄：

ID，讀者編號，館藏流水號，借書日期，到期日期，歸還日期館藏項：館藏流水號，當前狀態(tài)ResourceItem0..11記載第一百零九頁，共一百五十一頁，編輯于2023年，星期二繼承關系的映射

三種可選方式：繼承關系樹的每個類對應一個表：使用不同的表來分別表示父類和子類。繼承關系樹的每個具體類對應一個表：將所有父類的屬性復制為子類表中不同的列，父類不建立對應的表。繼承關系樹只對應一個表：使用一張表來描述父類和所有子類的屬性，額外還需要增加一個列表示對象所屬的子類型。第一百一十頁，共一百五十一頁，編輯于2023年，星期二BookDiscResourceTitle1、三個表：品種：ISBN，名稱，作者，出版日期，價格…書籍：ISBN，開本光盤：ISBN，光盤類型，盤片數(shù)量2、兩個表：書籍：ISBN，名稱，作者…，開本光盤：ISBN，名稱，作者…，光盤類型，盤片數(shù)量3、一個表品種：ISBN，名稱，作者…，品種類別，開本，光盤類型，盤片數(shù)量第一百一十一頁，共一百五十一頁，編輯于2023年，星期二2、持久化軟件架構設計（1）在領域層實現(xiàn)，即直接在實體類中編寫SQL語句訪問數(shù)據(jù)庫，或者為了減少數(shù)據(jù)庫操作的代碼數(shù)量，編寫一個公用的數(shù)據(jù)訪問類，各實體類將組裝好的SQL語句傳遞給該類以實現(xiàn)數(shù)據(jù)庫訪問。（2）設計簡單的數(shù)據(jù)映射層實現(xiàn)數(shù)據(jù)訪問，即把SQL訪問從業(yè)務邏輯中分離出來，放到獨立的類中。當每個實體類映射為一張表時，可以為每個實體類建立一個數(shù)據(jù)訪問類，一般包括數(shù)據(jù)查找方法以及更新、插入和刪除方法。（3）設計功能獨立具有數(shù)據(jù)映射器的持久層。業(yè)務邏輯層完全不用了解數(shù)據(jù)的存儲，應用程序中的對象通過設置與表的映射關系后，可以在開發(fā)人員對底層數(shù)據(jù)庫及其模型毫不知情的情況下實現(xiàn)數(shù)據(jù)的持久化。映射關系通過數(shù)據(jù)映射器來具體實施，它是分離內(nèi)存對象和數(shù)據(jù)庫的一個軟件層，其職責是在內(nèi)存對象和數(shù)據(jù)庫之間傳遞數(shù)據(jù)并保持它們彼此獨立。第一百一十二頁，共一百五十一頁，編輯于2023年，星期二三種設計方法的舉例參見用戶權限的VB程序，實體類負責數(shù)據(jù)庫的訪問參見微軟PetShop程序，數(shù)據(jù)庫訪問通過編寫數(shù)據(jù)訪問層的類來實現(xiàn)。比如業(yè)務層的類Order，有Insert、getOrder方法分別完成保存和查詢的功能，這些方法中使用了數(shù)據(jù)訪問層的類來讀寫數(shù)據(jù)庫網(wǎng)上可查閱Hibernate示例程序，代碼中不需要編寫SQL語句第一百一十三頁，共一百五十一頁，編輯于2023年，星期二11.5設計原則總的原則抽象與復用（封裝、信息隱藏）松耦合面向功能模塊設計功能內(nèi)聚的模塊，避免使用全局數(shù)據(jù)模塊傳遞的參數(shù)作數(shù)據(jù)用，并且盡可能少模塊內(nèi)語句數(shù)一般為50-100面向對象單一職責、開放封閉、里氏替換、依賴倒置…面向服務標準化服務合約、服務松散耦合、服務抽象、服務可復用、服務自治、服務無狀態(tài)、服務可發(fā)現(xiàn)性和服務可組合性第一百一十四頁，共一百五十一頁，編輯于2023年，星期二11.5.1抽象與復用模塊化：模塊是廣泛意義上的建模元素，可以是子過程或函數(shù)、類、構件、服務、流程等。模塊化強調(diào)抽象和封裝。好的抽象能讓人們集中精力考慮問題實質，而忽略問題中與主旨無關的次要部分。好的封裝能讓一個部件暴露出其最本質的內(nèi)容，讓人們快速理解和使用它，不讓復雜性蔓延。模塊化的另一個好處就是復用。不同業(yè)務流程中重復對一組數(shù)據(jù)執(zhí)行同一操作，對這類數(shù)據(jù)和操作進行合理抽象和封裝后，就能在多個地方進行復用，節(jié)約了成本，提高了效率。第一百一十五頁，共一百五十一頁，編輯于2023年，星期二11.5.2松耦合任何事物只要相互之間存在某種關系，就意味著事物間的耦合。緊耦合：是指應用系統(tǒng)的各部件在功能上、數(shù)據(jù)上或結構上是緊密相連的，因而每當某個部件發(fā)生變化時，相關部分的也要隨之進行部分甚至整個應用程序的調(diào)整。松耦合：面對變化則具有很好的適應能力和應變能力。耦合和內(nèi)聚有著密切關系，通常高內(nèi)聚就會帶來松耦合。第一百一十六頁，共一百五十一頁，編輯于2023年，星期二11.5.3單一職責原則SRP即內(nèi)聚性原則。單一職責的模塊—>單一職責的類。一個類承擔的職責過多，某個職責的變化可能會削弱或者抑制該類完成其他職責的能力，并影響到構建、測試和部署等活動。多職責會導致脆弱的和不易理解的設計。職責過多的職工類第一百一十七頁，共一百五十一頁，編輯于2023年，星期二分離職責到不同的類對“雜湊類”進行分解第一百一十八頁，共一百五十一頁，編輯于2023年，星期二11.5.4開放封閉原則OCP軟件實體（類、模塊、函數(shù)等）應該是“可擴展”的，但又是“不可修改”的?！白兓攀遣蛔兊恼胬怼?，但通過設計使得系統(tǒng)能夠適應改變又能保持相對穩(wěn)定，避免僵化的設計。開放-封閉原則實現(xiàn)兩個目標：“對于擴展是開放的”（openforextension）。這意味著模塊的行為是可擴展的，從而使其具有滿足那些改變的新需求。“對于更改是封閉的”（closedformodification）。當對模塊進行擴展時，不必改動模塊的源代碼或二進制代碼（如dll/jar文件）。自相矛盾嗎？第一百一十九頁，共一百五十一頁，編輯于2023年，星期二什么是不封閉、不開放如下的模型可以處理月薪制（SALARIED）和時薪制（WAGED）職工工資，時薪制根據(jù)考勤卡計算。如果增加了一種新的職工類型，其計酬方式不同（如提成制），則必定要修改Employee類（即Employee是不封閉的），如果讓其封閉，開放擴展又是不可能的。第一百二十頁，共一百五十一頁，編輯于2023年，星期二如何改進利用抽象機制封閉：Employee及其已有的子類是封閉的，不可改開放：可以派生新的子類，實現(xiàn)新的需求，可擴展第一百二十一頁，共一百五十一頁，編輯于2023年，星期二11.5.5Liscov替換原則LSP實現(xiàn)OCP的主要機制是抽象和多態(tài)。怎樣設計最佳的繼承層次，BarbaraLiskov在1988年首次提出LSP：子類型（subtype）必須能夠替換掉它們的基類型（basetype）。假設S是T的子類型，所有使用了T對象的程序(也稱客戶程序)，用S對象替換T對象后，仍能成功執(zhí)行。LSP是多態(tài)順利實現(xiàn)的保證，從而使OCP成為可能。因為正是子類型的可替換性才使得使用基類的模塊在無需修改的情況下就可以擴展。增加或修改任何一個子類型，基類不用修改（封閉）基類的使用者（客戶程序）通過多態(tài)得到擴展或修改過的行為（開放）。第一百二十二頁，共一百五十一頁，編輯于2023年，星期二一個使用繼承的例子正方形是長方形的一種特例第一百二十三頁，共一百五十一頁，編輯于2023年，星期二會發(fā)生什么情況？正方形有獨特的行為方式通過覆蓋父類的有關方法來實現(xiàn)子類行為第一百二十四頁，共一百五十一頁，編輯于2023年，星期二客戶程序如何能了解長方形的使用者按照長方形的特點來調(diào)用SetWidth和SetHeight兩個函數(shù)，并測試面積，代碼如下：voidtestArea(Rectangle&r){ r.SetWidth(5); r.SetHeight(4); assert(r.Area()==20);}如果傳遞進來的是Square對象又會如何呢？顯然會出現(xiàn)斷言錯誤，測試失敗。對于客戶程序來說，模型中的層次結構是脆弱的，因為違反了LSP替換原則，Square對象和Rectangle對象的行為方式不相容，這樣的抽象即使采用虛函數(shù)也無法實現(xiàn)子類對父類的替換。違反LSP替換原則，多態(tài)的使用是不安全的。第一百二十五頁，共一百五十一頁，編輯于2023年，星期二11.5.6依賴倒置原則DIP高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象（也稱針對抽象編程）；抽象不應該依賴于細節(jié)，細節(jié)應該依賴于抽象。結構化設計時，高層模塊總是依賴于低層模塊。面向對象的分層模式中也是高層的類依賴于底層的類。按照自上而下的依賴關系，高層的策略設置模塊往往是無法重用的，如果設法讓高層模塊獨立于低層模塊，則實現(xiàn)重用就變?yōu)榭赡堋Ｒ蕾嚨怪迷瓌t的啟發(fā)式建議是“依賴于抽象”，具體做法是將高層需要的服務聲明為抽象接口，高層使用這些接口，低層模塊實現(xiàn)這些接口，使得高層不再依賴于低層，而是依賴于抽象接口，同樣低層也依賴于抽象接口。第一百二十六頁，共一百五十一頁，編輯于2023年，星期二傳統(tǒng)的依賴層次高層使用低層的對象及其服務第一百二十七頁，共一百五十一頁，編輯于2023年，星期二都依賴于抽象設計抽象接口，上層類使用接口，下層類實現(xiàn)接口這樣Button類也可以得到重用，也許是開關燈，也許是開關電視，根據(jù)創(chuàng)建具體對象完成多態(tài)的行為。第一百二十八頁，共一百五十一頁，編輯于2023年，星期二如何遵守設計原則設計原則不是死記硬背，而是要靈活運用一些成熟的設計模式可以幫助我們解決實際問題，并且符合設計原則第一百二十九頁，共一百五十一頁，編輯于2023年，星期二11.6軟件設計模式GRASP對象職責分配模式GRASP（GeneralResponsibilityAssignmentSoftwarePattern）是一組通用的基本原則和慣用的設計方案，用來指導對象職責的分配和交互圖的創(chuàng)建。OOAD經(jīng)典著作《UML和模式應用》進行了總結和應用。GoF23種設計模式由四人組的專著《設計模式》一書總結了廣為應用的23種設計模式，每種模式解決了一個特定問題，包括一組合適的對象和對象接口，以及對象間協(xié)作的方式。第一百三十頁，共一百五十一頁，編輯于2023年，星期二模式無處不在好萊塢電影模式社會題材、動作片、言情片、歷史題材片…中國象棋開局當頭炮、順炮、列炮、屏風馬…圍棋布局星小目、三連星、中國流、宇宙流…古代行軍布陣八陣圖、天門陣、一字長蛇陣…建筑、服裝、交通、社會、文化…諸多模式模式是對成功應用經(jīng)驗的總結與復用第一百三十一頁，共一百五十一頁，編輯于2023年，星期二設計模式的基本思想-1軟件是在不斷進化的需求在不斷改變，所以軟件應該適應變化設計模式是為了讓軟件更加適應變化，有更多的可復用性；就是有變化時你不用從頭重寫一次這個軟件如何適應變化？就應該封裝變化，讓變化的影響最小封裝復雜性，提供簡單的接口第一百三十二頁，共一百五十一頁，編輯于2023年，星期二設計模式的基本思想-2遵守上述設計原則：松耦合針對接口編程，而不是針對實現(xiàn)編程使用繼承、組合、委托、多態(tài)、泛型第一百三十三頁，共一百五十一頁，編輯于2023年，星期二11.6.1什么是設計模式美國建筑設計大師ChristopherAlexander，在他出版的一本關于城市規(guī)劃和建筑設計的著作《建筑的永恒方法》中，是這樣描述模式的：模式是一條由三部分組成的規(guī)則，它表示了一個特定環(huán)境、一個問題和一個解決方案之間的關系。每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題以及該問題解決方案的核心內(nèi)容。這樣，你就能一次又一次地使用該方案而不必做重復勞動。Eachpatterndescribesaproblemwhichoccursoverandoveragaininourenvironments,andthendescribesthecoreofthesolutiontothatproblem,insuchawaythatyoucanusethissolutionamilliontimesover,withouteverdoingitthesamewaytwice. --ChristopherAlexander,

APatternLanguage,1977第一百三十四頁，共一百五十一頁，編輯于2023年，星期二設計模式名成為專業(yè)詞匯討論設計方案時，使用模式名能簡化描述第一百三十五頁，共一百五十一頁，編輯于2023年，星期二設計模式是：優(yōu)秀的設計范例從優(yōu)秀設計方案中發(fā)現(xiàn)和總結出來的經(jīng)驗在實踐中反復出現(xiàn)的設計問題的優(yōu)秀解決方案設計者相互交流的基本術語：設計語言培養(yǎng)優(yōu)秀設計師的一條捷徑不是：面向對象設計的框架可供簡單組合的設計元件發(fā)明創(chuàng)造出來的創(chuàng)新思路解決面向對象設計問題的完整方案第一百三十六頁，共一百五十一頁，編輯于2023年，星期二設計模式的基本要素名稱：用于助記，形象表示這個模式問題：這個模式可以解決什么問題解決方案：這個模式怎樣解決這個問題的步驟與方法效果：使用這個模式與不使用這個模式有什么區(qū)別，它有什么優(yōu)點和缺點一個問題可以有多種解法，好的解法都可以找到很多種，每種都有優(yōu)缺點，某個模式也不一定永遠是最好的第一百三十七頁，共一百五十一頁，編輯于2023年，星期二11.6.2GoF設計模式GangofFour，簡稱GoF，他們是：ErichGammaRichardHelmRalphJohnsonJohnVlissides（2005年底去世）著作《設計模式》第一百三十八頁，共一百五十一頁，編輯于2023年，星期二23種GoF模式創(chuàng)建型結構型行為型類FactoryMethod