北郵軟件工程課件面向?qū)ο笤O計

第8章面向?qū)ο笤O計退出如前所述，分析是提取和整理用戶需求，并建立問題域精確模型的過程。設計則是把分析階段得到的需求轉(zhuǎn)變成符合成本和質(zhì)量要求的、抽象的系統(tǒng)實現(xiàn)方案的過程。從面向?qū)ο蠓治龅矫嫦驅(qū)ο笤O計(通?？s寫為OOD)，是一個逐漸擴充模型的過程。或者說，面向?qū)ο笤O計就是用面向?qū)ο笥^點建立求解域模型的過程。第8章面向?qū)ο笤O計退出如前所述，分析是提1盡管分析和設計的定義有明顯區(qū)別，但是在實際的軟件開發(fā)過程中二者的界限是模糊的。許多分析結(jié)果可以直接映射成設計結(jié)果，而在設計過程中又往往會加深和補充對系統(tǒng)需求的理解，從而進一步完善分析結(jié)果。因此，分析和設計活動是一個多次反復迭代的過程。面向?qū)ο蠓椒▽W在概念和表示方法上的一致性，保證了在各項開發(fā)活動之間的平滑(無縫)過渡，領域?qū)＜液烷_發(fā)人員能夠比較容易地跟蹤整個系統(tǒng)開發(fā)過程，這是面向?qū)ο蠓椒ㄅc傳統(tǒng)方法比較起來所具有的一大優(yōu)勢。盡管分析和設計的定義有明顯區(qū)別，但是在實際的軟件2生命周期方法學把設計進一步劃分成總體設計和詳細設計兩個階段，類似地，也可以把面向?qū)ο笤O計再細分為系統(tǒng)設計和對象設計。系統(tǒng)設計確定實現(xiàn)系統(tǒng)的策略和目標系統(tǒng)的高層結(jié)構(gòu)。對象設計確定解空間中的類、關聯(lián)、接口形式及實現(xiàn)服務的算法。系統(tǒng)設計與對象設計之間的界限，比分析與設計之間的界限更模糊，本書不再對它們加以區(qū)分。生命周期方法學把設計進一步劃分成總體設計和詳細設38.1面向?qū)ο笤O計的準則8.2啟發(fā)規(guī)則8.3系統(tǒng)分解8.4設計問題域子系統(tǒng)8.5設計人-機交互子系統(tǒng)8.6設計任務管理子系統(tǒng)8.1面向?qū)ο笤O計的準則48.7設計數(shù)據(jù)管理子系統(tǒng)8.8設計類中的服務8.9設計關聯(lián)8.10設計優(yōu)化8.11面向?qū)ο蠓治雠c設計實例8.12小結(jié)8.7設計數(shù)據(jù)管理子系統(tǒng)58.1面向?qū)ο笤O計的準則所謂優(yōu)秀設計，就是權(quán)衡了各種因素，從而使得系統(tǒng)在其整個生命周期中的總開銷最小的設計。對大多數(shù)軟件系統(tǒng)而言，60%以上的軟件費用都用于軟件維護，因此，優(yōu)秀軟件設計的一個主要特點就是容易維護。8.1面向?qū)ο笤O計的準則所謂優(yōu)秀設計，就是68.1.1模塊化8.1.2抽象8.1.3信息隱藏8.1.4弱耦合1.交互耦合如果對象之間的耦合通過消息連接來實現(xiàn)，則這種耦合就是交互耦合。為使交互耦合盡可能松散，應該遵守下述準則?！けM量降低消息連接的復雜程度。應該盡量減少消息中包含的參數(shù)個數(shù)，降低參數(shù)的復雜程度?！p少對象發(fā)送(或接收)的消息數(shù)。8.1.1模塊化72.繼承耦合與交互耦合相反，應該提高繼承耦合程度。繼承是一般化類與特殊類之間耦合的一種形式。從本質(zhì)上看，通過繼承關系結(jié)合起來的基類和派生類，構(gòu)成了系統(tǒng)中粒度更大的模塊。因此，它們彼此之間應該結(jié)合得越緊密越好。為獲得緊密的繼承耦合，特殊類應該確實是對它的一般化類的一種具體化，也就是說，它們之間在邏輯上應該存在“ISA”的關系。因此，如果一個派生類摒棄了它基類的許多屬性，則它們之間是松耦合的。在設計時應該使特殊類盡量多繼承并使用其一般化類的屬性和服務，從而更緊密地耦合到其一般化類。2.繼承耦合88.1.5強內(nèi)聚1.服務內(nèi)聚一個服務應該完成一個且僅完成一個功能。2.類內(nèi)聚設計類的原則是，一個類應該只有一個用途，它的屬性和服務應該是高內(nèi)聚的。類的屬性和服務應該全都是完成該類對象的任務所必需的，其中不包含無用的屬性或服務。如果某個類有多個用途，通常應該把它分解成多個專用的類。3.一般—特殊內(nèi)聚設計出的一般—特殊結(jié)構(gòu)，應該符合多數(shù)人的概念，更準確地說，這種結(jié)構(gòu)應該是對相應的領域知識的正確抽取。8.1.5強內(nèi)聚98.1.6可重用軟件重用是提高軟件開發(fā)生產(chǎn)率和目標系統(tǒng)質(zhì)量的重要途徑。重用基本上從設計階段開始。重用有兩方面的含義：一是盡量使用已有的類(包括開發(fā)環(huán)境提供的類庫，及以往開發(fā)類似系統(tǒng)時創(chuàng)建的類)，二是如果確實需要創(chuàng)建新類，則在設計這些新類的協(xié)議時，應該考慮將來的可重復使用性。8.1.6可重用108.2啟發(fā)規(guī)則8.2.1設計結(jié)果應該清晰易懂使設計結(jié)果清晰、易讀、易懂，是提高軟件可維護性和可重用性的重要措施。顯然，人們不會重用那些他們不理解的設計。保證設計結(jié)果清晰易懂的主要因素如下。1.用詞一致2.使用已有的協(xié)議3.減少消息模式的數(shù)目4.避免模糊的定義8.2啟發(fā)規(guī)則8.2.1設計結(jié)果應該清晰118.2.2一般—特殊結(jié)構(gòu)的深度應適當應該使類等級中包含的層次數(shù)適當。8.2.3設計簡單的類應該盡量設計小而簡單的類，以便于開發(fā)和管理。1.避免包含過多的屬性2.有明確的定義3.盡量簡化對象之間的合作關系4.不要提供太多服務8.2.2一般—特殊結(jié)構(gòu)的深度應適當128.2.4使用簡單的協(xié)議一般來說，消息中的參數(shù)不要超過3個。8.2.5使用簡單的服務面向?qū)ο笤O計出來的類中的服務通常都很小，一般只有3～5行源程序語句，可以用僅含一個動詞和一個賓語的簡單句子描述它的功能。8.2.6把設計變動減至最小通常，設計的質(zhì)量越高，設計結(jié)果保持不變的時間也越長。8.2.4使用簡單的協(xié)議13圖8.1理想的設計變動情況圖8.1理想的設計變動情況148.3系統(tǒng)分解大多數(shù)系統(tǒng)的面向?qū)ο笤O計模型，在邏輯上都由四大部分組成。這四大部分對應于組成目標系統(tǒng)的四個子系統(tǒng)，它們分別是問題域子系統(tǒng)，人-機交互子系統(tǒng)、任務管理子系統(tǒng)和數(shù)據(jù)管理子系統(tǒng)。當然，在不同的軟件系統(tǒng)中，這四個子系統(tǒng)的重要程度和規(guī)?？赡芟嗖詈艽?，規(guī)模過大的在設計過程中應該進一步劃分成更小的子系統(tǒng)，規(guī)模過小的可合并在其他子系統(tǒng)中。某些領域的應用系統(tǒng)在邏輯上可能僅由3個(甚至少于3個)子系統(tǒng)組成。8.3系統(tǒng)分解大多數(shù)系統(tǒng)的面向?qū)ο笤O計模型，15圖8.2典型的面向?qū)ο笤O計模型圖8.2典型的面向?qū)ο笤O計模型168.3.1子系統(tǒng)之間的兩種交互方式在軟件系統(tǒng)中，子系統(tǒng)之間的交互有兩種可能的方式，分別是客戶—供應商(Client_supplier)關系和平等伙伴(peer_to_peer)關系。1.客戶—供應商關系2.平等伙伴關系總的說來，單向交互比雙向交互更容易理解，也更容易設計和修改，因此應該盡量使用客戶—供應商關系。8.3.1子系統(tǒng)之間的兩種交互方式178.3.2組織系統(tǒng)的兩種方案把子系統(tǒng)組織成完整的系統(tǒng)時，有水平層次組織和垂直塊組織兩種方案可供選擇。1.層次組織這種組織方案把軟件系統(tǒng)組織成一個層次系統(tǒng)，每層是一個子系統(tǒng)。上層在下層的基礎上建立，下層為實現(xiàn)上層功能而提供必要的服務。每一層內(nèi)所包含的對象，彼此間相互獨立，而處于不同層次上的對象，彼此間往往有關聯(lián)。實際上，在上、下層之間存在客戶—供應商關系。低層子系統(tǒng)提供服務，相當于供應商，上層子系統(tǒng)使用下層提供的服務，相當于客戶。8.3.2組織系統(tǒng)的兩種方案182.塊狀組織這種組織方案把軟件系統(tǒng)垂直地分解成若干個相對獨立的、弱耦合的子系統(tǒng)，一個子系統(tǒng)相當于一塊，每塊提供一種類型的服務。8.3.3設計系統(tǒng)的拓撲結(jié)構(gòu)由子系統(tǒng)組成完整的系統(tǒng)時，典型的拓撲結(jié)構(gòu)有管道型、樹型、星型等。設計者應該采用與問題結(jié)構(gòu)相適應的、盡可能簡單的拓撲結(jié)構(gòu)，以減少子系統(tǒng)之間的交互數(shù)量。2.塊狀組織198.4設計問題域子系統(tǒng)通過面向?qū)ο蠓治鏊贸龅膯栴}域精確模型，為設計問題域子系統(tǒng)奠定了良好的基礎，建立了完整的框架。只要可能，就應該保持面向?qū)ο蠓治鏊⒌膯栴}域結(jié)構(gòu)。通常，面向?qū)ο笤O計僅需從實現(xiàn)角度對問題域模型作一些補充或修改，主要是增添、合并或分解類—＆—對象、屬性及服務，調(diào)整繼承關系等。當問題域子系統(tǒng)過分復雜龐大時，應該把它進一步分解成若干個更小的子系統(tǒng)。8.4設計問題域子系統(tǒng)通過面向?qū)ο蠓治鏊贸?0下面介紹，在面向?qū)ο笤O計過程中，可能對面向?qū)ο蠓治鏊贸龅膯栴}域模型作的補充或修改。8.4.1調(diào)整需求8.4.2重用已有的類8.4.3把問題域類組合在一起在面向?qū)ο笤O計過程中，設計者往往通過引入一個根類而把問題域類組合在一起。8.4.4增添一般化類以建立協(xié)議8.4.5ATM系統(tǒng)之例圖8.4描繪了上章給出的ATM系統(tǒng)的問題域子系統(tǒng)的結(jié)構(gòu)。下面介紹，在面向?qū)ο笤O計過程中，可能對面向?qū)ο蠓?18.5設計人-機交互子系統(tǒng)8.5.1設計人-機交互界面的準則遵循下列準則有助于設計出讓用戶滿意的人-機交互界面。1.一致性使用一致的術(shù)語，一致的步驟，一致的動作。

8.5設計人-機交互子系統(tǒng)8.5.1設計人222.減少步驟應使用戶為做某件事情而需敲擊鍵盤的次數(shù)、點按鼠標的次數(shù)、或者下拉菜單的距離，都減至最少。還應使得技術(shù)水平不同的用戶，為獲得有意義的結(jié)果所需使用的時間都減至最少。特別應該為熟練用戶提供簡捷的操作方法(例如，熱鍵)。3.及時提供反饋信息每當用戶等待系統(tǒng)完成一項工作時，系統(tǒng)都應該向用戶提供有意義的、及時的反饋信息，以便用戶能夠知道系統(tǒng)目前已經(jīng)完成該項工作的多大比例。2.減少步驟234.提供撤消命令人在與系統(tǒng)交互的過程中難免會犯錯誤，因此，應該提供“撤消(undo)”命令，以便用戶及時撤消錯誤動作，消除錯誤動作造成的后果。5.無須記憶不應該要求用戶記住在某個窗口中顯示的信息，然后再用到另一個窗口中，這是軟件系統(tǒng)的責任而不是用戶的任務。此外，在設計人-機交互部分時應該力求達到下述目標：用戶在使用該系統(tǒng)時用于思考人-機交互方法所花費的時間減至最少，而用于做他實際想做的工作所用的時間達到最大值。更理想的情況是，人-機交互界面能夠增強用戶的能力。4.提供撤消命令246.易學人-機交互界面應該易學易用，應該提供聯(lián)機參考資料，以便用戶在遇到困難時可隨時參閱。7.富有吸引力人-機交互界面不僅應該方便、高效，還應該使人在使用時感到心情愉快，能夠從中獲得樂趣，從而吸引人去使用它。6.易學258.5.2設計人-機交互子系統(tǒng)的策略1.分類用戶為了更好地了解用戶的需要與愛好，以便設計出符合用戶需要的界面，設計者首先應該把將來可能與系統(tǒng)交互的用戶分類。通常從下列幾個不同角度進行分類?！ぐ醇寄芩椒诸?新手/初級/中級/高級)?！ぐ绰殑辗诸?總經(jīng)理/經(jīng)理/職員)?！ぐ此鶎偌瘓F分類(職員/顧客)。8.5.2設計人-機交互子系統(tǒng)的策略262.描述用戶應該仔細了解將來使用系統(tǒng)的每類用戶的情況，把獲得的下列各項信息記錄下來。·用戶類型。·使用系統(tǒng)欲達到的目的。·特征(年齡、性別、受教育程度、限制因素等)?！りP鍵的成功因素(需求、愛好、習慣等)。·技能水平?！ね瓿杀韭毠ぷ鞯哪_本。2.描述用戶273.設計命令層次設計命令層次的工作通常包含以下幾項內(nèi)容。(1)研究現(xiàn)有的人-機交互含義和準則(2)確定初始的命令層次所謂命令層次，實質(zhì)上是用過程抽象機制組織起來的、可供選用的服務的表示形式。設計命令層次時，通常先從對服務的過程抽象著手，然后再進一步修改它們，以適合具體應用環(huán)境的需要。3.設計命令層次28(3)精化命令層次為進一步修改完善初始的命令層次，應該考慮下列一些因素?！ご涡颍鹤屑氝x擇每個服務的名字，并在命令層的每一部分內(nèi)把服務排好次序。排序時或者把最常用的服務放在最前面，或者按照用戶習慣的工作步驟排序。·整體—部分關系：尋找在這些服務中存在的整體—部分模式，這樣做有助于在命令層中分組組織服務。(3)精化命令層次29·寬度和深度：由于人的短期記憶能力有限，命令層次的寬度和深度都不應該過大?！げ僮鞑襟E：應該用盡量少的單擊、拖動和擊鍵組合來表達命令，而且應該為高級用戶提供簡捷的操作方法。4.設計人-機交互類人-機交互類與所使用的操作系統(tǒng)及編程語言密切相關?！挾群蜕疃龋河捎谌说亩唐谟洃浤芰τ邢蓿顚?08.6設計任務管理子系統(tǒng)8.6.1分析并發(fā)性通過面向?qū)ο蠓治鼋⑵饋淼膭討B(tài)模型，是分析并發(fā)性的主要依據(jù)。如果兩個對象彼此間不存在交互，或者它們同時接受事件，則這兩個對象在本質(zhì)上是并發(fā)的。8.6設計任務管理子系統(tǒng)8.6.1分析318.6.2設計任務管理子系統(tǒng)常見的任務有事件驅(qū)動型任務、時鐘驅(qū)動型任務、優(yōu)先任務、關鍵任務和協(xié)調(diào)任務等。設計任務管理子系統(tǒng)，包括確定各類任務并把任務分配給適當?shù)挠布蜍浖?zhí)行。1.確定事件驅(qū)動型任務某些任務是由事件驅(qū)動的，這類任務可能主要完成通信工作。2.確定時鐘驅(qū)動型任務某些任務每隔一定時間間隔就被觸發(fā)以執(zhí)行某些處理，例如，某些設備需要周期性地獲得數(shù)據(jù)；某些人-機接口、子系統(tǒng)、任務、處理器或其他系統(tǒng)也可能需要周期性地通信。在這些場合往往需要使用時鐘驅(qū)動型任務。8.6.2設計任務管理子系統(tǒng)323.確定優(yōu)先任務優(yōu)先任務可以滿足高優(yōu)先級或低優(yōu)先級的處理需求?！じ邇?yōu)先級：某些服務具有很高的優(yōu)先級，為了在嚴格限定的時間內(nèi)完成這種服務，可能需要把這類服務分離成獨立的任務?！さ蛢?yōu)先級：與高優(yōu)先級相反，有些服務是低優(yōu)先級的，屬于低優(yōu)先級處理(通常指那些背景處理)。設計時可能用額外的任務把這樣的處理分離出來。3.確定優(yōu)先任務334.確定關鍵任務關鍵任務是有關系統(tǒng)成功或失敗的關鍵處理，這類處理通常都有嚴格的可靠性要求。在設計過程中可能用額外的任務把這樣的關鍵處理分離出來，以滿足高可靠性處理的要求。對高可靠性處理應該精心設計和編碼，并且應該嚴格測試。5.確定協(xié)調(diào)任務當系統(tǒng)中存在三個以上任務時，就應該增加一個任務，用它作為協(xié)調(diào)任務。4.確定關鍵任務346.盡量減少任務數(shù)必須仔細分析和選擇每個確實需要的任務。應該使系統(tǒng)中包含的任務數(shù)盡量少。7.確定資源需求使用多處理器或固件，主要是為了滿足高性能的需求。設計者必須通過計算系統(tǒng)載荷(即每秒處理的業(yè)務數(shù)及處理一個業(yè)務所花費的時間)，來估算所需要的CPU(或其他固件)的處理能力。6.盡量減少任務數(shù)358.7設計數(shù)據(jù)管理子系統(tǒng)數(shù)據(jù)管理子系統(tǒng)是系統(tǒng)存儲或檢索對象的基本設施，它建立在某種數(shù)據(jù)存儲管理系統(tǒng)之上，并且隔離了數(shù)據(jù)存儲管理模式(文件、關系數(shù)據(jù)庫或面向?qū)ο髷?shù)據(jù)庫)的影響。8.7.1選擇數(shù)據(jù)存儲管理模式不同的數(shù)據(jù)存儲管理模式有不同的特點，適用范圍也不相同，設計者應該根據(jù)應用系統(tǒng)的特點選擇適用的模式。8.7設計數(shù)據(jù)管理子系統(tǒng)數(shù)據(jù)管理子系統(tǒng)是系統(tǒng)361.文件管理系統(tǒng)2.關系數(shù)據(jù)庫管理系統(tǒng)3.面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)是一種新技術(shù)，主要有兩種設計途徑：擴展的關系數(shù)據(jù)庫管理系統(tǒng)和擴展的面向?qū)ο蟪绦蛟O計語言。1.文件管理系統(tǒng)378.7.2設計數(shù)據(jù)管理子系統(tǒng)設計數(shù)據(jù)管理子系統(tǒng)，既需要設計數(shù)據(jù)格式又需要設計相應的服務。1.設計數(shù)據(jù)格式設計數(shù)據(jù)格式的方法與所使用的數(shù)據(jù)存儲管理模式密切相關，下面分別介紹適用于每種數(shù)據(jù)存儲管理模式的設計方法。(1)文件系統(tǒng)(2)關系數(shù)據(jù)庫管理系統(tǒng)(3)面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)8.7.2設計數(shù)據(jù)管理子系統(tǒng)382.設計相應的服務如果某個類的對象需要存儲起來，則在這個類中增加一個屬性和服務，用于完成存儲對象自身的工作。下面介紹使用不同數(shù)據(jù)存儲管理模式時的設計要點。(1)文件系統(tǒng)注意，為提高性能應該批量處理訪問文件的要求。(2)關系數(shù)據(jù)庫管理系統(tǒng)(3)面向?qū)ο髷?shù)據(jù)庫管理系統(tǒng)8.7.3例子2.設計相應的服務398.8設計類中的服務8.8.1確定類中應有的服務需要綜合考慮對象模型、動態(tài)模型和功能模型，才能正確確定類中應有的服務。對象模型是進行對象設計的基本框架。但是，面向?qū)ο蠓治龅贸龅膶ο竽Ｐ?，通常只在每個類中列出很少幾個最核心的服務。設計者必須把動態(tài)模型中對象的行為以及功能模型中的數(shù)據(jù)處理，轉(zhuǎn)換成由適當?shù)念愃峁┑姆铡?.8設計類中的服務8.8.1確定類中應408.8.2設計實現(xiàn)服務的方法在面向?qū)ο笤O計過程中還應該進一步設計實現(xiàn)服務的方法，主要應該完成以下幾項工作。1.設計實現(xiàn)服務的算法設計實現(xiàn)服務的算法時，應該考慮下列幾個因素。(1)算法復雜度(2)容易理解與容易實現(xiàn)(3)易修改2.選擇數(shù)據(jù)結(jié)構(gòu)3.定義內(nèi)部類和內(nèi)部操作8.8.2設計實現(xiàn)服務的方法418.9設計關聯(lián)在對象模型中，關聯(lián)是聯(lián)結(jié)不同對象的紐帶，它指定了對象相互間的訪問路徑。在面向?qū)ο笤O計過程中，設計人員必須確定實現(xiàn)關聯(lián)的具體策略。8.9.1關聯(lián)的遍歷在應用系統(tǒng)中，使用關聯(lián)有兩種可能的方式：單向遍歷和雙向遍歷。8.9設計關聯(lián)在對象模型中，關聯(lián)是聯(lián)結(jié)不同對428.9.2實現(xiàn)單向關聯(lián)用指針可以方便地實現(xiàn)單向關聯(lián)。如果關聯(lián)的階是一元的(如圖8.5所示)，則實現(xiàn)關聯(lián)的指針是一個簡單指針；如果階是多元的，則需要用一個指針集合實現(xiàn)關聯(lián)(參見圖8.6)。8.9.3實現(xiàn)雙向關聯(lián)許多關聯(lián)都需要雙向遍歷，當然，兩個方向遍歷的頻度往往并不相同。實現(xiàn)雙向關聯(lián)有下列三種方法。

·只用屬性實現(xiàn)一個方向的關聯(lián)，當需要反向遍歷時就執(zhí)行一次正向查找?！蓚€方向的關聯(lián)都用屬性實現(xiàn)?！び锚毩⒌年P聯(lián)對象實現(xiàn)雙向關聯(lián)。8.9.2實現(xiàn)單向關聯(lián)43圖8.5用指針實現(xiàn)單向關聯(lián)(a)關聯(lián)；(b)實現(xiàn)圖8.5用指針實現(xiàn)單向關聯(lián)44圖8.6用指針實現(xiàn)雙向關聯(lián)(a)關聯(lián)；(b)實現(xiàn)圖8.6用指針實現(xiàn)雙向關聯(lián)458.9.4鏈屬性的實現(xiàn)如果某個關聯(lián)具有鏈屬性，則實現(xiàn)它的方法取決于關聯(lián)的階數(shù)。對于一對一關聯(lián)來說，鏈屬性可作為其中一個對象的屬性而存儲在該對象中。對于一對多關聯(lián)來說，鏈屬性可作為“多”端對象的一個屬性。如果是多對多關聯(lián)，則鏈屬性不可能只與一個關聯(lián)對象有關，通常使用一個獨立的類來實現(xiàn)鏈屬性，這個類的每個實例表示一條鏈及該鏈的屬性(參見圖8.7)。8.9.4鏈屬性的實現(xiàn)46圖8.7用對象實現(xiàn)關聯(lián)圖8.7用對象實現(xiàn)關聯(lián)478.10設計優(yōu)化8.10.1確定優(yōu)先級系統(tǒng)的各項質(zhì)量指標并不是同等重要的，設計人員必須確定各項質(zhì)量指標的相對重要性(即確定優(yōu)先級)，以便在優(yōu)化設計時制定折衷方案。8.10設計優(yōu)化8.10.1確定優(yōu)先級488.10.2提高效率的幾項技術(shù)1.增加冗余關聯(lián)以提高訪問效率2調(diào)整查詢次序3.保留派生屬性8.10.2提高效率的幾項技術(shù)49圖8.8公司、雇員及技能之間的關聯(lián)鏈圖8.8公司、雇員及技能之間的關聯(lián)鏈50圖8.9為雇員技能數(shù)據(jù)庫建立索引圖8.9為雇員技能數(shù)據(jù)庫建立索引518.10.3調(diào)整繼承關系在面向?qū)ο笤O計過程中，建立良好的繼承關系是優(yōu)化設計的一項重要內(nèi)容。下面討論與建立類繼承有關的問題。1.抽象與具體在設計類繼承時，很少使用純粹自頂向下的方法。通常的作法是，首先創(chuàng)建一些滿足具體用途的類，然后對它們進行歸納，一旦歸納出一些通用的類以后，往往可以根據(jù)需要再派生出具體類。在進行了一些具體化(即專門化)的工作之后，也許就應該再次歸納了。對于某些類繼承來說，這是一個持續(xù)不斷的演化過程。8.10.3調(diào)整繼承關系52(a)先創(chuàng)建一些具體類；(b)歸納出抽象類；(c)進一步具體化；(d)再次歸納圖8.10設計類繼承的例子(a)先創(chuàng)建一些具體類；(b)歸納出抽象類；(c)進一532.為提高繼承程度而修改類定義如果在一組相似的類中存在公共的屬性和公共的行為，則可以把這些公共的屬性和行為抽取出來放在一個共同的祖先類中，供其子類繼承，如圖8.10(a)和(b)所示。在對現(xiàn)有類進行歸納的時候，要注意下述兩點：(1)不能違背領域知識和常識；(2)應該確?，F(xiàn)有類的協(xié)議(即同外部世界的接口)不變。2.為提高繼承程度而修改類定義543.利用委托實現(xiàn)行為共享僅當存在真實的一般—特殊關系(即子類確實是父類的一種特殊形式)時，利用繼承機制實現(xiàn)行為共享才是合理的。如果你只想把繼承作為實現(xiàn)操作共享的一種手段，則利用委托(即把一類對象作為另一類對象的屬性，從而在兩類對象間建立組合關系)也可以達到同樣目的，而且這種方法更安全。使用委托機制時，只有有意義的操作才委托另一類對象實現(xiàn)，因此，不會發(fā)生不慎繼承了無意義(甚至有害)操作的問題。3.利用委托實現(xiàn)行為共享55(a)用繼承實現(xiàn)；(b)用委托實現(xiàn)圖8.11用表實現(xiàn)棧的兩種方法(a)用繼承實現(xiàn)；(b)用委托實現(xiàn)568.11面向?qū)ο蠓治雠c設計實例8.11.1面向?qū)ο蠓治?.需求這個類庫管理系統(tǒng)的主要用途，是管理用戶在用C++語言開發(fā)軟件的漫長過程中逐漸積累起來的類，以便在今后的軟件開發(fā)過程中能夠從庫中方便地選取出可重用的類。它應該具有編輯(包括添加、修改和刪除)、儲存和瀏覽等基本功能，下面是對它的具體需求。8.11面向?qū)ο蠓治雠c設計實例8.11.1面57·管理用C+[KG-*4/9]+語言定義的類?！び脩裟軌蚍奖愕叵蝾悗熘刑砑有碌念?，并能建立新類與庫中原有類的關系?！び脩裟軌蛲ㄟ^類名從類庫中查詢出指定的類?！び脩裟軌虿榭椿蛐薷呐c指定類有關的信息(包括數(shù)據(jù)成員的定義、成員函數(shù)的定義及這個類與其他類的關系)。·用戶能夠從類庫中刪除指定的類?！び脩裟軌蛟跒g覽窗口中方便、快速地瀏覽當前類的父類和子類?！す芾碛肅+[KG-*4/9]+語言定義的類。58·具有“聯(lián)想”瀏覽功能，也就是說，可以把當前類的某個子類或父類指定為新的當前類，從而瀏覽這個新當前類的父類和子類?！び脩裟軌虿榭椿蛐薷哪硞€類的指定成員函數(shù)的源代碼?！け鞠到y(tǒng)是一個簡化的多用戶系統(tǒng)，每個用戶都可以建立自己的類庫，不同類庫之間互不干擾。·對于用戶的誤操作或錯誤的輸入數(shù)據(jù)，系統(tǒng)能給出適當?shù)奶崾拘畔ⅲ⑶胰匀焕^續(xù)穩(wěn)定地運行?！は到y(tǒng)易學易用，用戶界面應該是GUI的?！ぞ哂小奥?lián)想”瀏覽功能，也就是說，可以把當前類的某個子類或592.建立對象模型(1)確定類—＆—對象從對這個類庫管理系統(tǒng)的需求不難看出，組成這個系統(tǒng)的基本對象是“類庫”和“類”。類是類庫中的“條目”，不妨把它稱為“類條目”(ClassEntry)。類條目中應該包含的信息(即它的屬性)主要有類名、父類列表、成員函數(shù)列表和數(shù)據(jù)成員列表。一個類可能有多個父類(多重繼承)，對于它的每個父類來說，應該保存的信息主要是該父類的名字、訪問權(quán)及虛基類標志(是否是虛基類)。對于每個成員函數(shù)來說，主要應該保存函數(shù)名、訪問權(quán)、虛函數(shù)標志(是否是虛函數(shù))、返回值類型、參數(shù)及函數(shù)代碼等信息。在每個數(shù)據(jù)成員中主要應該記錄數(shù)據(jù)名、訪問權(quán)和數(shù)據(jù)類型等信息。我們把“父類”、“成員函數(shù)”和“數(shù)據(jù)成員”也都作為對象。2.建立對象模型60根據(jù)對這個類庫管理系統(tǒng)的需求可以想到，類條目應該提供的服務主要是：設置或更新類名；添加、刪除和更改父類；添加、刪除和更改成員函數(shù)；添加、刪除和更改數(shù)據(jù)成員。類庫包含的信息主要是庫名和類條目列表。類庫應該提供的服務主要是：向類庫中插入一個類條目；從類庫中刪除一個類條目；把類庫儲存到磁盤上；從磁盤中讀出類庫(放到內(nèi)存中)。根據(jù)對這個類庫管理系統(tǒng)的需求可以想到，類條目應該61(2)分析類—＆—對象之間的關系在這個問題域中，各個類—＆—對象之間的邏輯關系相當簡單。分析系統(tǒng)需求，并結(jié)合關于C++語言語法的知識，可以知道問題域中各個類—＆—對象之間的關系是：一個用戶擁有多個類庫，每個類庫由0或多個類條目組成，每個類條目由0或多個父類，0或多個數(shù)據(jù)成員及0或多個成員函數(shù)組成。圖812是本問題域的對象模型。本系統(tǒng)的功能和控制流程都比較簡單，無須建立動態(tài)模型和功能模型，僅用對象模型就可以很清楚地描述這個系統(tǒng)了。事實上，在用面向?qū)ο蠓椒ㄩ_發(fā)軟件的過程中，建立系統(tǒng)對象模型是最關鍵的工作。(2)分析類—＆—對象之間的關系62圖8.12類庫管理系統(tǒng)的對象模型圖8.12類庫管理系統(tǒng)的對象模型638.11.2面向?qū)ο笤O計1.設計類庫結(jié)構(gòu)通常，類庫中包含一組類，這一組類通過歸納、組合等關系組成一個有機的整體，其中歸納(即繼承)關系對于重用來說具有特別重要的意義。8.11.2面向?qū)ο笤O計64由于C++語言支持多重繼承，類庫中相當多的類可能具有多個父類，因此，容易表示具有多個父類的類應該作為選擇類庫結(jié)構(gòu)的一條準則。此外，簡單、方便、容易實現(xiàn)編輯操作和容易遍歷，對這個系統(tǒng)來說也很重要。經(jīng)過權(quán)衡，我們決定采用鏈表結(jié)構(gòu)來組織類庫。因為在每個類條目中都有它的父類列表，查找一個類的父類非常容易。查找一個類的子類則需遍歷類庫，雖然開銷較大但算法卻相當簡單。為了提高性能，可以增加冗余關聯(lián)(即建立索引)，以加快查找子類的速度。由于C++語言支持多重繼承，類庫中相當多的類可能652.設計問題域子系統(tǒng)通過面向?qū)ο蠓治?，我們對問題域已經(jīng)有了較深入的了解，圖8.12總結(jié)了我們對問題域的認識。在面向?qū)ο笤O計過程中，僅需從實現(xiàn)的角度出發(fā)，并根據(jù)我們所設計的類庫結(jié)構(gòu)，對圖8.12所示的對象模型做一些補充和細化。(1)類條目(ClassEntry)(2)類庫(ClassEntryLink)(3)父類(ClassBase)，成員函數(shù)(ClassFun)和數(shù)據(jù)成員(ClassData)綜上所述，我們可以畫出類庫(ClassEntryLink)的示意圖(見圖8.13)。2.設計問題域子系統(tǒng)66圖8.13類庫示意圖圖8.13類庫示意圖67(4)類條目緩沖區(qū)(ClassEntryBuffer)當編輯或查看類信息時，每個時刻用戶只能面對一個類條目，我們把這個類稱為當前類。為便于處理當前類，額外設置一個類條目緩沖區(qū)。它是從ClassEntry類派生出來的類，除了繼承ClassEntry類中定義的數(shù)據(jù)成員和成員函數(shù)之外，主要增加了一些用于與窗口或類鏈交換數(shù)據(jù)的成員函數(shù)。每當用戶要查看或編輯有關指定類的信息時，就把這個類條目從類庫(即類鏈)中取到類條目緩沖區(qū)中。用戶對這個類條目所做的一切編輯操作都只針對緩沖區(qū)中的數(shù)據(jù)，如果用戶有編輯操作完成后不“確認”他的操作，則緩沖區(qū)中的數(shù)據(jù)不送回類庫，因而也就不會修改類庫的內(nèi)容。(4)類條目緩沖區(qū)(ClassEntryBuf683.設計人-機交互子系統(tǒng)(1)窗口為方便用戶使用，本系統(tǒng)采用圖形用戶界面。主要設計了下述一些窗口。①登錄窗口②主窗口③創(chuàng)建窗口