面向?qū)ο髮崿F(xiàn)

面向?qū)ο髮崿F(xiàn)第一頁，共五十八頁，編輯于2023年，星期五面向?qū)ο髮崿F(xiàn)主要包括兩項工作：把面向?qū)ο笤O(shè)計結(jié)果翻譯成用某種程序語言書寫的面向?qū)ο蟪绦?；測試并調(diào)試面向?qū)ο蟮某绦颉Ｃ嫦驅(qū)ο蟪绦虻馁|(zhì)量基本上由面向?qū)ο笤O(shè)計的質(zhì)量決定，但是，所采用的程序語言的特點和程序設(shè)計風格也將對程序的可靠性、可重用性及可維護性產(chǎn)生深遠影響。目前，軟件測試仍然是保證軟件可靠性的主要措施，對于面向?qū)ο蟮能浖碚f，情況也是如此。面向?qū)ο鬁y試的目標，也是用盡可能低的測試成本發(fā)現(xiàn)盡可能多的軟件錯誤。第二頁，共五十八頁，編輯于2023年，星期五面向?qū)ο笤O(shè)計的結(jié)果既可以用面向?qū)ο笳Z言、也可以用非面向?qū)ο笳Z言實現(xiàn)。使用面向?qū)ο笳Z言時，由于語言本身充分支持面向?qū)ο蟾拍畹膶崿F(xiàn)，因此，編譯程序可以自動把面向?qū)ο蟾拍钣成涞侥繕顺绦蛑小?2.1程序設(shè)計語言

12.1.1面向?qū)ο笳Z言的優(yōu)點第三頁，共五十八頁，編輯于2023年，星期五到底應該選用面向?qū)ο笳Z言還是非面向?qū)ο笳Z言，關(guān)鍵不在于語言功能強弱。從原理上說，使用任何一種通用語言都可以實現(xiàn)面向?qū)ο蟾拍睢．斎?，使用面向?qū)ο笳Z言，實現(xiàn)面向?qū)ο蟾拍?，遠比使用非面向?qū)ο笳Z言方便，但是，方便性也并不是決定選擇何種語言的關(guān)鍵因素。選擇編程語言的關(guān)鍵因素，是語言的一致的表達能力、可重用性及可維護性。從面向?qū)ο笥^點看來，能夠更完整、更準確地表達問題域語義的面向?qū)ο笳Z言的語法是非常重要的，因為這會帶來下述幾個重要優(yōu)點：第四頁，共五十八頁，編輯于2023年，星期五1.一致的表示方法面向?qū)ο箝_發(fā)基于不隨時間變化的、一致的表示方法。這種表示方法應該從問題域到OOA，從OOA到OOD，最后從OOD到面向?qū)ο缶幊?OOP)，始終穩(wěn)定不變。一致的表示方法既有利于在軟件開發(fā)過程中始終使用統(tǒng)一的概念，也有利于維護人員理解軟件的各種配置成分。第五頁，共五十八頁，編輯于2023年，星期五2.可重用性為了能帶來可觀的商業(yè)利益，必須在更廣泛的范圍中運用重用機制，而不是僅僅在程序設(shè)計這個層次上進行重用。因此，在OOA，OOD直到OOP中都顯式地表示問題域語義，其意義是十分深遠的。隨著時間的推移，軟件開發(fā)組織既可能重用它在某個問題域內(nèi)的OOA結(jié)果，也可能重用相應的OOD和OOP結(jié)果。第六頁，共五十八頁，編輯于2023年，星期五3.可維護性盡管人們反復強調(diào)保持文檔與源程序一致的必要性，但是，在實際工作中很難做到交付兩類不同的文檔，并使它們保持彼此完全一致。特別是考慮到進度、預算、能力和人員等限制因素時，做到兩類文檔完全一致幾乎是不可能的。因此，維護人員最終面對的往往只有源程序本身。第七頁，共五十八頁，編輯于2023年，星期五兩大類面向?qū)ο笳Z言。一類是純面向?qū)ο笳Z言，如Smalltalk和Eiffel等語言。另一類是混合型面向?qū)ο笳Z言，也就是在過程語言的基礎(chǔ)上增加面向?qū)ο髾C制，如C++等語言。一般說來，純面向?qū)ο笳Z言著重支持面向?qū)ο蠓椒ㄑ芯亢涂焖僭偷膶崿F(xiàn)，而混合型面向?qū)ο笳Z言的目標則是提高運行速度和使傳統(tǒng)程序員容易接受面向?qū)ο笏枷?。成熟的面向?qū)ο笳Z言通常都提供豐富的類庫和強有力的開發(fā)環(huán)境。12.1.2面向?qū)ο笳Z言的技術(shù)特點第八頁，共五十八頁，編輯于2023年，星期五1.支持類與對象概念的機制所有面向?qū)ο笳Z言都允許用戶動態(tài)創(chuàng)建對象，并且可以用指針引用動態(tài)創(chuàng)建的對象。允許動態(tài)創(chuàng)建對象，就意味著系統(tǒng)必須處理內(nèi)存管理問題(釋放內(nèi)存)有兩種管理內(nèi)存的方法，一種是由語言的運行機制自動管理內(nèi)存，即提供自動回收“垃圾”的機制；另一種是由程序員編寫釋放內(nèi)存的代碼。第九頁，共五十八頁，編輯于2023年，星期五2.實現(xiàn)整體-部分(即聚集)結(jié)構(gòu)的機制一般說來，有兩種實現(xiàn)方法，分別使用指針和獨立的關(guān)聯(lián)對象實現(xiàn)整體-部分結(jié)構(gòu)。大多數(shù)現(xiàn)有的面向?qū)ο笳Z言并不顯式支持獨立的關(guān)聯(lián)對象，在這種情況下，使用指針是最容易的實現(xiàn)方法，通過增加內(nèi)部指針可以方便地實現(xiàn)關(guān)聯(lián)。第十頁，共五十八頁，編輯于2023年，星期五3.實現(xiàn)一般-特殊(即泛化)結(jié)構(gòu)的機制既包括實現(xiàn)繼承的機制也包括解決名字沖突的機制。所謂解決名字沖突，指的是處理在多個基類中可能出現(xiàn)的重名問題，這個問題僅在支持多重繼承的語言中才會遇到。某些語言拒絕接受有名字沖突的程序，另一些語言提供了解決沖突的協(xié)議。不論使用何種語言，程序員都應該盡力避免出現(xiàn)名字沖突。第十一頁，共五十八頁，編輯于2023年，星期五4.實現(xiàn)屬性和服務(wù)的機制對于實現(xiàn)屬性的機制應該著重考慮以下幾個方面：支持實例連接的機制；屬性的可見性控制；對屬性值的約束。對于服務(wù)來說，主要應該考慮下列因素：支持消息連接(即表達對象交互關(guān)系)的機制；控制服務(wù)可見性的機制；動態(tài)聯(lián)編。所謂動態(tài)聯(lián)編，是指應用系統(tǒng)在運行過程中，當需要執(zhí)行一個特定服務(wù)的時候，選擇(或聯(lián)編)實現(xiàn)該服務(wù)的適當算法的能力。動態(tài)聯(lián)編機制使得程序員在向?qū)ο蟀l(fā)送消息時擁有較大自由，在發(fā)送消息前，無須知道接受消息的對象當時屬于哪個類。第十二頁，共五十八頁，編輯于2023年，星期五5.類型檢查程序設(shè)計語言可以按照編譯時進行類型檢查的嚴格程度來分類。如果語言僅要求每個變量或?qū)傩噪`屬于一個對象，則是弱類型的；如果語法規(guī)定每個變量或?qū)傩员仨殰蚀_地屬于某個特定的類，則這樣的語言是強類型的。面向?qū)ο笳Z言在這方面差異很大，例如，Smalltalk實際上是一種無類型語言(所有變量都是未指定類的對象)；C++和Eiffel則是強類型語言?；旌闲驼Z言(如C++,Objective_C等)甚至允許屬性值不是對象而是某種預定義的基本類型數(shù)據(jù)(如整數(shù)，浮點數(shù)等)，這可以提高操作的效率。第十三頁，共五十八頁，編輯于2023年，星期五強類型語言主要有兩個優(yōu)點：一是有利于在編譯時發(fā)現(xiàn)程序錯誤，二是增加了優(yōu)化的可能性。通常使用強類型編譯型語言開發(fā)軟件產(chǎn)品，使用弱類型解釋型語言快速開發(fā)原型?？偟恼f來，強類型語言有助于提高軟件的可靠性和運行效率，現(xiàn)代的程序語言理論支持強類型檢查，大多數(shù)新語言都是強類型的。6.類庫大多數(shù)面向?qū)ο笳Z言都提供一個實用的類庫。某些語言本身并沒有規(guī)定提供什么樣的類庫，而是由實現(xiàn)這種語言的編譯系統(tǒng)自行提供類庫。存在類庫，許多軟構(gòu)件就不必由程序員重頭編寫了，這為實現(xiàn)軟件重用帶來很大方便。第十四頁，共五十八頁，編輯于2023年，星期五類庫中往往包含實現(xiàn)通用數(shù)據(jù)結(jié)構(gòu)(例如，動態(tài)數(shù)組、表、隊列、棧、樹等等)的類，通常把這些類稱為包容類。在類庫中還可以找到實現(xiàn)各種關(guān)聯(lián)的類。更完整的類庫通常還提供獨立于具體設(shè)備的接口類(例如，輸入輸出流)，此外，用于實現(xiàn)窗口系統(tǒng)的用戶界面類也非常有用，它們構(gòu)成一個相對獨立的圖形庫。第十五頁，共五十八頁，編輯于2023年，星期五7.效率許多人認為面向?qū)ο笳Z言的主要缺點是效率低。產(chǎn)生這種印象的一個原因是，某些早期的面向?qū)ο笳Z言是解釋型的而不是編譯型的。事實上，使用擁有完整類庫的面向?qū)ο笳Z言，有時能比使用非面向?qū)ο笳Z言得到運行更快的代碼。這是因為類庫中提供了更高效的算法和更好的數(shù)據(jù)結(jié)構(gòu)，例如，程序員已經(jīng)無須編寫實現(xiàn)哈希表或平衡樹算法的代碼了，類庫中已經(jīng)提供了這類數(shù)據(jù)結(jié)構(gòu)，而且算法先進、代碼精巧可靠。第十六頁，共五十八頁，編輯于2023年，星期五認為面向?qū)ο笳Z言效率低的另一個理由是，這種語言在運行時使用動態(tài)聯(lián)編實現(xiàn)多態(tài)性，這似乎需要在運行時查找繼承樹，以得到定義給定操作的類。事實上，絕大多數(shù)面向?qū)ο笳Z言都優(yōu)化了這個查找過程，從而實現(xiàn)了高效率查找。只要在程序運行時始終保持類結(jié)構(gòu)不變，就能在子類中存儲各個操作的正確入口點，從而使得動態(tài)聯(lián)編成為查找哈希表的高效過程，不會由于繼承樹深度加大或類中定義的操作數(shù)增加而降低效率。第十七頁，共五十八頁，編輯于2023年，星期五8.持久保存對象任何應用程序都對數(shù)據(jù)進行處理，如果希望數(shù)據(jù)能夠不依賴于程序執(zhí)行的生命期而長時間保存下來，則需要提供某種保存數(shù)據(jù)的方法。希望長期保存數(shù)據(jù)主要出于以下兩個原因：(1)為實現(xiàn)在不同程序之間傳遞數(shù)據(jù)，需要保存數(shù)據(jù)；(2)為恢復被中斷了的程序的運行，首先需要保存數(shù)據(jù)。一些面向?qū)ο笳Z言，沒有提供直接存儲對象的機制。這些語言的用戶必須自己管理對象的輸入輸出，或者購買面向?qū)ο蟮臄?shù)據(jù)庫管理系統(tǒng)。第十八頁，共五十八頁，編輯于2023年，星期五另外一些面向?qū)ο笳Z言(例如，Smalltalk)，把當前的執(zhí)行狀態(tài)完整地保存在磁盤上。還有一些面向?qū)ο笳Z言，提供了訪問磁盤對象的輸入輸出操作。通過在類庫中增加對象存儲管理功能，可以在不改變語言定義或不增加關(guān)鍵字的情況下，就在開發(fā)環(huán)境中提供這種功能。然后，可以從“可存儲的類”中派生出需要持久保存的對象，該對象自然繼承了對象存儲管理功能。這就是Eiffel語言采用的策略。理想情況下，應該使程序設(shè)計語言語法與對象存儲管理語法實現(xiàn)無縫集成。第十九頁，共五十八頁，編輯于2023年，星期五9.參數(shù)化類在實際的應用程序中，常?？吹竭@樣一些軟件元素(即函數(shù)、類等軟件成分)，從它們的邏輯功能看，彼此是相同的，所不同的主要是處理的對象(數(shù)據(jù))類型不同。例如，對于一個向量(一維數(shù)組)類來說，不論是整型向量，浮點型向量，還是其他任何類型的向量，針對它的數(shù)據(jù)元素所進行的基本操作都是相同的(例如，插入、刪除、檢索等)，當然，不同向量的數(shù)據(jù)元素的類型是不同的。如果程序語言提供一種能抽象出這類共性的機制，則對減少冗余和提高可重用性是大有好處的。第二十頁，共五十八頁，編輯于2023年，星期五所謂參數(shù)化類，就是使用一個或多個類型去參數(shù)化一個類的機制，有了這種機制，程序員就可以先定義一個參數(shù)化的類模板(即在類定義中包含以參數(shù)形式出現(xiàn)的一個或多個類型)，然后把數(shù)據(jù)類型作為參數(shù)傳遞進來，從而把這個類模板應用在不同的應用程序中，或用在同一應用程序的不同部分。Eiffel語言中就有參數(shù)化類，C++語言也提供了類模板。第二十一頁，共五十八頁，編輯于2023年，星期五10.開發(fā)環(huán)境軟件工具和軟件工程環(huán)境對軟件生產(chǎn)率有很大影響。由于面向?qū)ο蟪绦蛑欣^承關(guān)系和動態(tài)聯(lián)編等引入的特殊復雜性，面向?qū)ο笳Z言所提供的軟件工具或開發(fā)環(huán)境就顯得尤其重要了。至少應該包括下列一些最基本的軟件工具：編輯程序，編譯程序或解釋程序，瀏覽工具，調(diào)試器(debugger)等。第二十二頁，共五十八頁，編輯于2023年，星期五編譯程序或解釋程序是最基本、最重要的軟件工具。編譯與解釋的差別主要是速度和效率不同。利用解釋程序解釋執(zhí)行用戶的源程序，雖然速度慢、效率低，但卻可以更方便更靈活地進行調(diào)試。編譯型語言適于用來開發(fā)正式的軟件產(chǎn)品，優(yōu)化工作做得好的編譯程序能生成效率很高的目標代碼。有些面向?qū)ο笳Z言(例如Objective_C)除提供編譯程序外，還提供一個解釋工具，從而給用戶帶來很大方便。第二十三頁，共五十八頁，編輯于2023年，星期五某些面向?qū)ο笳Z言的編譯程序，先把用戶源程序翻譯成一種中間語言程序，然后再把中間語言程序翻譯成目標代碼。這樣做可能會使得調(diào)試器不能理解原始的源程序。在評價調(diào)試器時，首先應該弄清楚它是針對原始的面向?qū)ο笤闯绦颍€是針對中間代碼進行調(diào)試。如果是針對中間代碼進行調(diào)試，則會給調(diào)試人員帶來許多不便。此外，面向?qū)ο蟮恼{(diào)試器，應該能夠查看屬性值和分析消息連接的后果。第二十四頁，共五十八頁，編輯于2023年，星期五在開發(fā)大型系統(tǒng)的時候，需要有系統(tǒng)構(gòu)造工具和變動控制工具。因此應該考慮語言本身是否提供了這種工具，或者該語言能否與現(xiàn)有的這類工具很好地集成起來。經(jīng)驗表明，傳統(tǒng)的系統(tǒng)構(gòu)造工具(例如，UNIX的Make)目前對許多應用系統(tǒng)來說都已經(jīng)太原始了。第二十五頁，共五十八頁，編輯于2023年，星期五開發(fā)人員在選擇面向?qū)ο笳Z言時，還應該著重考慮以下一些實際因素。1.將來能否占主導地位在若干年以后，哪種面向?qū)ο蟮某绦蛟O(shè)計語言將占主導地位呢?為了使自己的產(chǎn)品在若干年后仍然具有很強的生命力，人們可能希望采用將來占主導地位的語言編程。12.1.3選擇面向?qū)ο笳Z言第二十六頁，共五十八頁，編輯于2023年，星期五根據(jù)目前占有的市場份額，以及專業(yè)書刊和學術(shù)會議上所做的分析、評價，人們往往能夠?qū)ξ磥砟姆N面向?qū)ο笳Z言將占據(jù)主導地位做出預測。但是，最終決定選用哪種面向?qū)ο笳Z言的實際因素，往往是諸如成本之類的經(jīng)濟因素而不是技術(shù)因素。2.可重用性采用面向?qū)ο蠓椒ㄩ_發(fā)軟件的基本目的和主要優(yōu)點，是通過重用提高軟件生產(chǎn)率。因此，應該優(yōu)先選用能夠最完整、最準確地表達問題域語義的面向?qū)ο笳Z言。第二十七頁，共五十八頁，編輯于2023年，星期五3.類庫和開發(fā)環(huán)境決定可重用性的因素，不僅僅是面向?qū)ο蟪绦蛘Z言本身，開發(fā)環(huán)境和類庫也是非常重要的因素。事實上，語言、開發(fā)環(huán)境和類庫這3個因素綜合起來，共同決定了可重用性?？紤]類庫的時候，不僅應該考慮是否提供了類庫，還應該考慮類庫中提供了哪些有價值的類。隨著類庫的日益成熟和豐富，在開發(fā)新應用系統(tǒng)時，需要開發(fā)人員自己編寫的代碼將越來越少。第二十八頁，共五十八頁，編輯于2023年，星期五為便于積累可重用的類和重用已有的類，在開發(fā)環(huán)境中，除了提供前述的基本軟件工具外，還應該提供使用方便的類庫編輯工具和瀏覽工具。其中的類庫瀏覽工具應該具有強大的聯(lián)想功能。4.其他因素在選擇編程語言時，應該考慮的其他因素還有：對用戶學習面向?qū)ο蠓治?、設(shè)計和編碼技術(shù)所能提供的培訓服務(wù)；在使用這個面向?qū)ο笳Z言期間能提供的技術(shù)支持；能提供給開發(fā)人員使用的開發(fā)工具、開發(fā)平臺、發(fā)行平臺；對機器性能和內(nèi)存的需求；集成已有軟件的容易程度等。第二十九頁，共五十八頁，編輯于2023年，星期五第7章已經(jīng)強調(diào)指出，良好的程序設(shè)計風格對保證程序質(zhì)量的重要性。良好的程序設(shè)計風格對面向?qū)ο髮崿F(xiàn)來說尤其重要，不僅能明顯減少維護或擴充的開銷，而且有助于在新項目中重用已有的程序代碼。良好的面向?qū)ο蟪绦蛟O(shè)計風格，既包括傳統(tǒng)的程序設(shè)計風格準則，也包括為適應面向?qū)ο蠓椒ㄋ赜械母拍?例如，繼承性)而必須遵循的一些新準則。12.2程序設(shè)計風格第三十頁，共五十八頁，編輯于2023年，星期五面向?qū)ο蠓椒ǖ囊粋€主要目標，就是提高軟件的可重用性。軟件重用有多個層次，在編碼階段主要涉及代碼重用問題。一般說來，代碼重用有兩種：一種是本項目內(nèi)的代碼重用，另一種是新項目重用舊項目的代碼。內(nèi)部重用主要是找出設(shè)計中相同或相似的部分，然后利用繼承機制共享它們。為做到外部重用，則必須有長遠眼光，需要反復考慮精心設(shè)計。雖然為實現(xiàn)外部重用而需要考慮的面，比為實現(xiàn)內(nèi)部重用而需要考慮的面更廣，但是，有助于實現(xiàn)這兩類重用的程序設(shè)計準則卻是相同的。下面講述主要的準則：12.2.1提高可重用性第三十一頁，共五十八頁，編輯于2023年，星期五1.提高方法的內(nèi)聚一個方法(即服務(wù))應該只完成單個功能。如果某個方法涉及兩個或多個不相關(guān)的功能，則應該把它分解成幾個更小的方法。2.減小方法的規(guī)模應該減小方法的規(guī)模，如果某個方法規(guī)模過大(代碼長度超過一頁紙可能就太大了)，則應該把它分解成幾個更小的方法。第三十二頁，共五十八頁，編輯于2023年，星期五3.保持方法的一致性保持方法的一致性，有助于實現(xiàn)代碼重用。一般說來，功能相似的方法應該有一致的名字、參數(shù)特征(包括參數(shù)個數(shù)、類型和次序)、返回值類型、使用條件及出錯條件等。4.把策略與實現(xiàn)分開從所完成的功能看，有兩種不同類型的方法。一類方法負責做出決策，提供變元，并且管理全局資源，可稱為策略方法。另一類方法負責完成具體的操作，但卻并不做出是否執(zhí)行這個操作的決定，也不知道為什么執(zhí)行這個操作，可稱為實現(xiàn)方法。第三十三頁，共五十八頁，編輯于2023年，星期五策略方法應該檢查系統(tǒng)運行狀態(tài)，并處理出錯情況，它們并不直接完成計算或?qū)崿F(xiàn)復雜的算法。策略方法通常緊密依賴于具體應用，這類方法比較容易編寫，也比較容易理解。實現(xiàn)方法僅僅針對具體數(shù)據(jù)完成特定處理，通常用于實現(xiàn)復雜的算法。實現(xiàn)方法并不制定決策，也不管理全局資源，如果在執(zhí)行過程中發(fā)現(xiàn)錯誤，它們應該只返回執(zhí)行狀態(tài)而不對錯誤采取行動。由于實現(xiàn)方法是自含式算法，相對獨立于具體應用，因此，在其他應用系統(tǒng)中也可能重用它們。第三十四頁，共五十八頁，編輯于2023年，星期五為提高可重用性，在編程時不要把策略和實現(xiàn)放在同一個方法中，應該把算法的核心部分放在一個單獨的具體實現(xiàn)方法中。為此需要從策略方法中提取出具體參數(shù)，作為調(diào)用實現(xiàn)方法的變元。5.全面覆蓋如果輸入條件的各種組合都可能出現(xiàn)，則應該針對所有組合寫出方法，而不能僅僅針對當前用到的組合情況寫方法。例如，如果在當前應用中需要寫一個方法，以獲取表中第一個元素，則至少還應該為獲取表中最后一個元素再寫一個方法。第三十五頁，共五十八頁，編輯于2023年，星期五此外，一個方法不應該只能處理正常值，對空值、極限值及界外值等異常情況也應該能夠作出有意義的響應。6.盡量不使用全局信息應該盡量降低方法與外界的耦合程度，不使用全局信息是降低耦合度的一項主要措施。第三十六頁，共五十八頁，編輯于2023年，星期五7.利用繼承機制在面向?qū)ο蟪绦蛑校褂美^承機制是實現(xiàn)共享和提高重用程度的主要途徑。(1)調(diào)用子過程。最簡單的做法是把公共的代碼分離出來，構(gòu)成一個被其他方法調(diào)用的公用方法?？梢栽诨愔卸x這個公用方法，供派生類中的方法調(diào)用，如圖12.1所示。第三十七頁，共五十八頁，編輯于2023年，星期五圖12.1通過調(diào)用公用方法實現(xiàn)代碼重用第三十八頁，共五十八頁，編輯于2023年，星期五(2)分解因子。有時提高相似類代碼可重用性的一個有效途徑，是從不同類的相似方法中分解出不同的“因子”(即不同的代碼)，把余下的代碼作為公用方法中的公共代碼，把分解出的因子作為名字相同算法不同的方法，放在不同類中定義，并被這個公用方法調(diào)用，如圖12.2所示。使用這種途徑通常額外定義一個抽象基類，并在這個抽象基類中定義公用方法。把這種途徑與面向?qū)ο笳Z言提供的多態(tài)性機制結(jié)合起來，讓派生類繼承抽象基類中定義的公用方法，可以明顯降低為增添新子類而需付出的工作量，因為只需在新子類中編寫其特有的代碼。第三十九頁，共五十八頁，編輯于2023年，星期五圖12.2通過因子分解實現(xiàn)代碼重用第四十頁，共五十八頁，編輯于2023年，星期五(3)使用委托。繼承關(guān)系的存在意味著子類“即是”父類，因此，父類的所有方法和屬性應該都適用于子類。僅當確實存在一般-特殊關(guān)系時，使用繼承才是恰當?shù)摹＠^承機制使用不當將造成程序難于理解、修改和擴充。當邏輯上不存在一般-特殊關(guān)系時，為重用已有的代碼，可以利用委托機制，如本書11.11.3小節(jié)所述。第四十一頁，共五十八頁，編輯于2023年，星期五(4)把代碼封裝在類中。程序員往往希望重用用其他方法編寫的、解決同一類應用問題的程序代碼。重用這類代碼的一個比較安全的途徑，是把被重用的代碼封裝在類中。例如，在開發(fā)一個數(shù)學分析應用系統(tǒng)的過程中，已知有現(xiàn)成的實現(xiàn)矩陣變換的商品軟件包，程序員不想用C++語言重寫這個算法，于是他定義一個矩陣類把這個商品軟件包的功能封裝在該類中。第四十二頁，共五十八頁，編輯于2023年，星期五上一小節(jié)所述的提高可重用性的準則，也能提高程序的可擴充性。此外，下列的面向?qū)ο蟪绦蛟O(shè)計準則也有助于提高可擴充性：1.封裝實現(xiàn)策略應該把類的實現(xiàn)策略(包括描述屬性的數(shù)據(jù)結(jié)構(gòu)、修改屬性的算法等)封裝起來，對外只提供公有的接口，否則將降低今后修改數(shù)據(jù)結(jié)構(gòu)或算法的自由度。12.2.2提高可擴充性第四十三頁，共五十八頁，編輯于2023年，星期五2.不要用一個方法遍歷多條關(guān)聯(lián)鏈一個方法應該只包含對象模型中的有限內(nèi)容。違反這條準則將導致方法過分復雜，既不易理解，也不易修改擴充。3.避免使用多分支語句一般說來，可以利用DO_CASE語句測試對象的內(nèi)部狀態(tài)，而不要用來根據(jù)對象類型選擇應有的行為，否則在增添新類時將不得不修改原有的代碼。應該合理地利用多態(tài)性機制，根據(jù)對象當前類型，自動決定應有的行為。第四十四頁，共五十八頁，編輯于2023年，星期五4.精心確定公有方法公有方法是向公眾公布的接口。對這類方法的修改往往會涉及許多其他類，因此，修改公有方法的代價通常都比較高。為提高可修改性，降低維護成本，必須精心選擇和定義公有方法。私有方法是僅在類內(nèi)使用的方法，通常利用私有方法來實現(xiàn)公有方法。刪除、增加或修改私有方法所涉及的面要窄得多，因此代價也比較低。第四十五頁，共五十八頁，編輯于2023年，星期五程序員在編寫實現(xiàn)方法的代碼時，既應該考慮效率，也應該考慮健壯性。通常需要在健壯性與效率之間做出適當?shù)恼壑?。必須認識到，對于任何一個實用軟件來說，健壯性都是不可忽略的質(zhì)量指標。為提高健壯性應該遵守以下幾條準則。12.2.3提高健壯性第四十六頁，共五十八頁，編輯于2023年，星期五1.預防用戶的操作錯誤軟件系統(tǒng)必須具有處理用戶操作錯誤的能力。當用戶在輸入數(shù)據(jù)時發(fā)生錯誤，不應該引起程序運行中斷，更不應該造成“死機”。任何一個接收用戶輸入數(shù)據(jù)的方法，對其接收到的數(shù)據(jù)都必須進行檢查，即使發(fā)現(xiàn)了非常嚴重的錯誤，也應該給出恰當?shù)奶崾拘畔ⅲ蕚湓俅谓邮沼脩舻妮斎?。第四十七頁，共五十八頁，編輯?023年，星期五2.檢查參數(shù)的合法性對公有方法，尤其應該著重檢查其參數(shù)的合法性，因為用戶在使用公有方法時可能違反參數(shù)的約束條件。3.不要預先確定限制條件在設(shè)計階段，往往很難準確地預測出應用系統(tǒng)中使用的數(shù)據(jù)結(jié)構(gòu)的最大容量需求。因此不應該預先設(shè)定限制條件。如果有必要和可能，則應該使用動態(tài)內(nèi)存分配機制，創(chuàng)建未預先設(shè)定限制條件的數(shù)據(jù)結(jié)構(gòu)。第四十八頁，共五十八頁，編輯于2023年，星期五4.先測試后優(yōu)化為在效率與健壯性之間做出合理的折衷，應該在為提高效率而進行優(yōu)化之前，先測試程序的性能，人們常常驚奇地發(fā)現(xiàn)，事實上大部分程序代碼所消耗的運行時間并不多。應該仔細研究應用程序的特點，以確定哪些部分需要著重測試(例如，最壞情況出現(xiàn)的次數(shù)及處理時間，可能需要著重測試)。經(jīng)過測試，合理地確定為提高性能應該著重優(yōu)化的關(guān)鍵部分。如果實現(xiàn)某個操作的算法有許多種，則應該綜合考慮內(nèi)存需求、速度及實現(xiàn)的簡易程度等因素，經(jīng)合理折衷選定適當?shù)乃惴?。第四十九頁，共五十八頁，編輯?023年，星期五測試軟件的經(jīng)典策略是，從“小型測試”開始，逐步過渡到“大型測試”。用軟件測試的專業(yè)術(shù)語描述，就是從單元測試開始，逐步進入集成測試，最后進行確認測試和系統(tǒng)測試。對于傳統(tǒng)的軟件系統(tǒng)來說，單元測試集中測試最小的可編譯的程序單元（過程模塊），一旦把這些單元都測試完之后，就把它們集成到程序結(jié)構(gòu)中去；在集成過程中還應該進行一系列的回歸測試，以發(fā)現(xiàn)模塊接口錯誤和新單元加入到程序中所帶來的副作用；最后，把軟件系統(tǒng)作為一個整體來測試，以發(fā)現(xiàn)軟件需求錯誤。測試面向?qū)ο筌浖牟呗耘c上述策略基本相同，但也有許多新特點。12.3測試策略第五十頁，共五十八頁，編輯于2023年，星期五當考慮面向?qū)ο蟮能浖r，單元的概念改變了?！胺庋b”導致了類和對象的定義，這意味著類和類的實例（對象）包裝了屬性（數(shù)據(jù)）和處理這些數(shù)據(jù)的操作（也稱為方法或服務(wù)）?，F(xiàn)在，最小的可測試單元是封裝起來的類和對象。一個類可以包含一組不同的操作，而一個特定的操作也可能存在于一組不同的類中。因此，對于面向?qū)ο蟮能浖碚f，單元測試的含義發(fā)生了很大變化。12.3.1面向?qū)ο蟮膯卧獪y試第五十一頁，共五十八頁，編輯于2023年，星期五測試面向?qū)ο筌浖r，不能再孤立地測試單個操作，而應該把操作作為類的一部分來測試。例如，假設(shè)有一個類層次，操作X在超類中定義并被一組子類繼承，每個子類都使用操作X，但是，X調(diào)用子類中定義的操作并處理子類的私有屬性。由于在不同的子類中使用操作X的環(huán)境有微妙的差別，因此有必要在每個子類的語境中測試操作X。這就說明，當測試面向?qū)ο筌浖r，傳統(tǒng)的單元測試方法是不適用的，不能再在“真空”中（即孤立地）測試單個操作。第五十二頁，共五十八頁，編輯