計(jì)算機(jī)專業(yè)外文翻譯--- p2p信任模型

1、<p>　　畢業(yè)論文（設(shè)計(jì)）外文翻譯</p><p>　　題 目： 基于C++局域網(wǎng)聊天系統(tǒng) </p><p>　　學(xué) 院： 數(shù)理與信息學(xué)院 </p><p>　　學(xué)生姓名： </p><p>　　專 業(yè)

2、： 計(jì)算機(jī)科學(xué)與技術(shù) </p><p>　　班 級(jí)： A07計(jì)算機(jī) </p><p>　　指導(dǎo)教師： </p><p>　　起止日期： 2011.3.29至2011.6.18 </p><p>&l

3、t;b>　　2011年4月6日</b></p><p><b>　　Paper1</b></p><p>　　P2P trust model</p><p>　　Summary of the P2P network problems are analyzed, described the establishment of P2

4、P network trust model needs.P2P network on the existing trust models are summarized, pointing out the direction of future research.IntroductionWith the Internet's widespread popularity, the rich end user's syst

5、em resources, as well as the rapid increase in network bandwidth, the traditional Client / Server Network Application Mode server performance bottlenecks and single point of failure issue is not only limit</p><

6、;p>　　《Journal of Harbin Institute of Technology》</p><p><b>　　Paper2</b></p><p>　　Object landscapes and lifetimes</p><p>　　Technically, OOP is just about abstract data

7、 typing, inheritance, and polymorphism, but other issues can be at least as important. The remainder of this section will cover these issues. </p><p>　　One of the most important factors is the way objects ar

8、e created and destroyed. Where is the data for an object and how is the lifetime of the object controlled? There are different philosophies at work here. C++ takes the approach that control of efficiency is the most impo

9、rtant issue, so it gives the programmer a choice. For maximum run-time speed, the storage and lifetime can be determined while the program is being written, by placing the objects on the stack (these are sometimes called

10、 auto</p><p>　　The second approach is to create objects dynamically in a pool of memory called the heap. In this approach, you don't know until run-time how many objects you need, what their lifetime is,

11、 or what their exact type is. Those are determined at the spur of the moment while the program is running. If you need a new object, you simply make it on the heap at the point that you need it. Because the storage is ma

12、naged dynamically, at run-time, the amount of time required to allocate storage on the heap </p><p>　　Java uses the second approach, exclusively]. Every time you want to create an object, you use the new key

13、word to build a dynamic instance of that object. </p><p>　　There's another issue, however, and that's the lifetime of an object. With languages that allow objects to be created on the stack, the comp

14、iler determines how long the object lasts and can automatically destroy it. However, if you create it on the heap the compiler has no knowledge of its lifetime. In a language like C++, you must determine programmatically

15、 when to destroy the object, which can lead to memory leaks if you don’t do it correctly (and this is a common problem in C++ programs). Jav</p><p>　　The rest of this section looks at additional factors conc

16、erning object lifetimes and landscapes. </p><p>　　Collections and iterators</p><p>　　If you don’t know how many objects you’re going to need to solve a particular problem, or how long they will

17、last, you also don’t know how to store those objects. How can you know how much space to create for those objects? You can’t, since that information isn’t known until run-time. </p><p>　　The solution to most

18、 problems in object-oriented design seems flippant: you create another type of object. The new type of object that solves this particular problem holds references to other objects. Of course, you can do the same thing wi

19、th an array, which is available in most languages. But there’s more. This new object, generally called a container (also called a collection, but the Java library uses that term in a different sense so this book will use

20、 “container”), will expand itself whenev</p><p>　　Fortunately, a good OOP language comes with a set of containers as part of the package. In C++, it’s part of the Standard C++ Library and is sometimes called

21、 the Standard Template Library (STL). Object Pascal has containers in its Visual Component Library (VCL). Smalltalk has a very complete set of containers. Java also has containers in its standard library. In some librari

22、es, a generic container is considered good enough for all needs, and in others (Java, for example) the library has differen</p><p>　　All containers have some way to put things in and get things out; there ar

23、e usually functions to add elements to a container, and others to fetch those elements back out. But fetching elements can be more problematic, because a single-selection function is restrictive. What if you want to mani

24、pulate or compare a set of elements in the container instead of just one? </p><p>　　The solution is an iterator, which is an object whose job is to select the elements within a container and present them to

25、the user of the iterator. As a class, it also provides a level of abstraction. This abstraction can be used to separate the details of the container from the code that’s accessing that container. The container, via the i

26、terator, is abstracted to be simply a sequence. The iterator allows you to traverse that sequence without worrying about the underlying structure—that is, wh</p><p>　　From a design standpoint, all you really

27、 want is a sequence that can be manipulated to solve your problem. If a single type of sequence satisfied all of your needs, there’d be no reason to have different kinds. There are two reasons that you need a choice of c

28、ontainers. First, containers provide different types of interfaces and external behavior. A stack has a different interface and behavior than that of a queue, which is different from that of a set or a list. One of these

29、 might provide a mor</p><p>　　In the end, remember that a container is only a storage cabinet to put objects in. If that cabinet solves all of your needs, it doesn’t really matter how it is implemented (a ba

30、sic concept with most types of objects). If you’re working in a programming environment that has built-in overhead due to other factors, then the cost difference between an ArrayList and a LinkedList might not matter. Yo

31、u might need only one type of sequence. You can even imagine the “perfect” container abstraction, which</p><p>　　The singly rooted hierarchy</p><p>　　One of the issues in OOP that has become esp

32、ecially prominent since the introduction of C++ is whether all classes should ultimately be inherited from a single base class. In Java (as with virtually all other OOP languages) the answer is “yes” and the name of this

33、 ultimate base class is simply Object. It turns out that the benefits of the singly rooted hierarchy are many. </p><p>　　All objects in a singly rooted hierarchy have an interface in common, so they are all

34、ultimately the same type. The alternative (provided by C++) is that you don’t know that everything is the same fundamental type. From a backward-compatibility standpoint this fits the model of C better and can be thought

35、 of as less restrictive, but when you want to do full-on object-oriented programming you must then build your own hierarchy to provide the same convenience that’s built into other OOP languages.</p><p>　　All

36、 objects in a singly rooted hierarchy (such as Java provides) can be guaranteed to have certain functionality. You know you can perform certain basic operations on every object in your system. A singly rooted hierarchy,

37、along with creating all objects on the heap, greatly simplifies argument passing (one of the more complex topics in C++). </p><p>　　A singly rooted hierarchy makes it much easier to implement a garbage colle

38、ctor (which is conveniently built into Java). The necessary support can be installed in the base class, and the garbage collector can thus send the appropriate messages to every object in the system. Without a singly roo

39、ted hierarchy and a system to manipulate an object via a reference, it is difficult to implement a garbage collector. </p><p>　　Since run-time type information is guaranteed to be in all objects, you’ll neve

40、r end up with an object whose type you cannot determine. This is especially important with system level operations, such as exception handling, and to allow greater flexibility in programming. </p><p>　　Coll

41、ection libraries and support for easy collection use</p><p>　　Because a container is a tool that you’ll use frequently, it makes sense to have a library of containers that are built in a reusable fashion, so

42、 you can take one off the shelf Because a container is a tool that you’ll use frequently, it makes sense to have a library of containers that are built in a reusable fashion, so you can take one off the shelf and plug it

43、 into your program. Java provides such a library, which should satisfy most needs. </p><p>　　Downcasting vs. templates/generics</p><p>　　To make these containers reusable, they hold the one univ

44、ersal type in Java that was previously mentioned: Object. The singly rooted hierarchy means that everything is an Object, so a container that holds Objects can hold anything. This makes containers easy to reuse. </p&g

45、t;<p>　　To use such a container, you simply add object references to it, and later ask for them back. But, since the container holds only Objects, when you add your object reference into the container it is upcast

46、 to Object, thus losing its identity. When you fetch it back, you get an Object reference, and not a reference to the type that you put in. So how do you turn it back into something that has the useful interface of the o

47、bject that you put into the container? </p><p>　　Here, the cast is used again, but this time you’re not casting up the inheritance hierarchy to a more general type, you cast down the hierarchy to a more spec

48、ific type. This manner of casting is called downcasting. With upcasting, you know, for example, that a Circle is a type of Shape so it’s safe to upcast, but you don’t know that an Object is necessarily a Circle or a Shap

49、e so it’s hardly safe to downcast unless you know that’s what you’re dealing with. </p><p>　　It’s not completely dangerous, however, because if you downcast to the wrong thing you’ll get a run-time error cal

50、led an exception, which will be described shortly. When you fetch object references from a container, though, you must have some way to remember exactly what they are so you can perform a proper downcast. </p><

51、;p>　　Downcasting and the run-time checks require extra time for the running program, and extra effort from the programmer. Wouldn’t it make sense to somehow create the container so that it knows the types that it hold

52、s, eliminating the need for the downcast and a possible mistake? The solution is parameterized types, which are classes that the compiler can automatically customize to work with particular types. For example, with a par

53、ameterized container, the compiler could customize that container so</p><p>　　Parameterized types are an important part of C++, partly because C++ has no singly rooted hierarchy. In C++, the keyword that imp

54、lements parameterized types is “template.” Java currently has no parameterized types since it is possible for it to get by—however awkwardly—using the singly rooted hierarchy. However, a current proposal for parameterize

55、d types uses a syntax that is strikingly similar to C++ templates. </p><p>　　http://www.studyems.com/</p><p><b>　　Paper 1翻譯</b></p><p><b>　　p2p信任模型</b></p

56、><p>　　對(duì)P2P網(wǎng)絡(luò)存在的問(wèn)題進(jìn)行了分析，闡述了建立P2P網(wǎng)絡(luò)信任模型的需求。在對(duì)現(xiàn)有P2P網(wǎng)絡(luò)中的信任模型進(jìn)行總結(jié)歸納后，指出了以后研究的方向。</p><p>　　引言:隨著Internet的廣泛普及，端用戶系統(tǒng)資源的豐富，以及網(wǎng)絡(luò)帶寬的快速增加，傳統(tǒng)的Client/Server網(wǎng)絡(luò)應(yīng)用模式中服務(wù)器的性能瓶頸以及單點(diǎn)失效的問(wèn)題不僅限制了端系統(tǒng)資源的充分利用，同時(shí)也越來(lái)越無(wú)法滿足新的分

57、布式應(yīng)用的需求。而P2P網(wǎng)絡(luò)在協(xié)同工作、分布式信息共享、大規(guī)模并行計(jì)算等方面顯示出的獨(dú)特優(yōu)勢(shì)，使其成為新的發(fā)展熱點(diǎn)。P2P網(wǎng)絡(luò)是基于節(jié)點(diǎn)愿意共享資源這一基本假設(shè)的，即每個(gè)節(jié)點(diǎn)共享自己的資源，并從其他節(jié)點(diǎn)那里獲取自己需要的資源。然而，這種個(gè)人為公眾提供資源，且節(jié)點(diǎn)行為無(wú)約束的工作模式導(dǎo)致P2P網(wǎng)絡(luò)存在三個(gè)問(wèn)題。（1）搭便車（Free-Riding）問(wèn)題Free-Rriding指節(jié)點(diǎn)只消費(fèi)其他節(jié)點(diǎn)貢獻(xiàn)的資源，而不共享自己的資源。以Gnu

58、tella P2P文件共享系統(tǒng)為例，70%的節(jié)點(diǎn)是Free-Rider。最新的監(jiān)測(cè)也表明在eDonkey文件共享網(wǎng)絡(luò)中，大約有80%的節(jié)點(diǎn)是Free-Rider。（2）“公共物品的悲哀”（the Tragedy of the Commons）問(wèn)題“公共物品的悲哀”指網(wǎng)絡(luò)資源作為一種非排他的公共資源，被大多數(shù)P2P節(jié)點(diǎn)無(wú)節(jié)制地使用，據(jù)</p><p><b>　　為什么是信任模型</b>&

59、lt;/p><p>　　在節(jié)點(diǎn)具有自主權(quán)利，自組織的P2P網(wǎng)絡(luò)中，如何來(lái)規(guī)范節(jié)點(diǎn)的行為呢?事實(shí)上，P2P網(wǎng)絡(luò)提供了真實(shí)世界中人類交流的網(wǎng)絡(luò)環(huán)境，是以人為中心的網(wǎng)絡(luò)，與社會(huì)網(wǎng)絡(luò)具有同構(gòu)性。而信任作為社會(huì)存在的一個(gè)整體部分，是社會(huì)網(wǎng)絡(luò)中人與人之間的核心關(guān)系。人類社會(huì)通過(guò)基于信譽(yù)的信任關(guān)系與激勵(lì)機(jī)制來(lái)約束人們的日常生活行為?；谛湃蔚腜2P網(wǎng)絡(luò)與人類社會(huì)網(wǎng)絡(luò)的相似性體現(xiàn)在P2P網(wǎng)絡(luò)中個(gè)體之間的彼此交互會(huì)為彼此留下零星的“信

60、用”信息；個(gè)體對(duì)交互對(duì)象具有充分的選擇權(quán)利；個(gè)體往往不看重絕對(duì)的可靠性或服務(wù)質(zhì)量，即個(gè)體可以忍受少量錯(cuò)誤的選擇帶來(lái)的損失，比如文件共享應(yīng)用；個(gè)體有義務(wù)為網(wǎng)絡(luò)中的其它個(gè)體提供推薦信息。因此，可以利用信任關(guān)系刻畫(huà)P2P網(wǎng)絡(luò)中節(jié)點(diǎn)之間的關(guān)系，并采取基于信任的激勵(lì)機(jī)制解決上述問(wèn)題。（1）基于信任值提供區(qū)分服務(wù)在文件共享P2P網(wǎng)絡(luò)中，可以根據(jù)節(jié)點(diǎn)對(duì)網(wǎng)絡(luò)資源的貢獻(xiàn)程度，提供區(qū)分服務(wù)。例如，Kazaa將節(jié)點(diǎn)提供的資源與消耗資源的比值作為節(jié)點(diǎn)參與到

61、系統(tǒng)中的等級(jí)，并將其作為節(jié)點(diǎn)享受服務(wù)的優(yōu)先級(jí)。BitTorrent中節(jié)點(diǎn)根據(jù)對(duì)方上傳的速率決定自己上傳的速率。在eDonkey網(wǎng)絡(luò)中節(jié)點(diǎn)根據(jù)本地信任值來(lái)設(shè)定請(qǐng)求節(jié)點(diǎn)</p><p><b>　　信任的概念</b></p><p>　　信任是一個(gè)多學(xué)科的概念，描述了在特定的情境下，一個(gè)個(gè)體在可能帶來(lái)不利后果的情況下，愿意相信另一個(gè)個(gè)體具有某種能力或能夠完成某項(xiàng)任務(wù)的主觀

62、信念。與信任緊密聯(lián)系的概念是信譽(yù)，信譽(yù)來(lái)自個(gè)體的社會(huì)網(wǎng)絡(luò)中，是基于觀察到的個(gè)體過(guò)去行為或過(guò)去行為的信息而對(duì)個(gè)體行為的期望。信譽(yù)和信任之間的差別可以用我信任你因?yàn)槟阌泻玫男抛u(yù)或我信任你盡管你的信譽(yù)不好來(lái)說(shuō)明。由此可見(jiàn)，信譽(yù)強(qiáng)調(diào)的是一個(gè)群體對(duì)某一個(gè)體或群體的共同的可信賴度，而信任更多強(qiáng)調(diào)的是信任個(gè)體對(duì)被信任方的主觀信賴。在本文中所提及的信任指的是信任方對(duì)被信任方的主觀信任，即信任方根據(jù)自己的經(jīng)驗(yàn)或同時(shí)參考被信任方的信譽(yù)而得出的被信任方的可信

63、賴程度。在資源共享的P2P網(wǎng)絡(luò)中，體現(xiàn)節(jié)點(diǎn)可信賴程度的不僅包括節(jié)點(diǎn)的諸如計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)帶寬等方面的客觀能力，同時(shí)與節(jié)點(diǎn)參與到P2P網(wǎng)絡(luò)中的行為特征相關(guān)，例如節(jié)點(diǎn)的在線時(shí)長(zhǎng)、友好程度等。在電子商務(wù)類的P2P網(wǎng)絡(luò)中，賣家的可信賴程度與商品說(shuō)明、與買家的溝通、運(yùn)送時(shí)間、運(yùn)送及手續(xù)費(fèi)等相關(guān)。在實(shí)際的應(yīng)用系統(tǒng)中，將所有影響節(jié)點(diǎn)可信度的信任因素進(jìn)行量化并綜合得出節(jié)點(diǎn)的可信度并不可行。因此，一般情況下，在P2P網(wǎng)絡(luò)的信任模型中，根據(jù)</p&g

64、t;<p>　　信譽(yù)、信任與互惠的關(guān)系</p><p>　　正如社會(huì)領(lǐng)域，只有當(dāng)過(guò)去的行為對(duì)未來(lái)有影響時(shí)（社會(huì)學(xué)稱之為“未來(lái)陰影（Shadow of Future）”現(xiàn)象），人們才有動(dòng)機(jī)去建立彼此間的信任關(guān)系。因此，信任模型與激勵(lì)機(jī)制之間具有良好的互動(dòng)關(guān)系，可以有效促進(jìn)P2P網(wǎng)絡(luò)中節(jié)點(diǎn)之間的合作。</p><p><b>　　信任模型分類</b><

65、/p><p>　　在P2P網(wǎng)絡(luò)中，存在著各種各樣的攻擊模型，包括：欺詐、假冒、詆毀、聯(lián)合欺詐、具有前端節(jié)點(diǎn)（前端節(jié)點(diǎn)一般提供可靠的服務(wù)，對(duì)合作節(jié)點(diǎn)給予公正的評(píng)價(jià)。但這些前端節(jié)點(diǎn)試圖通過(guò)給予集團(tuán)內(nèi)部惡意節(jié)點(diǎn)高的正面評(píng)價(jià)來(lái)掩飾惡意節(jié)點(diǎn)的行為）的聯(lián)合欺詐、節(jié)點(diǎn)改變ID重新進(jìn)入網(wǎng)絡(luò)以及節(jié)點(diǎn)間歇性地提供不可信信息和服務(wù)，或是累積信譽(yù)到了一定高度時(shí)，利用其較高的信任值，進(jìn)行詐騙、詆毀或聯(lián)合欺詐等攻擊行為。目前的信任模型大多集中于

66、解決某幾類攻擊問(wèn)題，根據(jù)建立信任關(guān)系的方法，大致可分為基于可信第三方的信任模型和基于反饋/評(píng)價(jià)的信任模型兩類。</p><p>　　基于可信第三方的信任模型</p><p>　　這類信任模型采用傳統(tǒng)安全體系中的PKI技術(shù)，通過(guò)網(wǎng)絡(luò)中的少數(shù)領(lǐng)袖節(jié)點(diǎn)來(lái)監(jiān)督整個(gè)網(wǎng)絡(luò)的運(yùn)行情況，并定期通告違規(guī)節(jié)點(diǎn)或?qū)ζ溥M(jìn)行處罰。這些領(lǐng)袖節(jié)點(diǎn)的合法性通過(guò)CA頒發(fā)的證書(shū)加以保證。這類系統(tǒng)往往依賴于少量中心節(jié)點(diǎn)，因此存

67、在單點(diǎn)失效、以及可擴(kuò)展性的問(wèn)題。</p><p>　　基于反饋/評(píng)價(jià)的信任模型</p><p>　　P2P網(wǎng)絡(luò)中的信任模型大都屬于此類，根據(jù)被信任客體的不同，存在為資源建立可信度和為交易節(jié)點(diǎn)建立可信度兩大類。前者關(guān)注于P2P網(wǎng)絡(luò)中可獲取信息的可信度，與信息提供者的可信度并不建立直接聯(lián)系。在這類信任模型中，節(jié)點(diǎn)對(duì)信息的可靠性進(jìn)行判定，并給出正面或負(fù)面的反饋評(píng)價(jià)，并進(jìn)一步計(jì)算其信任值。例如，在

68、文件共享應(yīng)用Kazaa中，只考慮正面的反饋，采取數(shù)據(jù)簽名的方式來(lái)建立可信度，即如果用戶認(rèn)可信息的真實(shí)性，則進(jìn)行簽名，信息獲得的簽名越多，其真實(shí)性越高。這種為資源建立可信度的信任模型局限于信息共享的應(yīng)用，不具有廣泛的適用性。下文針對(duì)為交易節(jié)點(diǎn)建立可信度的信任模型進(jìn)行說(shuō)明。（1）全局信任模型這類信任模型對(duì)網(wǎng)絡(luò)中所有交易反饋進(jìn)行分析并為每個(gè)節(jié)點(diǎn)建立惟一的可信度。全球最大的拍賣網(wǎng)站eBay通過(guò)交易結(jié)束后，交易雙方分別給出正面、負(fù)面或中立的

69、反饋評(píng)價(jià)，并利用正面評(píng)價(jià)數(shù)減去負(fù)面評(píng)價(jià)數(shù)得出某個(gè)體的信譽(yù)。該方法簡(jiǎn)單易理解，但無(wú)法處理交易者給出的不公正的反饋。S.Kamvar提出的全局信任模型EigenTrust根據(jù)節(jié)點(diǎn)的交易歷史，計(jì)算本地的信任度，并考慮節(jié)點(diǎn)的推薦信任信息，通過(guò)節(jié)點(diǎn)間信任度的迭代來(lái)實(shí)現(xiàn)信任的傳播</p><p><b>　　結(jié)束語(yǔ)</b></p><p>　　在沒(méi)有有效管理機(jī)制的P2P網(wǎng)絡(luò)中，建

70、立能夠抑制所有攻擊模式的信任模型是非常困難的，除了要能夠抑制節(jié)點(diǎn)的攻擊外，在建立信任模型的時(shí)候，要充分考慮信任模型是否具有規(guī)?？蓴U(kuò)展性，在信任計(jì)算以及信任信息存儲(chǔ)方面的可擴(kuò)展性，以及信任信息傳播過(guò)程中的帶寬開(kāi)銷問(wèn)題。此外，在節(jié)點(diǎn)動(dòng)態(tài)進(jìn)出網(wǎng)絡(luò)頻繁的情況下，信任模型的容錯(cuò)性或健壯性也是需要特別強(qiáng)調(diào)的。事實(shí)上，在P2P網(wǎng)絡(luò)信任模型的研究方面，應(yīng)充分借鑒真實(shí)社會(huì)的信譽(yù)管理體制，針對(duì)交易發(fā)生的不同場(chǎng)景為節(jié)點(diǎn)建立可信度，并將節(jié)點(diǎn)納入到特定的群體來(lái)

71、約束和規(guī)范節(jié)點(diǎn)的行為。因此，基于群組的信譽(yù)機(jī)制是以后研究的方向，已有研究工作在該方面進(jìn)行了有益的探索，但仍不成熟。此外，在研究基于信任模型的激勵(lì)機(jī)制時(shí)，不僅要考慮P2P網(wǎng)絡(luò)內(nèi)部節(jié)點(diǎn)之間的合作，也應(yīng)考慮P2P應(yīng)用與網(wǎng)絡(luò)中其他應(yīng)用之間的合作。例如，在文件共享P2P應(yīng)用中，當(dāng)網(wǎng)絡(luò)帶寬利用率達(dá)到某一閾值時(shí)，對(duì)仍然掠奪性使用網(wǎng)絡(luò)資源的節(jié)點(diǎn)進(jìn)行懲罰。P2P應(yīng)用與網(wǎng)絡(luò)中其他應(yīng)用的和諧共存，才是P2P應(yīng)用發(fā)展的長(zhǎng)久之道。</p><

72、p>　　《Journal of Harbin Institute of Technology》</p><p><b>　　Paper 2翻譯</b></p><p>　　對(duì)象的創(chuàng)建和存在時(shí)間</p><p>　　從技術(shù)角度說(shuō)，OOP（面向?qū)ο蟪绦蛟O(shè)計(jì)）只是涉及抽象的數(shù)據(jù)類型、繼承以及多形性，但另一些問(wèn)題也可能顯得非常重要。本節(jié)將就這些問(wèn)

73、題進(jìn)行探討。</p><p>　　最重要的問(wèn)題之一是對(duì)象的創(chuàng)建及破壞方式。對(duì)象需要的數(shù)據(jù)位于哪兒，如何控制對(duì)象的“存在時(shí)間”呢？針對(duì)這個(gè)問(wèn)題，解決的方案是各異其趣的。C++認(rèn)為程序的執(zhí)行效率是最重要的一個(gè)問(wèn)題，所以它允許程序員作出選擇。為獲得最快的運(yùn)行速度，存儲(chǔ)以及存在時(shí)間可在編寫(xiě)程序時(shí)決定，只需將對(duì)象放置在堆棧（有時(shí)也叫作自動(dòng)或定域變量）或者靜態(tài)存儲(chǔ)區(qū)域即可。這樣便為存儲(chǔ)空間的分配和釋放提供了一個(gè)優(yōu)先級(jí)。某些情

74、況下，這種優(yōu)先級(jí)的控制是非常有價(jià)值的。然而，我們同時(shí)也犧牲了靈活性，因?yàn)樵诰帉?xiě)程序時(shí)，必須知道對(duì)象的準(zhǔn)確的數(shù)量、存在時(shí)間、以及類型。如果要解決的是一個(gè)較常規(guī)的問(wèn)題，如計(jì)算機(jī)輔助設(shè)計(jì)、倉(cāng)儲(chǔ)管理或者空中交通控制，這一方法就顯得太局限了。</p><p>　　第二個(gè)方法是在一個(gè)內(nèi)存池中動(dòng)態(tài)創(chuàng)建對(duì)象，該內(nèi)存池亦叫“堆”或者“內(nèi)存堆”。若采用這種方式，除非進(jìn)入運(yùn)行期，否則根本不知道到底需要多少個(gè)對(duì)象，也不知道它們的存在時(shí)間

75、有多長(zhǎng)，以及準(zhǔn)確的類型是什么。這些參數(shù)都在程序正式運(yùn)行時(shí)才決定的。若需一個(gè)新對(duì)象，只需在需要它的時(shí)候在內(nèi)存堆里簡(jiǎn)單地創(chuàng)建它即可。由于存儲(chǔ)空間的管理是運(yùn)行期間動(dòng)態(tài)進(jìn)行的，所以在內(nèi)存堆里分配存儲(chǔ)空間的時(shí)間比在堆棧里創(chuàng)建的時(shí)間長(zhǎng)得多（在堆棧里創(chuàng)建存儲(chǔ)空間一般只需要一個(gè)簡(jiǎn)單的指令，將堆棧指針向下或向下移動(dòng)即可）。由于動(dòng)態(tài)創(chuàng)建方法使對(duì)象本來(lái)就傾向于復(fù)雜，所以查找存儲(chǔ)空間以及釋放它所需的額外開(kāi)銷不會(huì)為對(duì)象的創(chuàng)建造成明顯的影響。除此以外，更大的靈活性

76、對(duì)于常規(guī)編程問(wèn)題的解決是至關(guān)重要的。</p><p>　　C++允許我們決定是在寫(xiě)程序時(shí)創(chuàng)建對(duì)象，還是在運(yùn)行期間創(chuàng)建，這種控制方法更加靈活。大家或許認(rèn)為既然它如此靈活，那么無(wú)論如何都應(yīng)在內(nèi)存堆里創(chuàng)建對(duì)象，而不是在堆棧中創(chuàng)建。</p><p>　　但還要考慮另外一個(gè)問(wèn)題，亦即對(duì)象的“存在時(shí)間”或者“生存時(shí)間”（Lifetime）。若在堆棧或者靜態(tài)存儲(chǔ)空間里創(chuàng)建一個(gè)對(duì)象，編譯器會(huì)判斷對(duì)象的持續(xù)

77、時(shí)間有多長(zhǎng)，到時(shí)會(huì)自動(dòng)“破壞”或者“清除”它。程序員可用兩種方法來(lái)破壞一個(gè)對(duì)象：用程序化的方式?jīng)Q定何時(shí)破壞對(duì)象，或者利用由運(yùn)行環(huán)境提供的一種“垃圾收集器”特性，自動(dòng)尋找那些不再使用的對(duì)象，并將其清除。當(dāng)然，垃圾收集器顯得方便得多，但要求所有應(yīng)用程序都必須容忍垃圾收集器的存在，并能默許隨垃圾收集帶來(lái)的額外開(kāi)銷。但這并不符合C++語(yǔ)言的設(shè)計(jì)宗旨，所以未能包括到C++里。但Java確實(shí)提供了一個(gè)垃圾收集器（Smalltalk也有這樣的設(shè)計(jì)；盡

78、管Delphi默認(rèn)為沒(méi)有垃圾收集器，但可選擇安裝；而C++亦可使用一些由其他公司開(kāi)發(fā)的垃圾收集產(chǎn)品）。</p><p><b>　　集合與繼承器</b></p><p>　　針對(duì)一個(gè)特定問(wèn)題的解決，如果事先不知道需要多少個(gè)對(duì)象，或者它們的持續(xù)時(shí)間有多長(zhǎng)，那么也不知道如何保存那些對(duì)象。既然如此，怎樣才能知道那些對(duì)象要求多少空間呢？事先上根本無(wú)法提前知道，除非進(jìn)入運(yùn)行期。

79、</p><p>　　在面向?qū)ο蟮脑O(shè)計(jì)中，大多數(shù)問(wèn)題的解決辦法似乎都有些輕率——只是簡(jiǎn)單地創(chuàng)建另一種類型的對(duì)象。用于解決特定問(wèn)題的新型對(duì)象容納了指向其他對(duì)象的句柄。當(dāng)然，也可以用數(shù)組來(lái)做同樣的事情，那是大多數(shù)語(yǔ)言都具有的一種功能。但不能只看到這一點(diǎn)。這種新對(duì)象通常叫作“集合”（亦叫作一個(gè)“容器”，但AWT在不同的場(chǎng)合應(yīng)用了這個(gè)術(shù)語(yǔ)，所以本書(shū)將一直沿用“集合”的稱呼。在需要的時(shí)候，集合會(huì)自動(dòng)擴(kuò)充自己，以便適應(yīng)我們?cè)?/p>

80、其中置入的任何東西。所以我們事先不必知道要在一個(gè)集合里容下多少東西。只需創(chuàng)建一個(gè)集合，以后的工作讓它自己負(fù)責(zé)好了。</p><p>　　幸運(yùn)的是，設(shè)計(jì)優(yōu)良的OOP語(yǔ)言都配套提供了一系列集合。在C++中，它們是以“標(biāo)準(zhǔn)模板庫(kù)”（STL）的形式提供的。Object Pascal用自己的“可視組件庫(kù)”（VCL）提供集合。Smalltalk提供了一套非常完整的集合。而Java也用自己的標(biāo)準(zhǔn)庫(kù)提供了集合。在某些庫(kù)中，一個(gè)常

81、規(guī)集合便可滿足人們的大多數(shù)要求；而在另一些庫(kù)中（特別是C++的庫(kù)），則面向不同的需求提供了不同類型的集合。例如，可以用一個(gè)矢量統(tǒng)一對(duì)所有元素的訪問(wèn)方式；一個(gè)鏈接列表則用于保證所有元素的插入統(tǒng)一。所以我們能根據(jù)自己的需要選擇適當(dāng)?shù)念愋汀Ｆ渲邪?、?duì)列、散列表、樹(shù)、堆棧等等。</p><p>　　所有集合都提供了相應(yīng)的讀寫(xiě)功能。將某樣?xùn)|西置入集合時(shí)，采用的方式是十分明顯的。有一個(gè)叫作“推”（Push）、“添加”（A

82、dd）或其他類似名字的函數(shù)用于做這件事情。但將數(shù)據(jù)從集合中取出的時(shí)候，方式卻并不總是那么明顯。如果是一個(gè)數(shù)組形式的實(shí)體，比如一個(gè)矢量（Vector），那么也許能用索引運(yùn)算符或函數(shù)。但在許多情況下，這樣做往往會(huì)無(wú)功而返。此外，單選定函數(shù)的功能是非常有限的。如果想對(duì)集合中的一系列元素進(jìn)行操縱或比較，而不是僅僅面向一個(gè)，這時(shí)又該怎么辦呢？</p><p>　　辦法就是使用一個(gè)“繼續(xù)器”（Iterator），它屬于一種對(duì)

83、象，負(fù)責(zé)選擇集合內(nèi)的元素，并把它們提供給繼承器的用戶。作為一個(gè)類，它也提供了一級(jí)抽象。利用這一級(jí)抽象，可將集合細(xì)節(jié)與用于訪問(wèn)那個(gè)集合的代碼隔離開(kāi)。通過(guò)繼承器的作用，集合被抽象成一個(gè)簡(jiǎn)單的序列。繼承器允許我們遍歷那個(gè)序列，同時(shí)毋需關(guān)心基礎(chǔ)結(jié)構(gòu)是什么——換言之，不管它是一個(gè)矢量、一個(gè)鏈接列表、一個(gè)堆棧，還是其他什么東西。這樣一來(lái)，我們就可以靈活地改變基礎(chǔ)數(shù)據(jù)，不會(huì)對(duì)程序里的代碼造成干擾。Java最開(kāi)始（在1.0和1.1版中）提供的是一個(gè)標(biāo)準(zhǔn)

84、繼承器，名為Enumeration（枚舉），為它的所有集合類提供服務(wù)。Java 1.2新增一個(gè)更復(fù)雜的集合庫(kù)，其中包含了一個(gè)名為Iterator的繼承器，可以做比老式的Enumeration更多的事情。</p><p>　　從設(shè)計(jì)角度出發(fā)，我們需要的是一個(gè)全功能的序列。通過(guò)對(duì)它的操縱，應(yīng)該能解決自己的問(wèn)題。如果一種類型的序列即可滿足我們的所有要求，那么完全沒(méi)有必要再換用不同的類型。有兩方面的原因促使我們需要對(duì)集合

85、作出選擇。首先，集合提供了不同的接口類型以及外部行為。堆棧的接口與行為與隊(duì)列的不同，而隊(duì)列的接口與行為又與一個(gè)集（Set）或列表的不同。利用這個(gè)特征，我們解決問(wèn)題時(shí)便有更大的靈活性。</p><p>　　其次，不同的集合在進(jìn)行特定操作時(shí)往往有不同的效率。最好的例子便是矢量（Vector）和列表（List）的區(qū)別。它們都屬于簡(jiǎn)單的序列，擁有完全一致的接口和外部行為。但在執(zhí)行一些特定的任務(wù)時(shí)，需要的開(kāi)銷卻是完全不同的

86、。對(duì)矢量?jī)?nèi)的元素進(jìn)行的隨機(jī)訪問(wèn)（存取）是一種常時(shí)操作；無(wú)論我們選擇的選擇是什么，需要的時(shí)間量都是相同的。但在一個(gè)鏈接列表中，若想到處移動(dòng)，并隨機(jī)挑選一個(gè)元素，就需付出“慘重”的代價(jià)。而且假設(shè)某個(gè)元素位于列表較遠(yuǎn)的地方，找到它所需的時(shí)間也會(huì)長(zhǎng)許多。但在另一方面，如果想在序列中部插入一個(gè)元素，用列表就比用矢量劃算得多。這些以及其他操作都有不同的執(zhí)行效率，具體取決于序列的基礎(chǔ)結(jié)構(gòu)是什么。在設(shè)計(jì)階段，我們可以先從一個(gè)列表開(kāi)始。最后調(diào)整性能的時(shí)候

87、，再根據(jù)情況把它換成矢量。由于抽象是通過(guò)繼承器進(jìn)行的，所以能在兩者方便地切換，對(duì)代碼的影響則顯得微不足道。</p><p>　　最后，記住集合只是一個(gè)用來(lái)放置對(duì)象的儲(chǔ)藏所。如果那個(gè)儲(chǔ)藏所能滿足我們的所有需要，就完全沒(méi)必要關(guān)心它具體是如何實(shí)現(xiàn)的（這是大多數(shù)類型對(duì)象的一個(gè)基本概念）。如果在一個(gè)編程環(huán)境中工作，它由于其他因素（比如在Windows下運(yùn)行，或者由垃圾收集器帶來(lái)了開(kāi)銷）產(chǎn)生了內(nèi)在的開(kāi)銷，那么矢量和鏈接列表之

88、間在系統(tǒng)開(kāi)銷上的差異就或許不是一個(gè)大問(wèn)題。我們可能只需要一種類型的序列。甚至可以想象有一個(gè)“完美”的集合抽象，它能根據(jù)自己的使用方式自動(dòng)改變基層的實(shí)現(xiàn)方式。</p><p><b>　　單根結(jié)構(gòu)</b></p><p>　　在面向?qū)ο蟮某绦蛟O(shè)計(jì)中，由于C++的引入而顯得尤為突出的一個(gè)問(wèn)題是：所有類最終是否都應(yīng)從單獨(dú)一個(gè)基礎(chǔ)類繼承。在Java中（與其他幾乎所有OOP語(yǔ)言

89、一樣），對(duì)這個(gè)問(wèn)題的答案都是肯定的，而且這個(gè)終級(jí)基礎(chǔ)類的名字很簡(jiǎn)單，就是一個(gè)“Object”。這種“單根結(jié)構(gòu)”具有許多方面的優(yōu)點(diǎn)。</p><p>　　單根結(jié)構(gòu)中的所有對(duì)象都有一個(gè)通用接口，所以它們最終都屬于相同的類型。另一種方案（就象C++那樣）是我們不能保證所有東西都屬于相同的基本類型。從向后兼容的角度看，這一方案可與C模型更好地配合，而且可以認(rèn)為它的限制更少一些。但假期我們想進(jìn)行純粹的面向?qū)ο缶幊?，那么必?/p>

90、構(gòu)建自己的結(jié)構(gòu)，以期獲得與內(nèi)建到其他OOP語(yǔ)言里的同樣的便利。需添加我們要用到的各種新類庫(kù)，還要使用另一些不兼容的接口。理所當(dāng)然地，這也需要付出額外的精力使新接口與自己的設(shè)計(jì)方案配合（可能還需要多重繼承）。為得到C++額外的“靈活性”，付出這樣的代價(jià)值得嗎？當(dāng)然，如果真的需要——如果早已是C專家，如果對(duì)C有難舍的情結(jié)——那么就真的很值得。但假如你是一名新手，首次接觸這類設(shè)計(jì)，象Java那樣的替換方案也許會(huì)更省事一些。</p>

91、<p>　　單根結(jié)構(gòu)中的所有對(duì)象（比如所有Java對(duì)象）都可以保證擁有一些特定的功能。在自己的系統(tǒng)中，我們知道對(duì)每個(gè)對(duì)象都能進(jìn)行一些基本操作。一個(gè)單根結(jié)構(gòu)，加上所有對(duì)象都在內(nèi)存堆中創(chuàng)建，可以極大簡(jiǎn)化參數(shù)的傳遞（這在C++里是一個(gè)復(fù)雜的概念）。</p><p>　　利用單根結(jié)構(gòu)，我們可以更方便地實(shí)現(xiàn)一個(gè)垃圾收集器。與此有關(guān)的必要支持可安裝于基礎(chǔ)類中，而垃圾收集器可將適當(dāng)?shù)南l(fā)給系統(tǒng)內(nèi)的任何對(duì)象。如果

92、沒(méi)有這種單根結(jié)構(gòu)，而且系統(tǒng)通過(guò)一個(gè)句柄來(lái)操縱對(duì)象，那么實(shí)現(xiàn)垃圾收集器的途徑會(huì)有很大的不同，而且會(huì)面臨許多障礙。</p><p>　　由于運(yùn)行期的類型信息肯定存在于所有對(duì)象中，所以永遠(yuǎn)不會(huì)遇到判斷不出一個(gè)對(duì)象的類型的情況。這對(duì)系統(tǒng)級(jí)的操作來(lái)說(shuō)顯得特別重要，比如違例控制；而且也能在程序設(shè)計(jì)時(shí)獲得更大的靈活性。</p><p>　　集合庫(kù)與方便使用集合</p><p>　

93、　由于集合是我們經(jīng)常都要用到的一種工具，所以一個(gè)集合庫(kù)是十分必要的，它應(yīng)該可以方便地重復(fù)使用。這樣一來(lái)，我們就可以方便地取用各種集合，將其插入自己的程序。</p><p>　　下溯造型與模板／通用性</p><p>　　為了使這些集合能夠重復(fù)使用，或者“再生”，Java提供了一種通用類型，以前曾把它叫作“Object”。單根結(jié)構(gòu)意味著、所有東西歸根結(jié)底都是一個(gè)對(duì)象”！所以容納了Object

94、的一個(gè)集合實(shí)際可以容納任何東西。這使我們對(duì)它的重復(fù)使用變得非常簡(jiǎn)便。</p><p>　　為使用這樣的一個(gè)集合，只需添加指向它的對(duì)象句柄即可，以后可以通過(guò)句柄重新使用對(duì)象。但由于集合只能容納Object，所以在我們向集合里添加對(duì)象句柄時(shí)，它會(huì)上溯造型成Object，這樣便丟失了它的身份或者標(biāo)識(shí)信息。再次使用它的時(shí)候，會(huì)得到一個(gè)Object句柄，而非指向我們?cè)缦戎萌氲哪莻€(gè)類型的句柄。所以怎樣才能歸還它的本來(lái)面貌，調(diào)

95、用早先置入集合的那個(gè)對(duì)象的有用接口呢？</p><p>　　在這里，我們?cè)俅斡玫搅嗽煨停–ast）。但這一次不是在分級(jí)結(jié)構(gòu)中上溯造型成一種更“通用”的類型。而是下溯造型成一種更“特殊”的類型。這種造型方法叫作“下溯造型”（Downcasting）。舉個(gè)例子來(lái)說(shuō)，我們知道在上溯造型的時(shí)候，Circle（圓）屬于Shape（幾何形狀）的一種類型，所以上溯造型是安全的。但我們不知道一個(gè)Object到底是Circle還是

96、Shape，所以很難保證下溯造型的安全進(jìn)行，除非確切地知道自己要操作的是什么。</p><p>　　但這也不是絕對(duì)危險(xiǎn)的，因?yàn)榧偃缦滤菰煨统慑e(cuò)誤的東西，會(huì)得到我們稱為“違例”（Exception）的一種運(yùn)行期錯(cuò)誤。我們稍后即會(huì)對(duì)此進(jìn)行解釋。但在從一個(gè)集合提取對(duì)象句柄時(shí)，必須用某種方式準(zhǔn)確地記住它們是什么，以保證下溯造型的正確進(jìn)行。</p><p>　　下溯造型和運(yùn)行期檢查都要求花額外的時(shí)間

97、來(lái)運(yùn)行程序，而且程序員必須付出額外的精力。既然如此，我們能不能創(chuàng)建一個(gè)“智能”集合，令其知道自己容納的類型呢？這樣做可消除下溯造型的必要以及潛在的錯(cuò)誤。答案是肯定的，我們可以采用“參數(shù)化類型”，它們是編譯器能自動(dòng)定制的類，可與特定的類型配合。例如，通過(guò)使用一個(gè)參數(shù)化集合，編譯器可對(duì)那個(gè)集合進(jìn)行定制，使其只接受Shape，而且只提取Shape。</p><p>　　參數(shù)化類型是C++一個(gè)重要的組成部分，這部分是C+