第八章 面向對象設計

第八章面向對象設計內容提綱軟件體系結構–基本概念與設計文檔體系結構風格–倉庫體系結構–模型／視圖／控制器結構–控制結構–客戶機／服務器結構–分層體系結構設計模式–抽象工廠（AbstractFactory）模式–狀態(tài)（State）模式–外觀（Fa?ade）模式–觀察者（Observer）模式軟件體系結構軟件體系結構包括一組軟件部件、軟件部件的外部的可見特性及其相互關系，其中軟件外部的可見特性是指軟件部件提供的服務、性能、特性、錯誤處理、共享資源使用等。–系統(tǒng)的總體組織結構和全局控制結構–通信、同步和數(shù)據(jù)訪問的協(xié)議–設計元素的組成與功能分配–非功能需求–系統(tǒng)的物理部署–備選設計方案的選擇軟件體系結構

包依賴性

?依賴性–PackageA的一些成員引用PackageB的某些成員–PackageB的變化可能會影響到PackageA循環(huán)依賴的消除

循環(huán)依賴的消除

體系結構風格?軟件體系結構風格是描述某一特定應用領域中系統(tǒng)組織方式的慣用模式，它反映了領域中眾多系統(tǒng)所共有的結構和語義特性，并指導如何將各個模塊和子系統(tǒng)有效地組織成一個完整系統(tǒng)。?典型的軟件體系結構風格–倉庫或知識庫結構–模型／視圖／控制器體系結構–控制結構–客戶機／服務器結構–分層體系結構倉庫結構?倉庫或知識庫結構（Repositoryarchitecture）倉庫結構

倉庫結構是一種以數(shù)據(jù)為中心的體系結構，它包含一個中心數(shù)據(jù)庫和一組相互獨立的處理中心數(shù)據(jù)的子系統(tǒng)，主要適合于數(shù)據(jù)由一個子系統(tǒng)產生而由其他子系統(tǒng)使用的情形。?優(yōu)點：在共享數(shù)據(jù)模型穩(wěn)定的情況下，擴展新的子系統(tǒng)十分容易?缺點：子系統(tǒng)與共享數(shù)據(jù)之間的耦合度很高，共享數(shù)據(jù)將對系統(tǒng)的性能和子系統(tǒng)的修改產生瓶頸。?應用：現(xiàn)代編譯器、管理信息系統(tǒng)、CAD系統(tǒng)和CASE工具集等。倉庫結構倉庫結構

模型/視圖/控制器結構（Model/View/ControllerArchitecture）–該結構是為同樣的數(shù)據(jù)提供多個視圖的應用程序而設計的，它將交互系統(tǒng)的組成分解成模型、視圖、控制器三種部件。?視圖是應用程序中用戶界面相關的部分，即用戶看到并與之交互的界面。?控制器工作就是根據(jù)用戶的輸入，控制用戶界面數(shù)據(jù)顯示和更新模型對象的狀態(tài)。?模型是應用程序的主體部分，表示業(yè)務數(shù)據(jù)或者業(yè)務邏輯。–該結構適合于交互式系統(tǒng)，特別是同一個模型需要多個視圖的情況。模型/視圖/控制器結構

模型/視圖/控制器結構控制結構?該結構關心的是子系統(tǒng)之間的控制流–集中式控制

?一個子系統(tǒng)專門負責控制，控制其他子系統(tǒng)的啟動和停止。它也可能將控制交給一個子系統(tǒng)，但在控制完成后控制權仍然要歸還給它。

–基于事件的控制

?控制信息不是集中于一個子系統(tǒng)中，而是每個子系統(tǒng)都能接收來自外部的事件并對此作出響應。這些事件可能來自其他子系統(tǒng)或來自系統(tǒng)的環(huán)境。控制結構控制結構客戶機／服務器結構?客戶機／服務器結構（Client/ServerArchitecture）

–在客戶機／服務器體系結構中，作為服務器的子系統(tǒng)為其他客戶機的子系統(tǒng)提供服務，作為客戶機的子系統(tǒng)負責與用戶的交互。?瘦客戶機模型

–所有的應用處理和數(shù)據(jù)管理都是在服務器上執(zhí)行，客戶機只是負責數(shù)據(jù)表示部分。–由于繁重的處理負荷全部集中在服務器和網絡上，有可能造成性能上的問題?？蛻魴C／服務器結構?胖客戶機模型–服務器只負責對數(shù)據(jù)的管理，客戶機上的軟件實現(xiàn)應用邏輯與用戶的交互。–系統(tǒng)管理更加復雜，因為應用程序的改變必須在客戶機上重新安裝。?三層的客戶機／服務器體系結構分層體系結構?層次化是一種概念，它將軟件設計組織成為類或組件的層次或集合，在同一個層次上的類或組件完成一個特定的目的。?良好的層次結構可以易于系統(tǒng)的擴展與維護，不同的層次之間通過接口進行通信。?三層體系結構（Three-tierArchitecture）–表示層：窗口、報表等用戶界面元素–應用邏輯層：管理業(yè)務過程的任務和規(guī)則–存儲層：持久化存儲機構分層體系結構MiniLibrary：軟件體系結構設計模式?回顧學過的數(shù)據(jù)結構–Trees,Stacks,Queues–它們給軟件開發(fā)帶來了什么？?問題–在軟件體系結構設計中是否存在一些可重用的解決方案？?答案是肯定的–設計模式使我們可以重用已經成功的經驗–Pattern＝Documentedexperience設計模式設計模式?設計模式描述了軟件系統(tǒng)設計過程中常見問題的解決方案，它是從大量的成功實踐中總結出來的且被廣泛公認的實踐和知識。?設計模式的好處–使人們可以簡便地重用已有的良好設計–提供了一套可供開發(fā)人員交流的語言–提升了人們看待問題的抽象程度–幫助設計人員更快更好地完成系統(tǒng)設計–模式是經過考驗的思想，具有更好的可靠性和擴展性設計模式的風險?設計模式不是萬能的–模式可以解決大多數(shù)問題，但不可能解決遇到的所有問題–應用一種模式一般會“有得有失”，切記不可盲目應用–濫用設計模式可能會造成過度設計，反而得不償失?設計模式是有難度和風險的–一個好的設計模式是眾多優(yōu)秀軟件設計師集體智慧的結晶–在設計過程中引入模式的成本是很高的–設計模式只適合于經驗豐富的開發(fā)人員使用設計模式的基本要素?模式名稱–一個助記名，便于交流和思考?問題–描述應該在何時使用模式，解釋了設計問題和問題存在的前因后果?解決方案–描述設計的組成部分，它們之間的相互關系以及各自的職責和協(xié)作方式?效果–描述模式應用的效果以及應權衡的問題設計模式的類型?創(chuàng)建型模式–創(chuàng)建型模式描述了實例化對象的相關技術，解決了與創(chuàng)建對象有關的問題。–創(chuàng)建型模式使用繼承來改變被實例化的類，而一個對象創(chuàng)建型模式將實例化委托給另一個對象。?典型的模式–工廠方法（FactoryMethod）、抽象工廠（AbstractFactory）–生成器（Builder）、原型（Prototype）、單件（Singleton）設計模式的類型?結構型模式–結構型模式描述了在軟件系統(tǒng)中組織類和對象的常用方法，避免了一個類被賦予過多職責而破壞類的封裝性和信息的隱藏，和類之間功能重疊的問題。–結構型模式采用繼承機制來組合接口或實現(xiàn)。?典型的模式–適配器Adapter、橋接Bridge、組成Composite–裝飾Decorator、外觀Facade、享元Flyweight、代理Proxy設計模式的類型行為模式–行為模式負責分配對象的職責，為對象間協(xié)作建模提供了有效的策略。–行為模式使用繼承機制在類件分配行為。?典型的模式–職責鏈ChainofResponsibility、命令Command、–解釋器Interpreter、迭代器Iterator、中介者Mediator–備忘錄Memento、觀察者Observer、狀態(tài)State

–策略Strategy、模板方法TemplateMethod、訪問者Visitor設計模式示例?抽象工廠（AbstractFactory）模式–抽象工廠模式是用于封裝具體的平臺，從而使應用程序可以在不同的平臺上運行。?狀態(tài)（State）模式–狀態(tài)模式允許一個對象在其內部狀態(tài)改變時改變自己行為。?外觀（Fa?ade）模式–外觀模式用簡單的統(tǒng)一接口封裝子系統(tǒng)，從而降低類之間的相關性。?觀察者（Observer）模式–觀察者模式用于定義對象之間一對多的依賴關系，當一個對象的狀態(tài)發(fā)生變化時，所有依賴于它的對象都將得到通知而被自動更新。AbstractFactoryAbstractFactoryStateFa?adeObserver面向對象設計的制品–設計類–用例實現(xiàn)（從設計角度）–設計子系統(tǒng)與接口–體系結構描述（從設計角度）–部署圖–體系結構描述（從部署角度）設計原則模塊化（Modularity）

–將一個復雜的大系統(tǒng)分解成若干個相對簡單的較小部分，稱為子系統(tǒng)（Subsystem）。耦合（Coupling）–耦合表示兩個子系統(tǒng)（或類）之間的關聯(lián)程度。–當一個子系統(tǒng)（或類）發(fā)生變化時對另一個子系統(tǒng)（或類）的影響很小，則稱它們是松散耦合的；反之，如果變化的影響很大時，則稱它們是緊密耦合的設計原則耦合（Coupling）

設計原則?內聚（Cohesion）–內聚性是子系統(tǒng)內部的相關程度。–當子系統(tǒng)中彼此相關的多個對象執(zhí)行類似的任務時，則認為該子系統(tǒng)是高內聚的；反之，當子系統(tǒng)內的多個對象彼此不相關時，則認為是低內聚的。–高內聚的方法做且僅做一件事，這會很容易理解與維護。

?舉例：如果使用一個方法changeItem()完成書目的讀取、增加、修改和刪除等若干方法的功能，有什么問題嗎？–高內聚的類表示且僅表示一種類型的對象。

?舉例：在大學系統(tǒng)中使用Professor而不用Employee，為什么？

面向對象設計的過程MiniLibrary：軟件體系結構

MiniLibrary：軟件體系結構

MiniLibrary：軟件體系結構

識別設計元素

識別設計元素

?確定設計元素的基本原則–如果一個“分析類”比較簡單，代表著單一的邏輯抽象，那么可以將其映射為“設計類”。通常，主動參與者對應的邊界類、控制類和一般的實體類都可以直接映射成設計類。–如果“分析類”的職責比較復雜，很難由單個“設計類”承擔，則應該將其映射成“子系統(tǒng)接口”。通常，被動參與者對應的邊界類被映射成子系統(tǒng)接口。–子系統(tǒng)的劃分應該符合高內聚低耦合的原則。?問題：MiniLibrary系統(tǒng)的分析類哪些應該直接映射成設計類？哪些應該映射成子系統(tǒng)？MiniLibrary：識別設計元素

MiniLibrary：識別設計元素

識別子系統(tǒng)接口–在確定了設計元素之后，需要描述子系統(tǒng)的行為，也就是準確定義接口操作的集合。同時，還要確定“子系統(tǒng)接口”與其他設計元素之間的依賴關系。數(shù)據(jù)存儲策略

?數(shù)據(jù)文件–數(shù)據(jù)文件是由操作系統(tǒng)提供的存儲形式，應用系統(tǒng)將數(shù)據(jù)按字節(jié)順序存儲，并定義如何以及何時檢索數(shù)據(jù)。?關系數(shù)據(jù)庫–在關系數(shù)據(jù)庫中，數(shù)據(jù)是以表的形式存儲在預先定義好的成為Schema的類型中。?面向對象數(shù)據(jù)庫–與關系數(shù)據(jù)庫不同的是，面向對象數(shù)據(jù)庫將對象和關系作為數(shù)據(jù)一起存儲。數(shù)據(jù)存儲策略

?何時選擇文件？–存儲大容量數(shù)據(jù)、臨時數(shù)據(jù)、低信息密度數(shù)據(jù)?何時選擇數(shù)據(jù)庫？–并發(fā)訪問要求高、系統(tǒng)跨平臺、多個應用程序使用相同數(shù)據(jù)?何時選擇關系數(shù)據(jù)庫？–復雜的數(shù)據(jù)查詢–數(shù)據(jù)集規(guī)模大?何時選擇面向對象數(shù)據(jù)庫？–數(shù)據(jù)集處于中等規(guī)模–對象間沒有規(guī)則聯(lián)系部署子系統(tǒng)?部署圖反映了系統(tǒng)中軟件和硬件的物理架構，表示系統(tǒng)運行時的處理節(jié)點以及節(jié)點中組件的配置。檢查系統(tǒng)設計?檢查“正確性”–每個子系統(tǒng)都能追溯到一個用例或一個非功能需求嗎？–每一個用例都能映射到一個子系統(tǒng)嗎？–系統(tǒng)設計模型中是否提到了所有的非功能需求？–每一個參與者都有合適的訪問權限嗎？–系統(tǒng)設計是否與安全性需求一致？?檢查“一致性”–是否將沖突的設計目標進行了排序？–是否有設計目標違背了非功能需求？–是否存在多個子系統(tǒng)或類重名？檢查系統(tǒng)設計?檢查“完整性”–是否處理邊界條件？–是否有用例走查來確定系統(tǒng)設計遺漏的功能？–是否涉及到系統(tǒng)設計的所有方面（如硬件部署、數(shù)據(jù)存儲、訪問控制、遺留系統(tǒng)、邊界條件）？–是否定義了所有的子系統(tǒng)？?檢查“可行性”–系統(tǒng)中是否使用了新的技術或組件？是否對這些技術或組件進行了可行性研究？–在子系統(tǒng)分解環(huán)境中檢查性能和可靠性需求了嗎？–考慮并發(fā)問題了嗎？方法建模?方法建模的過程

–找出滿足基本邏輯要求的操作–補充必要的輔助方法

?初始化類的實例?驗證兩個實例是否等同?……

–完整地描述操作

?確定方法的名稱、參數(shù)、返回值、可見性等?應該遵從程序設計語言的命名規(guī)則

–簡要說明方法的內部實現(xiàn)邏輯方法建模屬性建模?定義屬性–具體說明屬性的名稱、類型、缺省值、可見性等?基本原則–將所有屬性的可見性設置為private；–僅通過set方法更新屬性；–僅通過get方法訪問屬性；–在屬性的set方法中，實現(xiàn)簡單的有效性驗證，而在獨立的驗證方法中實現(xiàn)復雜的邏輯驗證。屬性建模狀態(tài)建模?在詳細設計階段，狀態(tài)建模一般只發(fā)生在依賴狀態(tài)展示不同行為的類上。關系建模?在對象設計階段，需要進一步確定詳細的關聯(lián)關系、依賴關系和聚合關系等。?不同對象之間的可能連接用戶界面的設計原則

用戶控制式–用戶啟動行為并取得結果，如果程序取得控制權的話，用戶也要獲得必要的反饋（一個沙漏、一個等待的指示器或其他類似的東西）。?界面一致性–遵循標準和常規(guī)的方式，應該讓用戶處在一個熟悉的和可預見的環(huán)境之中。

?若應用是為Windows開發(fā)的，則應采用Windows“外觀和感覺”；?菜單、活動按鈕、屏幕區(qū)域等的命名和編碼、對象在屏幕上處于什么位置的標準等的一致性也不能低估。?用戶界面的設計原則

?界面容錯性–一個好的界面應該以一種寬容的態(tài)度允許用戶進行實驗和出錯，用戶在出現(xiàn)錯誤時能夠方便地從錯誤中恢復。?界面可適應性–界面可適應性是指用戶界面應該根據(jù)用戶的個性要求及其對界面的熟知程度而改變，即滿足定制化和個性化的要求。–所謂定制化是在程序中聲明用戶的熟知程度，用戶界面可以根據(jù)熟知程度改變外觀和行為；–所謂個性化是使用戶按照自己的習慣和愛好來設置用戶界面元素。用戶界面的設計原則

?界面美觀性–界面美觀性是視覺上的吸引力，主要體現(xiàn)在具有平衡和對稱性、合適的色彩、各元素具有合理的對齊方式和間隔、相關