編程思想think本書作者根據(jù)自己學(xué)習(xí)的親身體會(huì)及多年教學(xué)經(jīng)驗(yàn)用單例子和

本書作者根據(jù)自己學(xué)習(xí)C++的親身體會(huì)及多年教學(xué)經(jīng)驗(yàn)，用簡(jiǎn)單的例子和簡(jiǎn)練的敘述講解C++編程，別具特色。全書共分十八章，內(nèi)容涉及對(duì)象的演化、數(shù)據(jù)抽象、隱藏實(shí)現(xiàn)、初始異常處理和運(yùn)行時(shí)類型識(shí)別。本書作為正式和均非常優(yōu)秀，作為程序設(shè)計(jì)者的 目錄11111 第3 隱藏實(shí) 為什么C++會(huì)成 C++ 較好的 4444類555 句柄類（handle 5679 第4 初始化與清 方法應(yīng)當(dāng)提供什 起草：最小的方 前 責(zé)任驅(qū)動(dòng)的設(shè)計(jì)對(duì)象建模技術(shù)為向OOP5 范圍分 管理 用返回值重 安全類型連 2C什么是6 內(nèi)聯(lián)函數(shù)和編譯 減少 為用戶分配的 自動(dòng)分 輸出流格式 第9 命名控 格式化算 建立算 輸入輸出流實(shí) 其他的類型指定 代碼生 C++第7 常 值替 頭文件里的 與C 指 指向const 第10 C++C++中的函數(shù)中的constconst 拷貝構(gòu)造函 傳遞和返回地 const和 const 只讀能 可變的 小 練 8第1 然而計(jì)算機(jī)并不僅僅是一臺(tái)機(jī)器，它是心智放大器和另一種有表述能力的。這一點(diǎn)使它不很像機(jī)器，而更像我們大腦的一部分，更像其他有表述能力的，例如寫作、繪畫、雕刻、動(dòng)畫制作或制作。面向?qū)ο蟮某绦蛟O(shè)計(jì)是計(jì)算機(jī)向有表述能力的發(fā)展中的一部分。本章將介紹面向?qū)ο蟪绦蛟O(shè)計(jì)（OOP）的基本概念，然后討論OOP開發(fā)方法，最后介紹使2章，然后再C++包含了比面向?qū)ο蟪绦蛟O(shè)計(jì)基本概念的內(nèi)容，讀者應(yīng)當(dāng)在學(xué)習(xí)設(shè)計(jì)和開發(fā)程序之對(duì)象：特性+行為第一個(gè)面向?qū)ο蟮某绦蛟O(shè)計(jì)語(yǔ)言是60年發(fā)的Simula-67。其目的是為了解決模擬問(wèn)題。類描述了一組有相同特性（數(shù)據(jù)元素）和相為（函數(shù)）的對(duì)象。類實(shí)際上就是數(shù)據(jù)類型，例如，浮點(diǎn)數(shù)也有一組特性和行為。區(qū)別在于程序員定義類是為了與具體問(wèn)題相適應(yīng)，而不是被迫使用已存在的數(shù)據(jù)類型。這些已存在的數(shù)據(jù)類型的設(shè)計(jì)動(dòng)機(jī)僅僅是為了描述機(jī)器的存儲(chǔ)單元。程序員可以通過(guò)增添他所需要的新數(shù)據(jù)類型來(lái)擴(kuò)展這個(gè)程序設(shè)計(jì)語(yǔ)言。該程序設(shè)計(jì)系統(tǒng)歡迎創(chuàng)建、關(guān)注新的類，對(duì)它們進(jìn)行與內(nèi)部類型一樣的類型檢查。這種方法并不限于去模擬具體問(wèn)題。盡管不是所有的人都同意，但大部分人相信，任何程序都模擬所設(shè)計(jì)系統(tǒng)。OOP技術(shù)能很容易地將大量問(wèn)題歸納成為一個(gè)簡(jiǎn)單的解，這一發(fā)現(xiàn)產(chǎn)生了大量的OO語(yǔ)言，其中最著名的是Smalltalk—C之前最成功的OOP語(yǔ)言。的特性和行為，但是，一個(gè)類型可能包括比另一個(gè)類型的特性，也可以處理的消[1]這一描述部分引自我對(duì)《TheTaoofObjects（GaryEntsminger著）一書的介紹（或?qū)ο⑦M(jìn)行不同的處理。繼承表示了基本類型和派生類型之間的相似性。一個(gè)基本類型具有所有由它派生出來(lái)的類型所共有的特性和行為。程序員創(chuàng)建一個(gè)基本類型以描述系統(tǒng)中一些對(duì)象的思想。由這個(gè)基本類型派生出其他類型，表達(dá)了認(rèn)識(shí)該的不同途徑。例如，再生機(jī)要對(duì)進(jìn)行分類。這里基本類型是“”，每件有重量、價(jià)值等等，并且可以被破碎、融化或分解。這樣，可以派生出更特殊的類型，它們可以有另外的特性（瓶子有顏色）或行為（鋁可以被壓碎，鋼可以被磁化（紙的價(jià)值取決于它的種類和狀態(tài)。程序員可以用繼承建立類的層次結(jié)構(gòu)，在該層次結(jié)構(gòu)中用類型術(shù)語(yǔ)來(lái)表述他需要解決的問(wèn)題。第二個(gè)例子是經(jīng)典的形體問(wèn)題，可以用于計(jì)算機(jī)輔助設(shè)計(jì)系統(tǒng)或游戲模擬中。這里基本類是”形小、。體制、由此，可以派生出特殊類型的形體：圓、正方形、三角形等，它們中的每一個(gè)都有另外的特性和行為，例如，某些形體可以翻轉(zhuǎn)。有些行為可以不同（計(jì)算形體的面積。類型層次結(jié)構(gòu)既體現(xiàn)了形體間的類似，又體現(xiàn)了它們之間的區(qū)別。用與問(wèn)題相同的術(shù)語(yǔ)描述問(wèn)題的解是非常有益的，這樣，從問(wèn)題描述到解的描述之間就不需要很多中間模型（程序語(yǔ)言解決大型問(wèn)題，就需要中間模型。面向?qū)ο笾暗恼Z(yǔ)言，描述問(wèn)題的解不可避免地要用計(jì)算機(jī)術(shù)語(yǔ)。使用對(duì)象術(shù)語(yǔ)，類型層次結(jié)構(gòu)是主要模型，所以可以從現(xiàn)實(shí)世界中的系統(tǒng)描述直接進(jìn)入代碼中的系統(tǒng)描述。實(shí)際上，使用面向?qū)ο笤O(shè)計(jì)，人們的之一是從開始到結(jié)束過(guò)于簡(jiǎn)單。一個(gè)已經(jīng)習(xí)慣于尋找復(fù)雜解的、訓(xùn)練有素的頭腦，往往會(huì)被問(wèn)題的簡(jiǎn)單性難住。多態(tài)當(dāng)處理類型層次結(jié)構(gòu)時(shí)，程序員常常希望不把對(duì)象看作是某一特殊類型的成員，而把它看作基本類型成員，這樣就可以編寫不依賴于特殊類型的代碼。在形體例子中，函數(shù)可以對(duì)一般所以這些函數(shù)能簡(jiǎn)單地發(fā)送消息給一個(gè)形體對(duì)象，而不考慮這個(gè)對(duì)象如何處理這個(gè)消息。例如，可以派生出形體的一個(gè)新的子類，稱為五邊形，而不必修改那些處理一般形體的函數(shù)。通過(guò)派生新子類，很容易擴(kuò)展程序，這個(gè)能力很重要，因?yàn)樗鼧O大地減少了軟件的花費(fèi)。在面向?qū)ο蟮某绦蛟O(shè)計(jì)中，答案是巧妙的。編譯器并不做傳統(tǒng)意義上的函數(shù)調(diào)用。由非OOP編譯器產(chǎn)生的函數(shù)調(diào)用會(huì)引起與被調(diào)用碼的“”，對(duì)于這一術(shù)語(yǔ)讀者可能還聽，因?yàn)閺膩?lái)沒(méi)有想到過(guò)它。早意味著編譯器對(duì)特定的函數(shù)名產(chǎn)生調(diào)用，而連接器確OOP，在程序運(yùn)行之前，編譯器不確定執(zhí)行代碼的地址，所以，當(dāng)消息發(fā)送給一般對(duì)象時(shí)，需要采用其他的方案。運(yùn)行之前不去確定被調(diào)用的代碼。編譯器保證這個(gè)被調(diào)用的函數(shù)存在，并完成參數(shù)和返回值的類型檢查，但是它不知道將執(zhí)行的準(zhǔn)確代碼。為了實(shí)現(xiàn)晚，編譯器在真正調(diào)用的地方插入一段特殊的二進(jìn)制代碼。通過(guò)使用存放在（14紹。這樣，每個(gè)對(duì)象就能根據(jù)一個(gè)指針的內(nèi)容有不同的行為。當(dāng)一個(gè)對(duì)象接收到消息時(shí)，它根據(jù)這個(gè)消息判斷應(yīng)當(dāng)做什么。程序員可以用關(guān)鍵字virtual表明他希望某個(gè)函數(shù)有晚的靈活性，而并不需要懂得操作概念：OOP程序像我們已經(jīng)知道，用C語(yǔ)言編寫的過(guò)程程序就是一些數(shù)據(jù)定義和函數(shù)調(diào)用。要理解這種程序的含義，程序員必須掌握函數(shù)調(diào)用和函數(shù)實(shí)現(xiàn)的本身。這就是過(guò)程程序需要中間表示的原因。中間表示容易引起，因?yàn)橹虚g表示的表述是原始的，更偏向于計(jì)算機(jī)，而不偏向于所解決的問(wèn)題。C++向CC++main()會(huì)C程序更復(fù)雜。但令人吃驚的是，一個(gè)寫得很好的C++C程序更簡(jiǎn)單和容易理解。程序員只會(huì)看到一些描述問(wèn)題空間對(duì)象的定義（而不是計(jì)算機(jī)的描述，發(fā)送給這些對(duì)象的消息。這些消息表示了在這個(gè)空間的活動(dòng)。面向?qū)ο蟪绦蛟O(shè)計(jì)的優(yōu)點(diǎn)之一是通過(guò)閱讀，很容易理解代碼。通常，面向?qū)ο蟪绦蛐枰^少的代碼，因?yàn)閱?wèn)題中的許多為什么C++會(huì)成C++C語(yǔ)言轉(zhuǎn)變成OOP語(yǔ)言（雖然這是最初的目的，而且還為了解決程序員，特是些在C語(yǔ)言中已經(jīng)大量投資的程序員所的許多問(wèn)題。人們已經(jīng)對(duì)OOP語(yǔ)言有了這樣傳統(tǒng)的看法：程序員應(yīng)當(dāng)拋棄所知道的每件事情并且從一組新概念和新文法重新開始，他應(yīng)當(dāng)相信，最好丟掉所有來(lái)自過(guò)程語(yǔ)言的老行裝。從長(zhǎng)遠(yuǎn)角度看，這是對(duì)的。但從短期角度看，這些行裝還是有價(jià)值的。最有價(jià)值的可能不是那些已存在的代碼庫(kù)（給出合適的工具，可以轉(zhuǎn)變它C的每一件事，以適應(yīng)新的語(yǔ)言，那么，幾個(gè)月內(nèi)，他將C知識(shí)，并在這個(gè)基礎(chǔ)上擴(kuò)展，那么他就可以繼續(xù)保持高效率，帶著已有的知識(shí)，進(jìn)入面向?qū)ο蟪绦蛟O(shè)計(jì)的世界。因?yàn)槊總€(gè)有他己的序設(shè)模型所以個(gè)轉(zhuǎn)是的因此，++成功的原因是經(jīng)濟(jì)上的：轉(zhuǎn)變到OOP需要代價(jià)，而轉(zhuǎn)變到C++較好的即便程序員在C++環(huán)境下繼續(xù)寫C代碼，也能直接得到好處，因?yàn)镃++堵塞了C些，并提供更好的類型檢查和編譯時(shí)的分析。程序員必須先說(shuō)明函數(shù)，使編譯器能檢查它們的使用情況。預(yù)處理虛擬刪除值替換宏，這就少了查找疵點(diǎn)的+個(gè)稱為references()，它允許對(duì)函數(shù)參數(shù)和返回值的地址進(jìn)行更方便的處理。函數(shù)重載改進(jìn)了對(duì)名字的處理，使程序員能對(duì)不同的函數(shù)使用相同的名字。另外，名字空間也加強(qiáng)了名字的控制。許多性能使與學(xué)習(xí)新語(yǔ)言有關(guān)的問(wèn)題是效率的問(wèn)題。所有公司都不可避免地因軟件工程師學(xué)習(xí)新語(yǔ)言C++是對(duì)C的擴(kuò)充，而不是新的文法和新的程序設(shè)計(jì)模型。程序員學(xué)習(xí)和理解這些性能，逐漸應(yīng)用并繼續(xù)創(chuàng)建有用的代碼。這是C++成功的最重要的原因之一。另外，已有的C代碼在C++中仍然是有用的，但因?yàn)镃++編譯器更嚴(yán)格，所以，重新編譯運(yùn)行有時(shí)，以程序執(zhí)行速度換取程序員的效率是值得的。假如一個(gè)金融模型僅在短期內(nèi)有用，所以C++C程序員非常重視運(yùn)行效率，這讓他們認(rèn)為這個(gè)語(yǔ)言不太龐大，也不太慢。產(chǎn)生的代碼運(yùn)行效率不夠時(shí)，程序員可以用C++C++不僅有與C相同的基本控制能力（和C++程序中直接寫匯編語(yǔ)言的能力），非正式的證據(jù)，面向?qū)ο蟮腃++程序的速度與用C寫的程序速度相差在±10%之內(nèi)，而且常常更接近。為適合于某問(wèn)題而設(shè)計(jì)的類當(dāng)然能更好地表達(dá)這個(gè)問(wèn)題。這意味著寫代碼時(shí)，程序員是在用問(wèn)題空間的術(shù)語(yǔ)描述問(wèn)題的解（，而不是用計(jì)算機(jī)的術(shù)語(yǔ)，也就是解空間的術(shù)語(yǔ)，描述問(wèn)題的解（器。程序員所涉及的是較的概念，一行代碼能做的事情。易于表達(dá)所帶來(lái)的另一個(gè)好處是易于。據(jù)，在程序的整個(gè)生命周期中，占了花費(fèi)的很大部分。如果程序容易理解，那么它就更容易，還能減少創(chuàng)建和文檔的花費(fèi)。C++的主要目標(biāo)是讓程序員能更容易地使用庫(kù)，這是通過(guò)將庫(kù)轉(zhuǎn)換為新數(shù)據(jù)類型（類）來(lái)完成的。引入一個(gè)庫(kù)，就是向該語(yǔ)言增加一個(gè)新類型。編譯器負(fù)責(zé)這個(gè)庫(kù)如何使用，保證適當(dāng)?shù)某跏蓟颓宄?，保證函數(shù)被正確地調(diào)用，因此程序員的精力可以集中在他想要這個(gè)庫(kù)做什么，而不是如何做上。因?yàn)槌绦虻母鞑糠种g名字是的，所以程序員想用多少庫(kù)就用多少庫(kù)，不會(huì)有像C語(yǔ)是重用庫(kù)代碼特別有用的工具。用模板設(shè)計(jì)的類型很容易與其他類型一起工作。因?yàn)槟０鍖?duì)程錯(cuò)誤在C語(yǔ)言中，錯(cuò)誤處理聲名狼藉。程序員常常忽視它們，對(duì)它們束手無(wú)策。如果正在建大而復(fù)雜的程序，沒(méi)什么比讓錯(cuò)隱藏在某處，不它來(lái)自何處更的了。C++異處理（見第17章的內(nèi)容）BASIC對(duì)于某些類型的問(wèn)題能很快解決，但是如果這個(gè)程序有幾頁(yè)紙長(zhǎng)，或者超出該語(yǔ)言的正常解題范圍，那么它可能算不出結(jié)果。C語(yǔ)言同樣有這樣的限制，例如當(dāng)程序超過(guò)50000行時(shí)，名字就開始成為問(wèn)題。簡(jiǎn)言之，程序員用光了函數(shù)和變量名。另一個(gè)特別糟糕的問(wèn)題是如果C語(yǔ)言中存在一些小漏洞—錯(cuò)誤藏在大程序中，要找出它們是極其的。沒(méi)有清楚的文字告訴程序員，什么時(shí)候他的語(yǔ)言會(huì)失效，即便有，他也會(huì)忽視它們。他不說(shuō)“我的BASIC程序太大，我必須用C重寫”，而是試圖硬塞進(jìn)另外幾行，增加額外的性能。所以額外的花費(fèi)就悄悄增加了。設(shè)計(jì)C++的目的是為了輔助大程序設(shè)計(jì)，也就是說(shuō)，去掉小程序和大程序之間復(fù)雜性的分界。當(dāng)程序員寫 o-world類實(shí)用程序時(shí)，他確實(shí)不需要用OOP、模板、名字空間和異常處理但當(dāng)他需要的時(shí)候，這些性能就有用了。而且，編譯器在排除錯(cuò)誤方面，對(duì)于小程序和大程序一樣有。OOP中，方法學(xué)是一個(gè)有許多實(shí)踐的領(lǐng)域。因此，在程序員考慮采用某一方法之前，了解該方法將要解決的問(wèn)題是很重要的。對(duì)于C++，有一點(diǎn)是確實(shí)的：它本身就是希望減少程序表達(dá)的復(fù)雜性。從而不C++認(rèn)識(shí)到“方法學(xué)”一詞含義太廣是很重要的。實(shí)際上，設(shè)計(jì)和編寫程序時(shí)，無(wú)論做什么都在使用法。只不過(guò)因?yàn)樗浅绦騿T自己的方法而沒(méi)有。但是，它是程序員編程中的一個(gè)過(guò)程。如果過(guò)程是有效的，只需要用C++做很小的調(diào)整。如果程序員對(duì)他的效率和調(diào)整復(fù)雜的，另一個(gè)是程序的分析，為了將來(lái)理解和程序而產(chǎn)生的。創(chuàng)建和都是程序生命期的內(nèi)部程序設(shè)計(jì)的演化（C++只是其中的一步）從程序設(shè)計(jì)模型強(qiáng)加于內(nèi)部開始，也就是允許程序員為內(nèi)存位置和機(jī)器指令取別名。這是數(shù)字機(jī)器程序設(shè)計(jì)的一次飛躍，帶動(dòng)了其他方面的發(fā)展，包括從初級(jí)機(jī)器中抽象出來(lái)，向更方便地解決手邊問(wèn)題的模型發(fā)展。不是所有這些發(fā)展都能流行，于學(xué)術(shù)界并延伸進(jìn)計(jì)算機(jī)世界的思想常常依賴于所適應(yīng)的問(wèn)題。命名子程序的創(chuàng)建和支持子程序庫(kù)的連接技術(shù)在50年代向前飛躍發(fā)展，并且孕育出了兩個(gè)語(yǔ)言，它們?cè)诋?dāng)時(shí)產(chǎn)生了巨大沖擊，這就是為科學(xué)工作者使用的FORTRAN（FORmula-TRANslation）和為商業(yè)者使用的COBOL（COmmonBusiness-OrientedLanguage。純計(jì)算機(jī)科學(xué)中很成功的語(yǔ)言是Lisp（List-Processing），而面向數(shù)學(xué)的語(yǔ)言應(yīng)當(dāng)是APL（AProgrammingLanguage這些語(yǔ)言的共同特點(diǎn)是對(duì)過(guò)程的使用。Lisp和APL的創(chuàng)造專注于語(yǔ)言的高雅—語(yǔ)言的“missionFOTRAN和COBOL的創(chuàng)造是為了解決專門的問(wèn)題，當(dāng)這些問(wèn)題變得更復(fù)雜，有新的問(wèn)題出現(xiàn)時(shí)，它們又得到了發(fā)展。甚至它們進(jìn)入衰FRTRAN和COBOL的版本都面向?qū)ο筮M(jìn)行了擴(kuò)充（后時(shí)髦哲學(xué)的基本原則是：任何具有自己獨(dú)特生活方式的組織，其主要目標(biāo)就是使這種生活方式永存。命名子程序在程序設(shè)計(jì)中起了重要作用，語(yǔ)言的設(shè)計(jì)圍繞著這一原則，特別是Algol和Pascal。同時(shí)另外一些語(yǔ)言也出現(xiàn)了，它們成功地解決了程序設(shè)計(jì)的一些子集問(wèn)題，并將它們有序排列。最有趣的兩個(gè)語(yǔ)言是Prolog和FTH。前者是圍繞著推理機(jī)而建立的（在其他語(yǔ)言中常常稱作庫(kù)。后者是一個(gè)可擴(kuò)充語(yǔ)言，允許程序員重新形成這個(gè)語(yǔ)言，以適應(yīng)所解決的問(wèn)題，觀上類于面對(duì)象序設(shè)。FOTH還可以改變語(yǔ)言，因而很難，并且是內(nèi)部原則概念最純正的表達(dá)，它強(qiáng)調(diào)的是問(wèn)題一時(shí)的解，而不是對(duì)這個(gè)解的。人們還創(chuàng)造了其他許多語(yǔ)言，以解決某一部分的程序設(shè)計(jì)問(wèn)題。通常，這些語(yǔ)言以特定的BASIC（BeginnersAll-purposeSymbolicInstructionCode）是在60年代設(shè)計(jì)的，目的是使程序設(shè)計(jì)對(duì)初學(xué)者更簡(jiǎn)單。APL的設(shè)計(jì)是為了數(shù)學(xué)處理。兩種語(yǔ)言都能夠解決其他問(wèn)題，而關(guān)鍵在于它們是否是這些問(wèn)題集合最理想的解。有一句笑話是，“帶著錘子三年，BASIC或APL語(yǔ)言，特別是，當(dāng)最終期限很短且這個(gè)解的生命期有限時(shí)，它就是我們問(wèn)題最好的解。然而，最終考慮兩個(gè)因素：復(fù)雜性的管理和（將在下一部分討論。即這種語(yǔ)言首先是為某一領(lǐng)域開發(fā)的，而程序員又不愿花很長(zhǎng)時(shí)間來(lái)熟悉這門語(yǔ)言，其結(jié)果只能使程序越來(lái)越長(zhǎng)，使手頭的問(wèn)題屈服于語(yǔ)言。界限是模糊的：誰(shuí)能說(shuō)什么時(shí)候您的語(yǔ)言會(huì)使您失望呢？這不是馬上就出現(xiàn)的。問(wèn)題的解開始變長(zhǎng)，并且對(duì)于程序員更具性。為知道語(yǔ)言大概的限制，你得，這種聰明變成了一種標(biāo)準(zhǔn)，也就是“為了使該語(yǔ)言工作而努力”。這似乎是人類的操作方式，而不是遇到缺陷就抱怨，并且不再稱它為缺陷。最終，程序設(shè)計(jì)問(wèn)題對(duì)于求解和變得太了，即求得的解太昂貴了。人們最終明白了，程序的復(fù)雜性超出了我們能夠處理的程度。盡管一大類程序設(shè)計(jì)要求開發(fā)期間去做大部分工作并創(chuàng)建要求最小的解（或者簡(jiǎn)單地丟掉這個(gè)解，或者用不同的解替換它，但這只是了，服務(wù)就必須隨著變化。這樣，當(dāng)?shù)谝话姹鹃_始運(yùn)行時(shí)，項(xiàng)目并沒(méi)有結(jié)束。項(xiàng)目是一個(gè)不斷外部為了更新和改善程序，需要更新思考問(wèn)題的方法。它不只是“我們?nèi)绾巫尦绦蚬ぷ鳌?，而是“我們?nèi)绾巫尦绦蚬ぷ鞑⑶沂顾菀赘淖儭?。這里就有一個(gè)新問(wèn)題：當(dāng)我們只是試圖讓程序工作時(shí)，我們可以假設(shè)開發(fā)組是穩(wěn)定的（總之，我們可以希望這樣，但是，如果我們正在考慮程序的整個(gè)生命期，就必須假設(shè)開發(fā)組成員會(huì)改變。這意味著，新組員必須以某種方式學(xué)習(xí)原程序的要點(diǎn)，并與老組員互相通訊（也許通過(guò)。這樣，該程序就需要某種形式的設(shè)計(jì)文檔。因?yàn)橹幌胱尦绦蚬ぷ?，文檔并不是必需的，所以還沒(méi)有像由程序設(shè)計(jì)語(yǔ)言強(qiáng)加于程序那樣的、強(qiáng)加于創(chuàng)建文檔的規(guī)則。這樣，如果要求文檔滿足特定的需要，就必須對(duì)文檔強(qiáng)加外部原（形式的爭(zhēng)論.比對(duì)“最好”程序設(shè)計(jì)語(yǔ)言的爭(zhēng)論更激烈。決定外部原則時(shí)，頭腦中的重要問(wèn)題是“我準(zhǔn)備解決什么問(wèn)題”。問(wèn)題的根本就是上面所說(shuō)的“我們?nèi)绾巫屗ぷ骱褪顾菀赘淖儭薄Ｈ欢?，這個(gè)問(wèn)題常常有多種解釋：它變成了“我如何才能與FoobleBlah文檔規(guī)范說(shuō)明一致，以使會(huì)為此給我撥款”。這樣，外部原則的目的是為了建立文檔，而不是為了設(shè)計(jì)好的、可的程序。文檔竟然變得比程序本身更重要了。被問(wèn)到未來(lái)一般和特殊的計(jì)算的方向時(shí)，我會(huì)從這樣的問(wèn)題開始：哪種解花費(fèi)較少？假設(shè)這個(gè)解滿足需要，價(jià)格的不同足以使程序員放棄他當(dāng)前做事情的習(xí)慣方式嗎？如果他的方法包括在項(xiàng)目分析和設(shè)計(jì)過(guò)程中所創(chuàng)建的每個(gè)文檔，并且包括當(dāng)項(xiàng)目進(jìn)化時(shí)這些文檔，那么當(dāng)項(xiàng)目更新時(shí)，他的系統(tǒng)將花費(fèi)很大，但是它能使新組員容易理解（假設(shè)沒(méi)有那么多的使人害怕閱的文檔。這樣創(chuàng)建和方法的花費(fèi)會(huì)和它打算替代方法的花費(fèi)一樣多。外部結(jié)構(gòu)系列的另一個(gè)是最小化方法為完成設(shè)而進(jìn)行足夠的分析，然丟掉它們，使得程序員不再花時(shí)間和錢去它；為開始編碼而做足夠的設(shè)計(jì)，然后丟掉這個(gè)設(shè)計(jì)，使得程序員不再花時(shí)間和錢去這些文檔；然后使得代碼是一流的和清晰的，代碼中只需要最少新組員只需花費(fèi)很少的時(shí)間（總之，沒(méi)有人真地理解它們，所以他能較快地參與工作。即便不文檔，丟掉文檔也不是最好的辦法，因?yàn)檫@畢竟是程序員所做的有效工作。某但是，代碼包含了我們實(shí)際上希望外部原則所產(chǎn)生的事物的本質(zhì)：通訊。我們只是希望能與改進(jìn)這個(gè)程序的新組員通訊就足夠了。但是，我們還想使花費(fèi)在外部原則上的錢最少，因?yàn)樽罱K人們只為這個(gè)程序所提供的服務(wù)付錢，而不是為它后面的設(shè)計(jì)文檔付錢。為了真正有用，外部原則應(yīng)當(dāng)做比只產(chǎn)生文檔的事情—它應(yīng)當(dāng)是項(xiàng)目組成員在創(chuàng)建設(shè)計(jì)時(shí)為了討論問(wèn)題而采用的通訊方法。理想的外部原則目標(biāo)是使關(guān)于程序分析和設(shè)計(jì)的通訊更容易。這對(duì)于現(xiàn)在為這而為了產(chǎn)生好的設(shè)計(jì)。發(fā)者為機(jī)器做大量工作的外部原則似乎從一開始就注定要失敗。成功的方法（也就是人們習(xí)慣的方法）它幫助人們進(jìn)行分析和設(shè)計(jì)。這就是，用這種方法比用別的方法對(duì)分析和設(shè)計(jì)中的思考和通訊要容易得多。目前的效率和采用這種方法后的效率應(yīng)當(dāng)明顯不同。否則，人們可能還留在原地。還有，它的使用必須足夠簡(jiǎn)單，不需用手冊(cè)。當(dāng)程序員正在解決問(wèn)題時(shí)，要考慮簡(jiǎn)單性，而不管他適用于符號(hào)還是技術(shù)。沒(méi)有短期回報(bào)，就不會(huì)加強(qiáng)投資。在通向目標(biāo)的可見的進(jìn)展中，沒(méi)有短期回報(bào)，人們就不會(huì)感到采用法能使效率提高，就會(huì)回避它。不能把這個(gè)進(jìn)展誤認(rèn)為是從一種中間形式到另一種中間形式的變換。程序員可以看到他的類，連同類之間互相發(fā)送的消息一起出現(xiàn)。為創(chuàng)造法，就像武斷的約束，因?yàn)樗呛?jiǎn)單的心理狀態(tài)：人們希望感到他們正在做創(chuàng)造性的工作，如果某種方法妨礙他們而不是幫助他們飛快地接近目標(biāo)，他們將設(shè)法繞過(guò)這種方法。在方法學(xué)上我的觀點(diǎn)之一是聽眾對(duì)“小”的理解因人而異。雖然這種看法并不全對(duì)，但它包含一個(gè)正確的：我們所需要的原則與我們正在努力解決問(wèn)題的量級(jí)有關(guān)。小項(xiàng)目完全不需要外部原則，這不同于個(gè)別程序員正在解的生命期問(wèn)題的模式。涉及很多人的大項(xiàng)目會(huì)使人們之間有一些通訊，所以必須使通訊具有形式化方法，以使通訊有效和準(zhǔn)確。麻煩的是介于它們之間的項(xiàng)目。它們對(duì)外部原則的需要程度可能在很大程度上依賴于項(xiàng)目的復(fù)雜性和開發(fā)者的經(jīng)驗(yàn)。確實(shí)，所有中等規(guī)模的項(xiàng)目都不需要忠實(shí)于成方法，即產(chǎn)生許多報(bào)告和很多文檔。一些項(xiàng)目也許這樣做，但許多項(xiàng)目可以僥幸成功于“方法學(xué)簡(jiǎn)化”代碼多而文檔少。我們面前的所有方法學(xué)的復(fù)雜性可以減少到80%～20%的（或更少的）規(guī)則。20%些方法學(xué)。如果我們的設(shè)計(jì)是充分的，并且也不可怕，那么我們也許不需要方法學(xué)或不全OOP現(xiàn)在提出一個(gè)更有意義的問(wèn)題。為了使通訊方便，假設(shè)方法學(xué)是需要的。這種關(guān)于程序的元通訊是必須的，因?yàn)槌绦蛟O(shè)計(jì)語(yǔ)言是不充分的—它太原始，趨向于機(jī)器范例，對(duì)于談?wù)搯?wèn)題不很有用。例如，過(guò)程程序設(shè)計(jì)方法要求用數(shù)據(jù)和變換數(shù)據(jù)的函數(shù)作為術(shù)語(yǔ)談?wù)摮绦?。因?yàn)檫@不是我們討論實(shí)際問(wèn)題的方法，所以必須在問(wèn)題描述和解描述之間翻譯來(lái)翻譯去。一旦得到了一個(gè)解描述并且實(shí)現(xiàn)了它，以后無(wú)論何時(shí)對(duì)這個(gè)解描述做改變就要對(duì)問(wèn)題描述做改變。這意味著必須從機(jī)器模式返回問(wèn)題空間。為了得到真正可的程序，并且能夠適應(yīng)問(wèn)題空間上的改變，這種翻譯是必須的。投資和組織的需要似乎要求某種外部原則。過(guò)程程序的最重要的方法學(xué)是結(jié)構(gòu)化技術(shù)。例如，在氣候控制大樓中的空氣調(diào)節(jié)器就變成了氣候調(diào)節(jié)程序的空氣調(diào)節(jié)器，自動(dòng)調(diào)溫器（這是按做的，與OOP不一致。突然，從問(wèn)題空間到解空間的翻譯變成了次要問(wèn)題。可以想象，在程序分析、設(shè)計(jì)的每一階段，能使用相同的術(shù)語(yǔ)學(xué)、相同的描述，這樣，這個(gè)問(wèn)題就變成了“如果文檔（程序）能夠充分地描述它自身，我們?nèi)匀恍枰P(guān)于這個(gè)文檔的文檔嗎？”如果OOP這個(gè)論點(diǎn)也為一個(gè)思想實(shí)驗(yàn)所揭示。假設(shè)程序員需要寫一些小實(shí)用程序，例如能在文本文（就像在第6章的后幾頁(yè)上可找到的那樣最的要花費(fèi)幾小時(shí)寫。現(xiàn)在假設(shè)回50年，個(gè)項(xiàng)目必須用機(jī)器語(yǔ)言匯編語(yǔ)言來(lái)寫50年代需要大量的外部原則和管理，現(xiàn)在不需要了。顯然，工具的發(fā)展已經(jīng)極大地增加了我們不用外部原則解決問(wèn)題的復(fù)雜性這并不是說(shuō)可以不需要外部原則，有用的OOP外部原則解決的問(wèn)題與有用的過(guò)程程序設(shè)計(jì)OOP方法的目標(biāo)首先必須是產(chǎn)生好的設(shè)計(jì)。好設(shè)計(jì)不僅要促進(jìn)重用，而且它與項(xiàng)目的各級(jí)開發(fā)者的需要是一致的。這樣，開發(fā)者就會(huì)更喜歡采用這樣的系統(tǒng)。讓我們基于這些觀點(diǎn)考慮OOP設(shè)計(jì)方法中的一些問(wèn)題。對(duì)象的設(shè)計(jì)不限于寫程序的時(shí)期，它出現(xiàn)在一系列階段。有這種觀點(diǎn)很有好處，因?yàn)槲覀儾辉倨谕O(shè)計(jì)立刻，而是認(rèn)識(shí)到，對(duì)對(duì)象做什么和它應(yīng)當(dāng)像什么的理解是隨著時(shí)間的推移而產(chǎn)生的。這個(gè)觀點(diǎn)也適用于不同類型程序的設(shè)計(jì)。特殊類型程序的模式是通過(guò)一次又一[1]。同樣，對(duì)象有自己的模式，通過(guò)理解、使用和重用而形成。對(duì)象發(fā)現(xiàn)這個(gè)階段出現(xiàn)在程序的最初分析期間?？梢酝ㄟ^(guò)尋找外部因素與界線、系統(tǒng)中的元素副本和最小概念單元而發(fā)現(xiàn)對(duì)象。如果已經(jīng)有了一組類庫(kù)，某些對(duì)象是很明顯的。類之間的共同性（暗示了基類和繼承類，可以立刻出現(xiàn)或在設(shè)計(jì)過(guò)程的后期出現(xiàn)。對(duì)象裝配我們?cè)诮?duì)象時(shí)會(huì)發(fā)現(xiàn)需要一些新成員，這些新成員在對(duì)象發(fā)現(xiàn)時(shí)期未出系統(tǒng)構(gòu)造對(duì)對(duì)象的要求可能出現(xiàn)在以后階段。隨著不斷的學(xué)習(xí)，我們會(huì)改進(jìn)我們系統(tǒng)擴(kuò)充當(dāng)我們向系統(tǒng)增添新的性能時(shí)，可能發(fā)現(xiàn)我們先前的設(shè)計(jì)不容易支持系統(tǒng)擴(kuò)對(duì)象重用這是對(duì)類的真正的重點(diǎn)測(cè)試。如果某些人試圖在全新的情況下重用它，他們會(huì)發(fā)現(xiàn)一些缺點(diǎn)。當(dāng)我們修改一個(gè)類以適應(yīng)更新的程序時(shí)，類的一般原則將變得更清楚，直到我們有了一個(gè)真正可重用的對(duì)象。[1]參看DesignPatterns:ElementsofReusableObject-OrientedSoftwarebyErich etal.,Addison-Wesley,1995和簡(jiǎn)單的類開始，當(dāng)我們對(duì)它有了較好地理解時(shí)再擴(kuò)展這個(gè)類接口，但不可能簡(jiǎn)化已存在的類接口。由于不同的原因，方法承諾的東西往往比它們能夠提供的東西多得多。這是不幸的，因?yàn)楫?dāng)策略和不實(shí)際的期望同時(shí)出現(xiàn)時(shí)程序員會(huì)疑神疑鬼。一些方法的壞名聲，使得程序員丟棄了的許諾是“這個(gè)方法將解決您的所有問(wèn)題”。這一許諾也很可能用這樣的思想表達(dá)，即一個(gè)方法將解決實(shí)際上不存在解的問(wèn)題，或者至少在程序的設(shè)計(jì)領(lǐng)域內(nèi)沒(méi)有解的問(wèn)題：一個(gè)貧窮的，疲憊的、互相疏遠(yuǎn)或的項(xiàng)目組成員；不充分的時(shí)間和資源；或試圖解決一個(gè)實(shí)際上不能解的問(wèn)題（資源不足。最好的方法學(xué)，不管它許諾什么，都不解決這些或類似的任何問(wèn)題。無(wú)論OOP還是C++，都無(wú)助于這樣的問(wèn)題。不幸的是，在這種情況下管理員是樣對(duì)報(bào)1]，他是最動(dòng)搖的。這就是方法應(yīng)當(dāng)成為的東西。提高生產(chǎn)效率不僅取決于管理容易和花費(fèi)不大，而且取決于一開始就創(chuàng)建好的設(shè)計(jì)。由于一些方法學(xué)的創(chuàng)造動(dòng)機(jī)是為了改善，所以它們就片面地強(qiáng)調(diào)OOP設(shè)計(jì)也應(yīng)當(dāng)容易，但這它的附加作用。不管為特殊方法提出什么要求，它都應(yīng)當(dāng)提供這一節(jié)所列出的基本功能：允許為討論這個(gè)項(xiàng)目將完成什么和如何做而進(jìn)行通訊的約定；支持項(xiàng)目結(jié)構(gòu)化的系統(tǒng)；能用某抽象形式描述項(xiàng)目的一組工具（使得程序員能容易地觀察和操作項(xiàng)目。如過(guò)去介紹過(guò)的，一個(gè)更微妙的問(wèn)題是該方法對(duì)待最寶貴資源—對(duì)于很小的項(xiàng)目組，可以用緊密接觸的方式自然維持通訊。這是理想的請(qǐng)況。C++的最大的好處之一是它可以使項(xiàng)目由很少的項(xiàng)目組成員建立，因此，明白表示的通訊能使變得容情況并不總是這樣理想，有可能項(xiàng)目組成員很多，項(xiàng)目很復(fù)雜，這就需要某種形式的通訊原則。方法提供一種在項(xiàng)目組成員之間形成“約定”的辦法?？梢杂脙煞N方式看待這樣的約定：1)的約定基于參與的當(dāng)事人之間互有疑問(wèn)，以使得沒(méi)有人出格且每個(gè)人都做應(yīng)該做的事情。約定清楚地說(shuō)明，如果他們不做這些事，會(huì)出現(xiàn)壞的結(jié)果。這樣看待任何約定，我們就已經(jīng)輸了，因?yàn)槲覀円呀?jīng)認(rèn)為其他人是不可信賴的了。如果不能信任，約定并不能確保好的行為。2)信息的約定是一種努力，使每個(gè)人都知道我們已經(jīng)在哪些方面取得了一致的意見。這是對(duì)通訊的輔助，使得每個(gè)人能看到它并說(shuō)，“是的，這是我認(rèn)為要做的事情。它是協(xié)[1]AreferencetovampiresmadeinTheMythicalMan-Month,byFredBrooks,Addision-Wesley,1975符號(hào)應(yīng)當(dāng)盡可能少。“過(guò)多的噱頭使得軟件變壞”系統(tǒng)設(shè)計(jì)和類設(shè)計(jì)是互相的問(wèn)題。類是可重用工具，而系統(tǒng)是對(duì)特殊問(wèn)題的解（雖類設(shè)計(jì)符號(hào)是必須的嗎？由C++語(yǔ)言提供的類表達(dá)對(duì)大多數(shù)情況是足夠的。如果符號(hào)在保持符號(hào)簡(jiǎn)單。我們想用我們的方法做的所有事情基本上就是發(fā)現(xiàn)對(duì)象及其如何互相連接以形成系統(tǒng)。如果一個(gè)方法或符號(hào)要求的東西，則應(yīng)當(dāng)問(wèn)一問(wèn)，該方法花費(fèi)我們的時(shí)間是否合理。我的朋友MichaelWilk來(lái)術(shù)界，也許并不具備做評(píng)判的資格（從某個(gè)人那里聽說(shuō)的新觀點(diǎn)，但他觀察到，項(xiàng)目、開發(fā)組或公司擁有的最重要的資源是積極性。不管問(wèn)題如何過(guò)去失敗多么嚴(yán)重，工具多么原始或不成套，積極性都能克服這些。不幸的是，各種管理技術(shù)常常完全不考慮積極性，或因?yàn)椴蝗菀锥攘克?，就認(rèn)為它是“不重要”的因素，他們認(rèn)為，如果管理完善，項(xiàng)目就能強(qiáng)制完成。這種認(rèn)識(shí)有開發(fā)組積極性的作用，因?yàn)樗麄儠?huì)感到公司除了利益動(dòng)機(jī)以外就沒(méi)有感的東西了。一旦發(fā)生這種現(xiàn)象，。在選擇任何方法之前，從并不想方法的人那兒得到意見是有幫助的。不真正地理解我們想要法是為了做什么或它能為我們做什么，那么采用法很容易。其他人正在用它，這似乎是很充足的理由。但是，人們有一種奇怪的心理：如果他們相信某件事能解決他們的問(wèn)題，他們就將試用它（這是經(jīng)驗(yàn)，是好的。但是，如果它不能解決他們的問(wèn)題，他們可能加倍地努力，并且開始大聲宣布他們已經(jīng)發(fā)現(xiàn)了偉大的東西（這是否定，是不好的。這個(gè)假設(shè)是，如果見到同一條船上有其他人，就不感到孤單，即便這條船哪兒也不去。這并不是說(shuō)所有的方法學(xué)都什么也不做，而是用精神方法使程序員到牙齒，這些方法為我們提供這些精神。（SoftwareCreativity，RobertGlass編，Prentice-Hall,199Glass已經(jīng)寫過(guò)的短文和文章以及收集到的東西組成的（.J.uger是一個(gè)撰稿者，反映出他在該上多年的思考和研究。他們愉快地說(shuō)明什么是必須的，并不東拉西扯和掃我們的興，不說(shuō)空話，而且，這里有幾百篇參考文獻(xiàn)。所有的[1。（Peoplear，TomDemarcoTimothyLiter編，DorsetHoue,1987有軟件開發(fā)方面的背景，而且本書大體上是針對(duì)項(xiàng)目和開發(fā)組的，但是這本書的重點(diǎn)是人和他們的需要方面，而不是技術(shù)和技術(shù)的需要方面。他們談?wù)搫?chuàng)造一個(gè)環(huán)境，在其中人們是和這本書后面的觀點(diǎn)是對(duì)程序員在采用XYZ方法，然后平靜地做他們總是做的事情時(shí)微笑和點(diǎn)頭（Complexit,M.Mitc Waldrop編，Simon&Schuster,1992。此書集中了SantaFe,NewMexico的一組持不同觀點(diǎn)的科學(xué)家，討論單個(gè)原則不能解決的實(shí)際問(wèn)題（經(jīng)濟(jì)學(xué)中的市場(chǎng)、生物學(xué)的生命原始形式、為什么人們做他們?cè)谏鐣?huì)中應(yīng)做的事情，等等。通過(guò)物理學(xué)、經(jīng)濟(jì)學(xué)、化學(xué)、數(shù)學(xué)、計(jì)算機(jī)科學(xué)、社會(huì)學(xué)和其他學(xué)科的交叉，對(duì)這些問(wèn)題的一種多原則途徑正在發(fā)展。更重要的是，思考這些極其復(fù)雜問(wèn)題的不同方法正在形成。拋開數(shù)學(xué)的確定性，人們想寫一個(gè)所有行為的方程，首先觀察和尋找一個(gè)模式，用任何可能的模擬這個(gè)模式（例如，這本書編入了遺傳算法。我相信，這種思維是有用的，因?yàn)槲覀冋趯?duì)管理越來(lái)越復(fù)雜軟件目的方法做科學(xué)察。我首先，這一點(diǎn)沒(méi)有證明過(guò)。我并不許諾—起草是起點(diǎn)，是其他思想的，是思想試驗(yàn)，盡管這是我在大量思考、適量閱讀和在開發(fā)過(guò)程中對(duì)自己和其他人觀察之后形成的看RobertMcKee2]的教學(xué)中，最初針對(duì)熱心熟練的劇作家們，也針對(duì)小說(shuō)家和編劇。后來(lái)我發(fā)現(xiàn)，程序員與這個(gè)有少量令人拍案稱奇的上口小說(shuō)，其他許多小說(shuō)都很平庸，但有技巧，得到，大量不上口的小說(shuō)得不到。當(dāng)然，小說(shuō)要描述，而程序要編寫。作家還有一些在程序設(shè)計(jì)中不太出現(xiàn)的約束：他們一般單獨(dú)工作或可能在兩個(gè)人的組中工McKee個(gè)目標(biāo)是將花費(fèi)在編劇上的時(shí)間從一年減少到六個(gè)月，在這個(gè)過(guò)程中極大地提高編劇的質(zhì)量。軟件開發(fā)者可以有類似的目標(biāo)。另外一本好“前景”的書是ObjectLessonsTomLove著,SIGSBooks,1993ThroughTwoArts,Inc.,12021WilshireBlvd.Suite868,LosAngeles,CA90025前與典型的過(guò)程語(yǔ)言（和大量已存在的語(yǔ)言）不同，C++語(yǔ)言和語(yǔ)言性能中有許多防護(hù)，程序員能建立自己的防護(hù)。這些防護(hù)意在防止程序員創(chuàng)建的程序破壞它的結(jié)構(gòu)，無(wú)論在創(chuàng)建它的整個(gè)期間還是在程序期間。不管分析得如何透徹，這里還有一些有關(guān)系統(tǒng)的事直到設(shè)計(jì)時(shí)還沒(méi)有揭示出來(lái)，的直到程序完成和運(yùn)行時(shí)還沒(méi)有揭示出來(lái)。因此，快速通過(guò)分析過(guò)程和設(shè)計(jì)過(guò)程以實(shí)現(xiàn)目標(biāo)系統(tǒng)的測(cè)試是重要的。根據(jù)第一點(diǎn)，這比用過(guò)程語(yǔ)言更安全，因?yàn)镃++中的防護(hù)有助于防止“面條”代碼的創(chuàng)建。著重強(qiáng)調(diào)第二點(diǎn)。由于歷史原因，我們已經(jīng)用了過(guò)程語(yǔ)言，因此在開始設(shè)計(jì)之前開DBMS時(shí)，徹底DBMS是一類具有良好形式且容易理解的問(wèn)題。在這一章中討論的這類程序設(shè)計(jì)問(wèn)題是ild-car變體問(wèn)題，它不只簡(jiǎn)單地重新形成已知解，而是包括一個(gè)或多個(gè)ild-card因素—1]手設(shè)計(jì)之前徹底地分析ild-card問(wèn)題會(huì)導(dǎo)致分析癱瘓，因?yàn)樵诜治鲭A段沒(méi)有足夠的信息解決這類問(wèn)題。解這樣的問(wèn)題要求在整個(gè)周期中反復(fù)，要（以產(chǎn)生感性認(rèn)識(shí)，因?yàn)槌绦騿T正在做新事情并且有較高潛在回報(bào)結(jié)果是，由盲目“闖”預(yù)備性實(shí)而產(chǎn)生是它反而能減少在ild-ard項(xiàng)中的，為人較早地現(xiàn)一特殊設(shè)計(jì)否可。這個(gè)方法的目標(biāo)是通過(guò)建議解處理wild-card問(wèn)題，得到最快的開發(fā)結(jié)果，使設(shè)計(jì)能盡早地被證明或反證。這些努力不會(huì)白費(fèi)。這個(gè)方法常常建議，“建立一個(gè)解，然后再丟掉它”。用OOP，可能仍然丟掉一部分，但是因?yàn)榇a被封裝成類，不可避免地生產(chǎn)一些有用的類設(shè)計(jì)和第一次反復(fù)中發(fā)展一些對(duì)系統(tǒng)設(shè)計(jì)有價(jià)值的思想，它們不需要丟掉。這樣，對(duì)某一問(wèn)題快速地過(guò)一遍不僅產(chǎn)生對(duì)下一次分析、設(shè)計(jì)的重復(fù)重要的信息，而且也為下一次的重復(fù)過(guò)程創(chuàng)這個(gè)方法的另一性能是能對(duì)項(xiàng)目早期部分的集體討論提供支持。由于保持最初的文檔小而簡(jiǎn)明，所以最初的文檔可以由小組與動(dòng)態(tài)創(chuàng)建該描述的通過(guò)幾次集體討論而創(chuàng)建，這不僅要求每個(gè)人的投入，而且還鼓勵(lì)開發(fā)組中的每個(gè)人意見一致。也許更重要的是，它能在較高的積極性下完成一個(gè)項(xiàng)目（如先前注意到的，這是最基本的資源。作家的最有價(jià)值的計(jì)算機(jī)工具是字處理器，因?yàn)樗菀字С治臋n的結(jié)構(gòu)。對(duì)于程序設(shè)計(jì)項(xiàng)目，程序的結(jié)構(gòu)通常是由某形式的分離的文檔來(lái)表述的。因?yàn)轫?xiàng)目變得更復(fù)雜，所以文檔是必Brooks[2]獨(dú)立文檔的傻念頭—而我們?cè)诔绦蛟O(shè)計(jì)文檔方面的實(shí)踐了我們自己的。我們典型努是序器讀式一立讀文檔?”我們認(rèn)為，使用熟悉的工具和思維模式是非常重要的 OOP的改變正著由它自己引我估計(jì)這樣的項(xiàng)目的主要規(guī)則：如果多于一張wd-card，則不計(jì)劃它要費(fèi)多長(zhǎng)時(shí)間和它花費(fèi)多少。這里有太多的自由度。TheMythicalMan-Month,出處同上的。較早的OOP方法學(xué)已經(jīng)因?yàn)槭褂镁?xì)的圖形符號(hào)方案而受挫了。我們不可避免地要大量改變?cè)O(shè)計(jì)，因?yàn)轫毟淖冊(cè)O(shè)計(jì)以避免棘手的問(wèn)題，所以用很難修改的符號(hào)表示設(shè)計(jì)是不好的。只是最近，才有處理這些圖形符號(hào)的工具出現(xiàn)。容易使用設(shè)計(jì)符號(hào)的工具必須在希望人們使用這種方法之前就有了。把這種觀點(diǎn)與在軟件設(shè)計(jì)過(guò)程中要求文檔這一事實(shí)結(jié)合，可以看[1。事實(shí)上，每個(gè)公司都有了這些工具（所以試用這種方法不需要花費(fèi)這符合++的精神，我們是建立在已有的知識(shí)和工具基礎(chǔ)上的，而不是把它們丟掉。[2]，但它不能緊密地支持集體討論。但是，每個(gè)人都懂得畫輪廓，而且很多字處理器有一些畫輪廓人們可以擴(kuò)展和推倒輪廓，決定于系統(tǒng)中粒度的不同層次。（如后描述）因?yàn)槌绦騿T創(chuàng)建了設(shè)高概建立的系統(tǒng)，無(wú)論如何復(fù)雜，都有一個(gè)基本的目的，它服務(wù)于哪一行業(yè)和它應(yīng)滿足什以基本需要。如果我們看看用戶界面、硬件、系統(tǒng)特殊的細(xì)節(jié)、編碼算法和效率問(wèn)題，那么我們最終會(huì)發(fā)現(xiàn)它有簡(jiǎn)單和直的。就像好塢中謂的高概念，我們能用兩句話描述它這種純描述是起點(diǎn)。高概念相當(dāng)重要，因?yàn)樗鼮槲覀兊捻?xiàng)目定調(diào)。它是委派語(yǔ)句，不需要一開始就正確（可以在完全清楚它之前完善這個(gè)論述或構(gòu)思設(shè)計(jì)，它只是嘗試，直到它正確。例如，在空通控制系統(tǒng)中，我們可以從系統(tǒng)的一個(gè)高概念開始，即準(zhǔn)備建立“控制塔飛機(jī)。”但是當(dāng)將該系統(tǒng)用于非常小的飛機(jī)場(chǎng)時(shí)，也許只有一個(gè)導(dǎo)航員或無(wú)人導(dǎo)航。更有用的模型不會(huì)使得正在論述劇本的論述是用一兩頁(yè)紙寫的故事概要，即高概念的外層。計(jì)算機(jī)系統(tǒng)發(fā)展高概念和論述的最好的途徑可能是組成一個(gè)小組，該小組有一個(gè)具有寫能力的輔助工具。在集體討論中能提出建議，輔助工具在與小組相連的網(wǎng)絡(luò)計(jì)算機(jī)上或在屏幕上表達(dá)這些思想。輔助工具只起捉刀人的作用，不評(píng)價(jià)這些思想，只是簡(jiǎn)單地使它們清楚和保持它們通順。論述變成了初始對(duì)象發(fā)現(xiàn)的起點(diǎn)和設(shè)計(jì)的第一個(gè)雛形，它也能在擁有輔助工具的小組內(nèi)完成。結(jié)構(gòu)對(duì)于系統(tǒng)，結(jié)構(gòu)是關(guān)鍵。沒(méi)有結(jié)構(gòu)就會(huì)任意收集意義。有了結(jié)構(gòu)，就有了故事。我的觀察是基于我最熟悉的 Word的擴(kuò)展功能，它已被用于產(chǎn)生了這本書的照相機(jī)準(zhǔn)備的頁(yè)我鼓勵(lì)這種選擇，即用簡(jiǎn)單的方框、線和符號(hào)，它們?cè)诋嬜痔幚淼陌鼤r(shí)是可用的，而不是很難產(chǎn)生的無(wú)定型的形狀。論述包括名詞和動(dòng)詞。當(dāng)我們列出它們后，一般將名詞作為類，動(dòng)詞或者變?yōu)檫@些類的方這是一個(gè)反復(fù)的過(guò)程。在將來(lái)的階段和后面的設(shè)計(jì)中可以增加另外的類和方法，因?yàn)槟菚r(shí)程序員對(duì)問(wèn)題會(huì)有更清晰的認(rèn)識(shí)。這種構(gòu)造方法的要點(diǎn)是不需要程序員當(dāng)前完全理解問(wèn)題，所以不期望設(shè)計(jì)一下子展現(xiàn)在程序員的面前。從簡(jiǎn)單的論述檢查開始，為每個(gè)已找出的唯一名稱創(chuàng)建“對(duì)象”中的第二層子段。取那些很顯然作用于對(duì)象的動(dòng)詞，置它們于相詞下面的第三層方法子段。對(duì)每個(gè)方法增加參數(shù)表如果一個(gè)類是從另一個(gè)類繼承來(lái)的，則它的第二層子段應(yīng)當(dāng)盡可能靠近地放在這個(gè)基類之derived:publicbase時(shí)應(yīng)當(dāng)做的。這允許雖然能設(shè)置系統(tǒng)去表示從公共接口繼承來(lái)的方法，但目的是只創(chuàng)建類和它們的公共接口，其他元素都被認(rèn)為是下面實(shí)現(xiàn)的部分，不是設(shè)計(jì)。如果要表示它們，它們應(yīng)當(dāng)作為相應(yīng)類下面的文本層注解出現(xiàn)。OccamsRazor辦法：考慮這個(gè)選擇并選擇最簡(jiǎn)單的一個(gè)，因?yàn)楹?jiǎn)單的類幾乎總是最好的。向類增加元素很容易，但是隨著時(shí)間的推移，丟掉元素就困難了。如果需要培植這一過(guò)程，請(qǐng)看一個(gè)懶程序員的觀點(diǎn)：您應(yīng)當(dāng)希望哪些對(duì)象魔術(shù)般地出現(xiàn)，用以解決您的問(wèn)題？讓一些可以用的類和各種系統(tǒng)設(shè)計(jì)模式作為手頭的參考是有用的。我們不要總是在對(duì)象段里，分析這個(gè)論述時(shí)應(yīng)當(dāng)在對(duì)象和系統(tǒng)設(shè)計(jì)之間來(lái)回運(yùn)動(dòng)。任何時(shí)候，我們都可能想在任子段下面寫一些通文本，關(guān)特殊類或方法的想或注解。從高概念和論述開始，會(huì)出現(xiàn)一些子情節(jié)。通常，它們就像“輸入、過(guò)程、輸出”或“用戶界面、活動(dòng)”一樣簡(jiǎn)單。在“設(shè)計(jì)”下面，每個(gè)子情節(jié)有它自己的第二層子段。大多數(shù)故事沿用一組公共情節(jié)。在oopoop設(shè)計(jì)模式上的資源，可以幫助對(duì)情節(jié)的搜索。我們現(xiàn)在正在創(chuàng)建系統(tǒng)的粗略草圖。在集體討論會(huì)上，小組中的人們對(duì)他們認(rèn)為應(yīng)該出現(xiàn)在系統(tǒng)中的活動(dòng)提出建議，并且分別記錄，不需要為將它與整個(gè)系統(tǒng)相連而工作。讓整個(gè)項(xiàng)目組，包括機(jī)械設(shè)計(jì)人員（如果需要、市場(chǎng)人員、管理人員，都。這是特別重要的，這不僅使得每個(gè)人心情舒暢，因?yàn)樗麄兊囊庖娨呀?jīng)被考慮，而且每一個(gè)人的參加對(duì)會(huì)議都是有價(jià)值的。在特殊的子情節(jié)下面，每個(gè)階段都給出它自己的第三層子段。條件和過(guò)渡被描寫為文本，放在這個(gè)階段的標(biāo)題下。情況如果理想，我們最終能夠?qū)懗雒總€(gè)子情節(jié)的基本的東西（因?yàn)樵O(shè)計(jì)是反復(fù)過(guò)程，作為對(duì)象的創(chuàng)建并向它們發(fā)送的消息。這就變成了這個(gè)子情節(jié)的最初代碼。開這是粗設(shè)計(jì)到編譯代碼的最初轉(zhuǎn)換，編譯代碼能被測(cè)試，特別是，它將證明或者反證我們?cè)撧D(zhuǎn)換用這樣法，即通過(guò)對(duì)代碼中的結(jié)構(gòu)或有關(guān)文字的改變重新產(chǎn)生文檔。這樣，在編碼開始后（和不可避免的改變出現(xiàn)后）產(chǎn)生設(shè)計(jì)文檔就變得非常容易了，而設(shè)計(jì)文檔能變成項(xiàng)目進(jìn)展的報(bào)告工具。通過(guò)在第一層的標(biāo)題中使用標(biāo)準(zhǔn)段名“對(duì)象”和“設(shè)計(jì)”，我們就能運(yùn)行我們的工具以突出這些段，并由它們產(chǎn)生文件頭。依據(jù)我們所在的主段和正在工作的子段層，完成不同的工作。最容易的辦法可能是讓我們的工具或宏把文檔分成小塊并且相應(yīng)地在每一小塊上工作。對(duì)于“對(duì)象”中的每個(gè)第二層段，在段名（類名和它的基類名，如果有的話）中會(huì)有足夠的信息用以自動(dòng)地產(chǎn)生類，在這個(gè)類名下面的每個(gè)第三層子段，段名（成員函數(shù)名、參數(shù)表和返回類型）中會(huì)有足夠的信息用以產(chǎn)生這個(gè)成員函數(shù)的。我們的工具將簡(jiǎn)單地管理這些并創(chuàng)建類。為了使問(wèn)題簡(jiǎn)單，單個(gè)類將出現(xiàn)在每個(gè)頭文件中。命名這些頭文件的最好辦法，也許編制情節(jié)可以更精細(xì)。每個(gè)子情節(jié)可以產(chǎn)生一個(gè)獨(dú)立的函數(shù)，由內(nèi)部main()調(diào)用，或者就是main()中的一段。從一個(gè)能完成我們的工作的事情開始，更好的模式可能在以后的反復(fù)中形為“對(duì)象”段中描述的每個(gè)類產(chǎn)生一個(gè)頭文件，也就是為每一個(gè)類創(chuàng)建一個(gè)類，帶有公共接口函數(shù)和與它們相聯(lián)系的描述塊；對(duì)每個(gè)類附上在以后很容易分析的專門標(biāo)號(hào)。//#[1]、//#[2]等等。所有產(chǎn)生的文件都有文檔注釋，放在帶有標(biāo)號(hào)的專門標(biāo)識(shí)塊中。類名和函數(shù)也保留注釋標(biāo)記。這樣，轉(zhuǎn)換工具能檢查、提取所有信息，并用文檔描述語(yǔ)言更好地重新產(chǎn)生源文檔，例如用RichTextFormat(RTF)描述語(yǔ)言。在這個(gè)階段，有兩件事會(huì)發(fā)生。如果設(shè)計(jì)是在早期，那么我們可能需要繼續(xù)加工處理集體討論會(huì)的文檔（而不是代碼）或小組負(fù)責(zé)的那部分文檔。然而，如果設(shè)計(jì)是完全充足的，那么我們就可以開始編碼。如果在編碼階段增加接口元素，則這些元素必須連同加過(guò)標(biāo)號(hào)的注釋一起由程序員加標(biāo)號(hào)，所以重新產(chǎn)生的程序能用新信息產(chǎn)生文檔。如果我們擁有前端編譯器，我們確實(shí)可以對(duì)類和函數(shù)自動(dòng)進(jìn)行編譯，但是它是大作業(yè)，并且這個(gè)語(yǔ)言正在演化。使用明確的標(biāo)號(hào)，是相當(dāng)不安全的，商業(yè)瀏覽工具能用以檢驗(yàn)是否所有的公共函數(shù)都已經(jīng)形成文檔了（也就是，它們已加標(biāo)號(hào)了。重這類似于重寫劇本以完善它，使它更好。在程序設(shè)計(jì)中，這是重復(fù)過(guò)程，我們的程序從好到更好，在第一遍中還沒(méi)有真正理解的問(wèn)題變得清楚了。我們的類從在單個(gè)項(xiàng)目中使用進(jìn)化為可重用的資源。從工具的觀點(diǎn)看，轉(zhuǎn)換該過(guò)程略微復(fù)雜，我們希望能分解頭文件，使我們能重新整理這些文件使它們成為設(shè)計(jì)文檔，包括在編碼過(guò)程中已經(jīng)做過(guò)的全部改變。在設(shè)計(jì)文檔中對(duì)設(shè)計(jì)有任何改變，頭文件也必須完全重建，這樣就不會(huì)丟失為了得到在第一遍反復(fù)中編譯所需要的頭文件而做的任何工作。因此，我們的工具不僅應(yīng)當(dāng)能找出加標(biāo)號(hào)的信息，將它們變成段層和文本#include。我們應(yīng)當(dāng)記住，頭文件表達(dá)了類設(shè)計(jì)而須能夠由設(shè)計(jì)文檔重新產(chǎn)生頭文件。我們還應(yīng)當(dāng)注意文本層注解和討論，它們最初產(chǎn)生時(shí)被轉(zhuǎn)換為加標(biāo)號(hào)的注釋，比在設(shè)計(jì)演化過(guò)程中程序員修改的內(nèi)容?；旧希@些注解和討論被收集并放在各自的地方，因此設(shè)計(jì)文檔反映了新的信息。這就允許我們?nèi)ジ淖冞@些信息，并且返還到已產(chǎn)生的頭文件中。對(duì)于系統(tǒng)設(shè)計(jì)（main()和任何支持函數(shù)，我們也可能想獲得整個(gè)文件，添加段標(biāo)識(shí)符，例如A、B、C等等，作為加標(biāo)號(hào)的注釋（不用行號(hào)，因?yàn)樾刑?hào)會(huì)改變，并附上段描述（然后返還main()文件，作為加標(biāo)號(hào)的文本。須知道什么時(shí)候停止，什么時(shí)候重復(fù)設(shè)計(jì)。理想的情況是，我們達(dá)到了目標(biāo)功能，處在完善和增加新功能的過(guò)程中，最后期限到來(lái)，強(qiáng)迫我們停止并發(fā)出我們的版本（記住，軟。邏我們會(huì)周期性地希望知道項(xiàng)目在什么地方需要重新整理文檔。如果是在網(wǎng)上使用自動(dòng)化工具，這個(gè)過(guò)程無(wú)關(guān)緊要。經(jīng)常地整集和設(shè)計(jì)文檔是項(xiàng)目者或管理者的責(zé)任，而項(xiàng)目組或個(gè)人只對(duì)文檔的一小部分負(fù)責(zé)（也就是他們的代碼和注釋。在任何時(shí)候，都可以通過(guò)簡(jiǎn)單地“刷新”文檔生成當(dāng)前的報(bào)告。這樣可以看到程序各部分的情況，也支援了項(xiàng)目組，并為最終用戶文檔提供了直接的更新。這些文檔對(duì)于使新組員盡快參加工作也很有價(jià)值。單個(gè)文檔比由某些分析、設(shè)計(jì)方法而產(chǎn)生的所有文檔更合理。雖然一個(gè)較小的文檔當(dāng)前有大量的形式化方法（不下20種）可用，由程序員選擇[1]。有一些并不完全獨(dú)立，它們有共同的思想基礎(chǔ)，在某個(gè)更上，它們都是相同的。在最低層，很多方法都受語(yǔ)言的缺省表現(xiàn)約束，所以每個(gè)方法大概只能滿足簡(jiǎn)單的項(xiàng)目。真正的好處是在較上，一個(gè)方法可用于實(shí)時(shí)硬件控制器，但可能不容易適合數(shù)據(jù)庫(kù)的設(shè)計(jì)。[1]這些是下綜述：Object ysisandDesign:DescriptionofMethods,editedbyAndrewT.F.HuttofObjectManagementGroup(OMG),johnWiley&Sons,1994。以此來(lái)認(rèn)識(shí)一個(gè)方法是否適合我們的特殊風(fēng)格，或者我們是否真需要一個(gè)方法。下面是對(duì)最流行的三種方法的描述，主要是供參考，不是比較。如果讀者想了解的方法，有許多書Booch方法[1]是最早、最基本和最廣泛被的一個(gè)方法。因?yàn)樗禽^早發(fā)展的，所以對(duì)各這是可預(yù)見的一小步。我們用自然語(yǔ)言問(wèn)題和解，并且確定關(guān)鍵特性，例如形成類的基本名詞。如果我們?cè)谛袠I(yè)，可能想確定工人、鞭、顧客，進(jìn)而，可能需要確定化學(xué)藥劑師、組裝者、處理者，業(yè)余鞭者和專業(yè)鞭者、者和觀眾。甚至更專門的，能確這是在相應(yīng)的抽象層上定義類。如果我們計(jì)劃創(chuàng)建一個(gè)類，我們應(yīng)當(dāng)確定類的相應(yīng)觀眾。例如，如果創(chuàng)建鞭類，那么誰(shuí)將觀察它，化學(xué)藥劑師還是觀眾？前者想知道在結(jié)構(gòu)中有什么化學(xué)藥劑，而后者將對(duì)鞭時(shí)釋放的顏色和形狀感。如果化學(xué)藥劑師問(wèn)起一個(gè)鞭產(chǎn)生主顏色的化學(xué)藥劑，最好不要回答“有點(diǎn)冷綠和紅”。同樣，觀眾會(huì)對(duì)鞭點(diǎn)火后噴出的只是化學(xué)方程式感到迷惑不解。也許，我們的程序是為了眼前的市場(chǎng)，化學(xué)藥劑師和觀眾都會(huì)用它，在這種情況下，鞭應(yīng)當(dāng)有屬性客體屬性并且能以和觀察者相應(yīng)外觀出現(xiàn)。確定它們之間的關(guān)系（CRC卡片（Class,Responsibility,Collaboration,CRC)卡片。這是一種小卡片（通常是一個(gè)索引卡，在它上面寫上這個(gè)類的狀態(tài)變量、它的責(zé)任也就是它發(fā)送和接受的消息）和對(duì)與它互相作用的其他類的。為什么需要索引卡片？理由是我們應(yīng)當(dāng)能在一張小卡片上存放我們需要知道的關(guān)于一個(gè)類的所有內(nèi)容，如果不能滿足這點(diǎn)，那么這個(gè)類就太復(fù)雜了。理想的類應(yīng)一種不涉及主要技術(shù)的解決辦法對(duì)于每個(gè)人都可用的（就像本章前面描述的草稿方法中的文檔結(jié)構(gòu)化一樣。這樣的設(shè)計(jì)過(guò)程給人一種類似著名的程序開發(fā)瀑布流方法的感覺(jué)。現(xiàn)在對(duì)這種方法的看法是有的。在第一遍查看主要的抽象是否可以將類清晰地分離之后，可能需要重復(fù)前三個(gè)步驟。Booch寫了一個(gè)“粗糙旅程完型設(shè)計(jì)過(guò)程”。如果這些類真正反映了這個(gè)解的自然語(yǔ)言描述，那么程序有完型的觀點(diǎn)應(yīng)當(dāng)是可能的。也許要記住的最重要的事情是，通過(guò)缺省—實(shí)際上是通過(guò)定義，如果修改了一個(gè)類，它的超類和子類應(yīng)當(dāng)仍然工作。不需要害怕修改，它不會(huì)/或被改變的這個(gè)類的特定協(xié)作者中。為了這個(gè)類而對(duì)C[1]參看Object-OrientedDesignwithApplicationsbyGradyBooch,BenjaminCummings,1991.有關(guān)C++更新的版責(zé)任驅(qū)動(dòng)的設(shè)計(jì)這個(gè)方法[1]也用CRC卡片。在這里，正如名稱蘊(yùn)涵，卡片的重點(diǎn)在于責(zé)任的，而不是外觀。這可由下面例子說(shuō)明Booch方法可以產(chǎn)生雇員—銀行雇員—銀行經(jīng)理的繼承，而更形式化地說(shuō)，RDD包含如下數(shù)據(jù)或狀態(tài) 對(duì)每個(gè)類的數(shù)據(jù)或狀態(tài)變量的描述池和源 數(shù)據(jù)池和源的標(biāo)識(shí)；處理或產(chǎn)生數(shù)據(jù)的類觀察者或觀點(diǎn) 觀點(diǎn)或觀察者類，用以硬件依賴對(duì)象建模技術(shù)對(duì)象建模技術(shù)[2]（OMT）Booch方法強(qiáng)調(diào)類的功能表現(xiàn)，簡(jiǎn)單地定義它們作為自然語(yǔ)言解的輪廓。RDD進(jìn)了一步，強(qiáng)調(diào)類的責(zé)任超過(guò)強(qiáng)調(diào)類的表現(xiàn)。Booch方法和RDD產(chǎn)生的那些模功能模型，“如何”，數(shù)據(jù)流程表：該功能模型數(shù)據(jù)流。它的理論是，在程序的最如果我們決定采用OOP伙伴開始使用OOP？”想，作為獨(dú)立的程序員，應(yīng)當(dāng)如何學(xué)習(xí)使用新語(yǔ)言和新程序設(shè)計(jì)。正如我們以前所做的，首先訓(xùn)練和做例子，再通過(guò)一個(gè)試驗(yàn)項(xiàng)目得到一個(gè)基本的感覺(jué)，不要做太的事情，然后嘗試做一個(gè)“真實(shí)世界”的實(shí)際有用的項(xiàng)目。在我們的第一個(gè)項(xiàng)目中，我們通過(guò)讀、向上司問(wèn)問(wèn)題、與朋友切磋等方式，繼續(xù)我們的訓(xùn)練?；旧希@就是許多作者建議的從C轉(zhuǎn)到C++的方法。轉(zhuǎn)變整個(gè)公司當(dāng)然應(yīng)當(dāng)采用某個(gè)動(dòng)態(tài)的小組，但回憶個(gè)人是如何做逐步進(jìn)入當(dāng)向OOP和C++轉(zhuǎn)變時(shí)，有一些方針要C代碼上的投資，并且當(dāng)每個(gè)人都在為這些參看DesigningObject-OrientedSoftwarebyRebeccaWirfs-Brocketal.,PrenticeHall,1990參看Object-OrientedModelingandDesignbyJamesRumbaughetal.,PrenticeHall,1991有時(shí)建議采用另法，即在整個(gè)公司層一起訓(xùn)練，包括為策略管理員而開設(shè)的概論課程，以及為項(xiàng)目建設(shè)者而開設(shè)的設(shè)計(jì)課程和編程課程。對(duì)于較小的公司或較大公司的部門，用他們做事情的方法去做基本的改變是非常好的。然而代價(jià)較高，所以一些公司可能選擇以項(xiàng)目層訓(xùn)練開始，做式的項(xiàng)目（可能請(qǐng)一個(gè)外面的導(dǎo)師，然后讓這個(gè)項(xiàng)目變成公司他首先嘗試一個(gè)低風(fēng)險(xiǎn)項(xiàng)目，并允許出錯(cuò)。一旦我們已經(jīng)得到了一些經(jīng)驗(yàn)，我們就將這第一OOP的技術(shù)支柱。第一個(gè)項(xiàng)目可能不能正確工作，所以該項(xiàng)目在事情的安排上應(yīng)當(dāng)不是非常重要的。它應(yīng)當(dāng)是簡(jiǎn)單的、自包含++以適合我們自己的需要。這是設(shè)計(jì)模式[1]的一般概念。轉(zhuǎn)變?yōu)?+的主要經(jīng)濟(jì)動(dòng)機(jī)是容易使用以類庫(kù)形式存在的代碼，最短的應(yīng)用開發(fā)周期是除了main()以外不必自己寫任何東西。然而，一些新程序員不理解這個(gè)，不知道已存在的類庫(kù)，或由于對(duì)語(yǔ)言的迷戀希望寫可能已經(jīng)存在的類。如果我們努力查找和重用其他人在轉(zhuǎn)變過(guò)程中的早期代碼，那么我們?cè)贠OP和C++雖然用C++編譯C代碼通常會(huì)有（有時(shí)是很大的）好處，它能發(fā)現(xiàn)老代碼中的問(wèn)題，但是把時(shí)間花在對(duì)已存在的功能代碼進(jìn)行C++重寫上，通常不是時(shí)間的最佳利用。如果代碼是為重用而編寫的，會(huì)有很大的好處。但是，有可能出現(xiàn)這種情況：在最初的幾個(gè)項(xiàng)目中，并不能看++和OOP好。管理對(duì)于管理員，他的任務(wù)就是為他的組獲得資源，他的小組克服通往成功的。并且，他應(yīng)當(dāng)努力創(chuàng)造高產(chǎn)的和令人愉快的環(huán)境，以使得他的小組最大可能完成他所要求的奇跡。轉(zhuǎn)變到++的過(guò)程包含有下面的三類，如果不花費(fèi)何代價(jià)，那真是奇怪的。雖然對(duì)于C程序員（也許對(duì)于其他過(guò)程語(yǔ)言的程序員）C++比選擇其他OOP語(yǔ)言代價(jià)++些。這個(gè)代價(jià)要比得到C++編譯器大得多。如果投資培訓(xùn)（也許為了指導(dǎo)第一個(gè)項(xiàng)目，并且如果選購(gòu)解決問(wèn)題的類庫(kù)，而不是試圖自己建立這些類庫(kù)，那么可以將中長(zhǎng)期代價(jià)減到最低。這些都是很花錢的，必須在制定計(jì)劃時(shí)充分考慮。另外，當(dāng)學(xué)習(xí)新語(yǔ)言連同程序設(shè)計(jì)環(huán)境時(shí)，[1]參看 etal.,出處同上還會(huì)有損失效率的隱含代價(jià)。培訓(xùn)和指導(dǎo)確實(shí)能使這些代價(jià)降到最低，但是組員們必須克服他們自己的困惑去理解這些問(wèn)題。在這個(gè)過(guò)程中，他們將會(huì)犯的錯(cuò)誤（這是一個(gè)特征，因?yàn)槭∈浅晒χ福┖陀懈偷男省１M管如此，對(duì)于一些類型的程序設(shè)計(jì)問(wèn)題、正確的類和正確的開發(fā)環(huán)境，即使我們還在學(xué)習(xí)++，也可能比我們?nèi)匀挥茫谜Z(yǔ)言時(shí)有更高的效率（即便考慮到我們正在犯的錯(cuò)誤和每天寫更少行的代碼。OOP統(tǒng)的OOPC++是在已有生產(chǎn)程序的情況下設(shè)計(jì)的。當(dāng)我們的焦點(diǎn)是建立快速原型時(shí)，我們可以盡快地把構(gòu)件拉在一起，而忽略效率問(wèn)題。如果我們正在使用任何第庫(kù)，這些庫(kù)通常已經(jīng)被廠商優(yōu)化過(guò)了，我們用快速這就行了。如果達(dá)不到這種要求，我們就開始用一個(gè)有益的工具進(jìn)行調(diào)整，首先尋求加速，這可以通過(guò)簡(jiǎn)單地運(yùn)用建立在C++所以使用特定類的原有代碼不需要改變。只有這一切都無(wú)法解決這個(gè)問(wèn)題時(shí)才需要改變?cè)O(shè)計(jì)。性能在設(shè)計(jì)中的地位如此重要，以致于這一因素必然是主要設(shè)計(jì)標(biāo)準(zhǔn)的指標(biāo)之一。通過(guò)快速原型較早地發(fā)現(xiàn)這一點(diǎn)是有好處的。C和C++1%實(shí)際上我們可以用C得到在規(guī)模和速度上超過(guò)C的系統(tǒng)，因?yàn)槲覀優(yōu)?+當(dāng)項(xiàng)目組開始使用OOP和C++時(shí)，程序員們將會(huì)出現(xiàn)一系列普遍的設(shè)計(jì)錯(cuò)誤。這經(jīng)常會(huì)發(fā)生，因?yàn)樵谠缙陧?xiàng)目的設(shè)計(jì)過(guò)程中從專家們那里得到的反饋太少，公司中沒(méi)有專家。程序員似乎會(huì)覺(jué)得，在這個(gè)周期中，他懂得OOP太早了并開始了一條不好的道路。有時(shí)，對(duì)這個(gè)語(yǔ)言有經(jīng)驗(yàn)的人認(rèn)為顯而易見的事情可能是新手們?cè)趦?nèi)部激烈爭(zhēng)論的。大量的這類問(wèn)題都這一章希望讀者對(duì)面向?qū)ο蟪绦蛟O(shè)計(jì)和C++的廣泛?jiǎn)栴}有一定的感性認(rèn)識(shí)，包括為什么OOP和C++C++是否能很好地C++滿足，那么可以用它研究替代物。即便他最終選擇了C++作為他的語(yǔ)言，他至少應(yīng)當(dāng)懂得這些選項(xiàng)是什么，并應(yīng)當(dāng)對(duì)為什么取這個(gè)方向有清晰的看法。第2 數(shù)據(jù)抽C++是一個(gè)能提高效率的工具。為什么我們還要努力（這是努力，不管我們?cè)噲D做的轉(zhuǎn)變多么容易）使我們從已經(jīng)熟悉且效率高的語(yǔ)言（在這里是語(yǔ)言）轉(zhuǎn)到另一種新的語(yǔ)言上？而且使用這種新語(yǔ)言，我們會(huì)在確實(shí)掌握它之前的一段時(shí)間內(nèi)降低效率。這歸因于我們確信通過(guò)使用新工具將會(huì)得到更大的好處。用程序設(shè)計(jì)術(shù)語(yǔ)，多產(chǎn)意味著用較少的人在較少的時(shí)間內(nèi)完成更復(fù)雜和更重要的程序。然（簡(jiǎn)單地講，提高生產(chǎn)效率，意味著本應(yīng)花費(fèi)三個(gè)人一星期的程序，現(xiàn)在只需要花費(fèi)一個(gè)人一兩天的時(shí)間。這會(huì)涉及到經(jīng)濟(jì)學(xué)的多層次問(wèn)題。生產(chǎn)效率提高了，我們很高興，因?yàn)槲覀冋诮ㄔ斓臇|西功能將會(huì)更強(qiáng)；我們的客戶（或）很高興，因?yàn)楫a(chǎn)品生產(chǎn)又快，用人又少；我們的顧客很高興，因?yàn)樗麄兊玫降漠a(chǎn)品更便宜。而極大提高效率的唯一辦法是使用其他人的代碼，即使用庫(kù)。庫(kù)，簡(jiǎn)單地說(shuō)就是一些人已經(jīng)寫的代碼，按某種方式包裝在一起。通常，最小的包是帶有擴(kuò)展名如LIB的文件和向編譯器庫(kù)中有什么的一個(gè)或多個(gè)頭文件。連接器知道如何在LIB文件中搜索和提取相應(yīng)的已編譯的代碼。但是，這只是提供庫(kù)的法。在多種體系結(jié)構(gòu)的平臺(tái)上，例如UNIX，通常，提供庫(kù)的最明智的方法是用源代碼，這樣在新的目標(biāo)機(jī)上它能被重新編譯。而在微軟indows上，動(dòng)態(tài)連接庫(kù)是最明智的方法，這使得我們能夠利用新發(fā)布的DDL經(jīng)常修改我們的程序，我們的庫(kù)函數(shù)銷售商可能已經(jīng)將新DDL所以，庫(kù)大概是改進(jìn)效率的最重要的方法。C++的主要設(shè)計(jì)目標(biāo)之一是使庫(kù)容易使用。這意味著，在C中使用庫(kù)有。懂得這一點(diǎn)就對(duì)C++設(shè)計(jì)有了初步的了解，從而對(duì)如何使用它 首先，必須知道“”和“定義”之間的區(qū)別，因?yàn)檫@兩個(gè)術(shù)語(yǔ)在全書中會(huì)被確切地使空空間。對(duì)于變量，編譯器確定這個(gè)變量占多少單元，并在內(nèi)存中產(chǎn)生存放它們的空間。對(duì)于函數(shù)，編譯器產(chǎn)生代碼，并為之分配空間。函數(shù)的空間中有一個(gè)由使用不帶參數(shù)表或帶地址操作符的函數(shù)名產(chǎn)生的指針。定義也可以是。如果該編譯器還沒(méi)有看到過(guò)名字A，程序員定義intA，則編譯器馬上常常使用于extern關(guān)鍵字。如果我們只是變量而不是定義它，則要求使用extern。對(duì)于函數(shù)，extern是可選的，不帶函數(shù)體的函數(shù)名連同參數(shù)表或返回值，自動(dòng)地作為一個(gè)intf(float,char);是一個(gè)函數(shù)原型，因?yàn)樗粌H介紹f這個(gè)函數(shù)的名字，而且告訴編譯器這個(gè)函數(shù)有什么樣的參數(shù)和返回值，使得編譯C++要求必須寫出函數(shù)原型，因?yàn)樗黾恿艘粋€(gè)重要的安全層。下面是一些的例子。在函數(shù)時(shí)，參數(shù)名可給出也可不給出。而在定義時(shí)，它們是必需的。這在C語(yǔ)言中確全書中，我們會(huì)注意到，每個(gè)文件的第一行是一個(gè)注釋，它以注釋符開始，后面跟冒號(hào)。greawk”這樣的文本處理工具從代碼文件中提取信息。在第一行中還包含有文件名，因此能在文本和其他文件中查閱這個(gè)文件，本書的代碼磁盤一個(gè)袖珍C一個(gè)小型庫(kù)通常以一組函數(shù)開始，但是，已經(jīng)用過(guò)別的C庫(kù)的程序員知道，這里通常有更多的東西，有比行為、動(dòng)作和函數(shù)的東西。還有一些特性（顏色、重量、紋理、亮度，它們都由數(shù)據(jù)表示。在C語(yǔ)言中，當(dāng)我們處理一組特性時(shí)，可以方便地把它們放在一起，形成一個(gè)struct。特別是，如果我們想表示我們的問(wèn)題空間中的多個(gè)類似的事情，則可以對(duì)每件事情創(chuàng)建這個(gè)truct這樣，在大多數(shù)C庫(kù)中都有一組struct和一組活動(dòng)在這些struct上的函數(shù)?，F(xiàn)在看一個(gè)這樣的例子。假設(shè)有一個(gè)程序設(shè)計(jì)工具，當(dāng)創(chuàng)建時(shí)它的表現(xiàn)像一個(gè)數(shù)組，但它的長(zhǎng)度能在運(yùn)行時(shí)建立。我稱它為tash。在結(jié)構(gòu)內(nèi)部需要這結(jié)構(gòu)時(shí)可以使用個(gè)struct的別名，例如，創(chuàng)建一個(gè)鏈表，需要指向下一個(gè)truct的指針。在Ctypedef。這樣做使得我們能把struct作為一個(gè)新類型處理，并且可以定義這個(gè)structstashA,B,注意，這些函數(shù)用標(biāo)準(zhǔn)C風(fēng)格的函數(shù)原型，標(biāo)準(zhǔn)C風(fēng)格比“老”C風(fēng)格更安全和更storag指針是一個(gè)unsignedchar*這是C編譯器支持的最小的片，盡管在某些機(jī)器tash被設(shè)計(jì)用于存放任何類型的變量，所以void*在這里應(yīng)當(dāng)更合適。然而，我們的目的并不是把它當(dāng)作某個(gè)未知類型的塊處理，而是作為連續(xù)的字節(jié)塊。OBJ或LIB或DDL等）如下：#include給出。這樣做，可以創(chuàng)建不同于這本書 的另外下initialize完成對(duì)structstashstorage指針為零，設(shè)置size指示器也為零，表示初始未被分配add()函數(shù)在stash的下一個(gè)可用位子上插入一個(gè)元素。首先，它檢查是否有可用空間，如果沒(méi)有，它就用后面介紹的inflate()函數(shù)擴(kuò)展空間。因?yàn)榫幾g器并不知道被存放的特定變量的類型（void*），所以我們不能只做賦值，雖然這的確是很方便的事情。代之，須用標(biāo)準(zhǔn)C庫(kù)函數(shù)memcpy()一個(gè)字節(jié)一個(gè)字節(jié)地拷貝這個(gè)變量，第一個(gè)參數(shù)是memcpy()開始拷貝字節(jié)的目的地址，由下面表達(dá)式產(chǎn)&(S->storage[S->next*S-它指示從塊開始的第next個(gè)可用單元結(jié)束。這個(gè)數(shù)實(shí)際上就是已經(jīng)用過(guò)的單元號(hào)加一的計(jì)數(shù)，它必須乘上每個(gè)單元擁有的字節(jié)數(shù)，產(chǎn)生按字節(jié)計(jì)算的偏移量。這不產(chǎn)生地址，而是。器加一，并返回被存值的索引。這樣，程序員可以在后面調(diào)用fetch(時(shí)用它來(lái)取得這個(gè)元素。fetch()首先看索引是否越界，如果沒(méi)有越界，返回所希望的變量地址，地址的計(jì)算采用與對(duì)于有經(jīng)驗(yàn)的程序員count()乍看上去可能有點(diǎn)奇怪，它好像是自找麻煩，做手工很容易structstash，例假設(shè)稱為intStash，那么通過(guò)用intStash.next找出它已經(jīng)有多少個(gè)元素的方法似乎更直接，而不是去做count(intStash)函數(shù)調(diào)用（它有的花費(fèi)stash的內(nèi)部表示和計(jì)數(shù)計(jì)算方法，那么這個(gè)函數(shù)調(diào)用接口就允許必要的靈活性。并且，很多程序員不會(huì)為找出庫(kù)的“更好”的設(shè)計(jì)而操心。如果他們能著眼于struct和直接取next的值，那么可能不經(jīng)允許就改變next。是不是能有一些方法使得庫(kù)設(shè)計(jì)者能更好地控制像這樣的問(wèn)題呢？（是的，這是可預(yù)見的。我們不可能預(yù)先知道一個(gè)stash需要的最大量是多少，所以由torage指向的內(nèi)存從堆中分配。堆是很大的內(nèi)存塊，用以在運(yùn)行時(shí)分一些小單元。在我們寫程序時(shí)，如果我們還不知道所需內(nèi)的大，就以使堆。樣，們可直運(yùn)行時(shí)知道要存放200個(gè)airne變是20。動(dòng)內(nèi)存配函是標(biāo)準(zhǔn)C庫(kù)的一部分，包括malloc()、calloc(、realloc()和 ()。inflate()函數(shù)使用realloc()為tash得到更大的空間塊。realloc()把已經(jīng)分配而又希望重分配的單元首地址作為它的第一個(gè)參數(shù)（如果這個(gè)參數(shù)為零，例如initialize()剛剛被調(diào)用時(shí)，realloc()分配一個(gè)新塊。第二個(gè)參數(shù)是這個(gè)塊新的長(zhǎng)度，如果這個(gè)長(zhǎng)度比原來(lái)的小，這個(gè)塊將不需要作拷貝，簡(jiǎn)單地告訴堆管理器剩下的空間是空閑的。如果這個(gè)長(zhǎng)度比原來(lái)的大，在堆a(bǔ)ssert()檢查以確信這個(gè)操作成（malloc()、calloc()和realloc()）注意，C管器當(dāng)要它內(nèi)塊對(duì)們用 ()時(shí)就回收它們。沒(méi)有對(duì)堆進(jìn)行合并的工具，如果能合并就可以提供更大的空閑塊。如果程序多次分配和釋放堆，最終會(huì)導(dǎo)致這個(gè)堆有大量的空閑塊，但沒(méi)有足夠大且連續(xù)的空間能滿足我們對(duì)內(nèi)存分配的需要。但是，如果用堆合并器動(dòng)內(nèi)存塊，又會(huì)得指針保的不是相應(yīng)的值。一些作環(huán)境，例如aert()是在ASSE.H中的預(yù)處理宏。asert()再調(diào)試時(shí)，我們可以用一個(gè)標(biāo)志使得這個(gè)斷言被忽略。在調(diào)試期間，這是非常清楚和簡(jiǎn)便的測(cè)C程序?qū)σ粋€(gè)斷失敗并且出去”在第17，C++是如何用出錯(cuò)處理來(lái)處理重編譯時(shí)，如果在棧上創(chuàng)建一個(gè)變量那么這個(gè)變量單元由編譯器自動(dòng)開辟和釋放。編譯器準(zhǔn)確地知道需要多少容量，根據(jù)這個(gè)變量的活動(dòng)范圍知道這個(gè)變量的生命期。而對(duì)動(dòng)態(tài)內(nèi)存分配，編譯器知道需要多少單元，不道它們的生命期，不能動(dòng)清除。因此用 ()， ()告訴堆管理器，這個(gè)可以被下一次調(diào)用的malloc()、calloc()或realloc()重用。合理的方法是使用庫(kù)中cleanup()函數(shù)，因?yàn)樵谶@里，該函數(shù)做所有類似的事情。在main()的開頭定義了一些變量，其中包括兩個(gè)stash結(jié)構(gòu)變量，當(dāng)然。稍后須在這個(gè)程序塊的對(duì)它們初始化。庫(kù)的問(wèn)題之一是須向用戶認(rèn)真地說(shuō)明初始化和清除函數(shù)的重要性，如果這些函數(shù)未被調(diào)用，就會(huì)出現(xiàn)許多問(wèn)題。遺憾的是，用戶不總是記得初始化和清除是必須的。他們只知道他們想完成什么，并不關(guān)心我們反復(fù)說(shuō)的：“喂，等一等，您必須首先發(fā)生（只有多預(yù)示。intStash適合于整型，stringStash適合于字符串。這些字符串是通過(guò)打開源代碼文件LIBTEST.C和把這些行讀到stringStash而產(chǎn)生的。注意一些有趣的地方：標(biāo)準(zhǔn)C庫(kù)函數(shù)打開和讀文件所使用的技術(shù)與在stash中使用的技術(shù)類似。fopen()返回一個(gè)指向FILEstruct的指針，這個(gè)FILEstruct是在堆上創(chuàng)建的，并且能將這個(gè)指針傳給涉及到這個(gè)文件的任何函數(shù)。（在這里是fgets()。fclose()所做的事情之一是向堆釋放這個(gè)FILEstruct。一旦我們開始注意到這種模式的，包含著struct和有關(guān)函數(shù)的C庫(kù)后，我們就能到處看到它。裝載了這兩個(gè)stash之后，可以打印出它們。intStach的打印用一個(gè)for循環(huán)，用count()確定它的限度。stringStash的打印用一個(gè)while語(yǔ)句，如果fetch()返回零則表示打印越界,這時(shí)跳出循C庫(kù)創(chuàng)建的問(wèn)題之前，應(yīng)當(dāng)了解另外一些事情（我們可能已經(jīng)知道這些，C。第一，雖然這里用頭文件，而且實(shí)際上用得很好，但它們不是必須的。在C中可能會(huì)調(diào)用還未的函數(shù)。好的編譯器會(huì)告誡我們應(yīng)當(dāng)首先函數(shù)，但不強(qiáng)迫這樣做。這很的，為編器能設(shè)以int參數(shù)調(diào)用的函數(shù)有包含int的參數(shù)表，并據(jù)此處理它，這是很難發(fā)現(xiàn)的錯(cuò)誤。LIB.Hstash的所有文件中，因?yàn)榫幾g器不可能猜出這個(gè)結(jié)構(gòu)是什么樣子的。它能猜出函數(shù)，即便它可能不應(yīng)當(dāng)這樣，但這是C的一部分。每個(gè)獨(dú)立的文件就是一個(gè)處理單元。就是說(shuō)，編譯器在每個(gè)處理單元上單獨(dú)運(yùn)行，而編譯器在運(yùn)行時(shí)只知道這個(gè)單元。這樣，用包含頭文件提供信息是相當(dāng)重要的，因?yàn)樗鼮榫幾g器提供了對(duì)程序其他部分的理解。在頭文件中的特別重要，因?yàn)闊o(wú)論是在哪里包含這個(gè)頭文件，編器都知道做什。例，若一個(gè)文中voidfoo(float)，編譯器就知道，如果我們用整型參數(shù)調(diào)用它，它會(huì)自動(dòng)把int轉(zhuǎn)變?yōu)閒loa。如果沒(méi)有，這個(gè)編譯器就會(huì)簡(jiǎn)單地猜測(cè)，有一個(gè)函數(shù)存在，而不會(huì)做這個(gè)轉(zhuǎn)變。對(duì)于每個(gè)處理單元，編譯器創(chuàng)建一個(gè)目標(biāo)文件，帶有擴(kuò)展名.o或.bj或類似的名字。必須再用連接器將這些目標(biāo)文件連同必要的啟動(dòng)代碼連接成可執(zhí)行程序。在連接期間，所有的外部必須定。如在LIBTESC中并用數(shù)initialize()和fetch()，(也是，編譯器知它們像什么，)在LIB.C中定義的,在LIBTES.C中這些調(diào)用都是外部。連接器將目標(biāo)文連接在一時(shí)，它找出未確定的并尋找這些引要識(shí)在C中，就是函數(shù)名，通常在它們前面加上下劃線。所以，連接器所要做的就是讓被調(diào)用的函數(shù)名與在目標(biāo)文件中的函數(shù)體匹配起來(lái)。如果我們偶然做了一個(gè)調(diào)用，編譯器解釋為foo(int)，而在其他目標(biāo)文件中有foo(float)的函數(shù)體，連接器將認(rèn)為一個(gè)_fo在一處而另一個(gè)_foo在另一處，它會(huì)認(rèn)為這都是對(duì)的。在調(diào)用foo()處將一個(gè)int而foo()float。如果這個(gè)函數(shù)只讀這個(gè)值而不對(duì)它寫，尚不會(huì)破壞這個(gè)棧。但從這個(gè)棧中讀出的float值可能會(huì)有另外的某種理解。這是的情況，因?yàn)楹芊謩e編譯時(shí)（把代碼分成多個(gè)處理單元，我們需要一些方法去編譯所有的代碼，并告訴連接器把它們與相應(yīng)的庫(kù)和啟動(dòng)代碼放在一起，形成一個(gè)可執(zhí)行文件。大部分編譯器允許用一條命令行語(yǔ)句。例如編譯器命名為cpp，可寫:cpplibtest.c這個(gè)方法帶來(lái)的問(wèn)題是，編譯器必須首先編譯每個(gè)處理單元，而不管這個(gè)單元是否需要重建。雖然我們只改變了一個(gè)文件，但卻需要耗費(fèi)時(shí)間來(lái)對(duì)項(xiàng)目中的每一個(gè)文件進(jìn)行重新編譯。UNIX（Ｃ的誕生地）提出，是一個(gè)被稱為make的程序。make比較源代碼文件的日期和目標(biāo)文件的日期，如果目標(biāo)文件的日期比源代碼文件的早，ake這器元理可譯檔1]中學(xué)到的關(guān)于maemaemakefile有點(diǎn)乏味。makefile是描述項(xiàng)目中所有文件之間關(guān)系的文本文件因此，編譯銷售商們自的項(xiàng)目創(chuàng)建工具這些工具向們?cè)儐?wèn)項(xiàng)目中有哪些處理單元，并確定它們的關(guān)系。這些關(guān)系有些類似于makefil文件，通常稱為項(xiàng)目文件。程序設(shè)計(jì)境這個(gè)件，所以我不必它擔(dān)心。項(xiàng)目文的配置和使隨系統(tǒng)而文檔（雖然由編譯器銷售商提供的項(xiàng)目文件工具通常是非常簡(jiǎn)單的，可以不費(fèi)勁地學(xué)會(huì)它們。應(yīng)注的一問(wèn)文命。在中，慣例是以擴(kuò)展名.命名文件包含），以.c（C繼續(xù)演化。它首先是在ix.H和.C-SC.hxx和.cx還是cp.。stashC程序[1]參看由作者編寫的C++Inside&Out,(Osborne/McGraw-Hill,1993)須向這個(gè)庫(kù)中的每一個(gè)函數(shù)傳遞這個(gè)結(jié)構(gòu)的地址。而當(dāng)讀這些代碼時(shí)，這種庫(kù)機(jī)制會(huì)和函數(shù)調(diào)用的含義相，試圖理解這些代碼時(shí)也會(huì)引起。然而在C中，使用庫(kù)的最大的是名字問(wèn)題。C對(duì)于函數(shù)使用單個(gè)名字空間，所以現(xiàn)在假設(shè)要支持從不同的廠商的兩個(gè)庫(kù)，并且每個(gè)庫(kù)都有一個(gè)必須被初始化和清除的結(jié)構(gòu)。兩個(gè)廠商都認(rèn)為initialize()和cleanup()是好名字。如果在某個(gè)處理單元中同時(shí)包含了這，C編器呢，準(zhǔn)C給一個(gè)出錯(cuò)，告訴在函數(shù)的兩個(gè)不同的參數(shù)表中類型不匹配。即便不把它們包含在同一個(gè)處理單元中，連接器也會(huì)有問(wèn)題。好的連接器會(huì)發(fā)現(xiàn)這里有名字，但有些編譯器僅僅通過(guò)查找目標(biāo)文件表，按照在連接表中給出的次序，取第一個(gè)找到的函數(shù)名（實(shí)際上，這可以看作是一種功能，因?yàn)榭梢杂米约旱陌姹咎鎿Q一個(gè)庫(kù)函數(shù)。C庫(kù)廠商常常會(huì)在它們的所有函數(shù)名前加上一個(gè)獨(dú)特字符串。所以，initialize()和cleanup()可能變?yōu)閟tash_initialize()和stash_cleanup()。這是合乎邏輯的，因?yàn)樗胺纸饬恕边@個(gè)struct的名字，++rut突。而當(dāng)一些函數(shù)在特定struct上運(yùn)算時(shí)，為什么不把這一優(yōu)點(diǎn)擴(kuò)展到這些函數(shù)名上呢？也就truct首先注意到的可能是新的注釋文法CC原來(lái)的注釋文法仍然能用。C++注釋直到該行的結(jié)尾，它有時(shí)非常方便。另外，我們會(huì)在這本書中，在文件的第一行的//之后加一個(gè)冒號(hào)，后面跟的是這個(gè)文件名和簡(jiǎn)要描述。這就可以了解代碼所在的文件。構(gòu)名轉(zhuǎn)變?yōu)檫@個(gè)程序的新類型名（就像int、char、float、double一樣。stash的用法仍然相同。所有的數(shù)據(jù)成員與以前完全相同，但現(xiàn)在這些函數(shù)在struct的內(nèi)部了。另外，注意到，對(duì)C版本中第一個(gè)參數(shù)已經(jīng)去掉了。在C++在這個(gè)結(jié)構(gòu)上運(yùn)算的所有函數(shù)的一個(gè)參數(shù)，而是編譯器背地里做了這件事?，F(xiàn)在，這些函數(shù)僅有的參數(shù)與這些函數(shù)所做的事情有關(guān)，而不與這些函數(shù)運(yùn)算的機(jī)制有關(guān)。C庫(kù)中的那些同樣有效，是很重要的。參數(shù)的個(gè)數(shù)是相同的（即stashA,B,)被產(chǎn)生的代碼幾乎和我們已經(jīng)為C庫(kù)寫的一樣。有趣的是，這同時(shí)就包括了為過(guò)程stah_initialize()、stah_cleanup()tuttahinitialize()initialize()相抵觸。大部分時(shí)間都不必為函數(shù)名字分解而擔(dān)心—即使使用未分解的函數(shù)名。但有時(shí)還必須能夠這個(gè)initialize()個(gè)structtash