189.B網(wǎng)絡(luò)即時通信系統(tǒng)的設(shè)計(jì) 外文文獻(xiàn)翻譯

1、學(xué)校代碼： xxx學(xué) 號：xxx 本科畢業(yè)設(shè)計(jì)外文文獻(xiàn)翻譯（學(xué)生姓名：xxx學(xué) 院：信息工程學(xué)院系 別：計(jì)算機(jī)系專 業(yè)：軟件工程班 級：軟件06指導(dǎo)教師：xxx 講師二一年六月本文源碼索取，請聯(lián)系qq：68661508xxx工業(yè)大學(xué)本科畢業(yè)設(shè)計(jì)外文文獻(xiàn)翻譯object landscapes and lifetimestechnically, oop is just about abstract data typing, inheritance, and polymorphism, but other issues can be at least as important. the remain

2、der of this section will cover these issues. one of the most important factors is the way objects are 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 efficien

3、cy is the most important 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 automatic or scoped variables) or in the static storage area

4、. this places a priority on the speed of storage allocation and release, and control of these can be very valuable in some situations. however, you sacrifice flexibility because you must know the exact quantity, lifetime, and type of objects while you're writing the program. if you are trying to

5、 solve a more general problem such as computer-aided design, warehouse management, or air-traffic control, this is too restrictive. 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,

6、 what their lifetime is, 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 managed dynamically, at run-time, the amount of time requi

7、red to allocate storage on the heap is significantly longer than the time to create storage on the stack. (creating storage on the stack is often a single assembly instruction to move the stack pointer down, and another to move it back up.) the dynamic approach makes the generally logical assumption

8、 that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage will not have an important impact on the creation of an object. in addition, the greater flexibility is essential to solve the general programming problem. java uses the second approach, exclusi

9、vely. every time you want to create an object, you use the new keyword to build a dynamic instance of that object. 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 compiler determines how long the object l

10、asts 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 when to destroy the object, which can lead to memory leaks if you dont do it correctly (and this is a common problem

11、in c+ programs). java provides a feature called a garbage collector that automatically discovers when an object is no longer in use and destroys it. a garbage collector is much more convenient because it reduces the number of issues that you must track and the code you must write. more important, th

12、e garbage collector provides a much higher level of insurance against the insidious problem of memory leaks (which has brought many a c+ project to its knees). the rest of this section looks at additional factors concerning object lifetimes and landscapes. 1 collections and iteratorsif you dont know

13、 how many objects youre going to need to solve a particular problem, or how long they will last, you also dont know how to store those objects. how can you know how much space to create for those objects? you cant, since that information isnt known until run-time. the solution to most problems in ob

14、ject-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 with an array, which is available in most languages. but theres more. this new object, generally

15、called a container (also called a collection, but the java library uses that term in a different sense so this book will use “container”), will expand itself whenever necessary to accommodate everything you place inside it. so you dont need to know how manyobjects youre going to hold in a container.

16、 just create a container object and let it take care of the details. fortunately, a good oop language comes with a set of containers as part of the package. in c+, its part of the standard c+ library and is sometimes called the standard template library (stl). object pascal has containers in its vis

17、ual component library (vcl). smalltalk has a very complete set of containers. java also has containers in its standard library. in some libraries, a generic container is considered good enough for all needs, and in others (java, for example) the library has different types of containers for differen

18、t needs: a vector (called an arraylist in java) for consistent access to all elements, and a linked list for consistent insertion at all elements, for example, so you can choose the particular type that fits your needs. container libraries may also include sets, queues, hash tables, trees, stacks, e

19、tc. all containers have some way to put things in and get things out; there are 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 manipu

20、late or compare a set of elements in the container instead of just one? the solution is an iterator, which is an object whose job is to select the elements within a container and present them to the user of the iterator. as a class, it also provides a level of abstraction. this abstraction can be us

21、ed to separate the details of the container from the code thats accessing that container. the container, via the iterator, is abstracted to be simply a sequence. the iterator allows you to traverse that sequence without worrying about the underlying structurethat is, whether its an arraylist, a link

22、edlist, a stack, or something else. this gives you the flexibility to easily change the underlying data structure without disturbing the code in your program. java began (in version 1.0 and 1.1) with a standard iterator, called enumeration, for all of its container classes. java 2 has added a much m

23、ore complete container library that contains an iterator called iterator that does more than the older enumeration. from a design standpoint, all you really want is a sequence that can be manipulated to solve your problem. if a single type of sequence satisfied all of your needs, thered be no reason

24、 to have different kinds. there are two reasons that you need a choice of containers. 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 migh

25、t provide a more flexible solution to your problem than the other. second, different containers have different efficiencies for certain operations. the best example is an arraylist and a linkedlist. both are simple sequences that can have identical interfaces and external behaviors. but certain oper

26、ations can have radically different costs. randomly accessing elements in an arraylist is a constant-time operation; it takes the same amount of time regardless of the element you select. however, in a linkedlist it is expensive to move through the list to randomly select an element, and it takes lo

27、nger to find an element that is further down the list. on the other hand, if you want to insert an element in the middle of a sequence, its much cheaper in a linkedlist than in an arraylist. these and other operations have different efficiencies depending on the underlying structure of the sequence.

28、 in the design phase, you might start with a linkedlist and, when tuning for performance, change to an arraylist. because of the abstraction via iterators, you can change from one to the other with minimal impact on your code. in the end, remember that a container is only a storage cabinet to put ob

29、jects in. if that cabinet solves all of your needs, it doesnt really matter how it is implemented (a basic concept with most types of objects). if youre working in a programming environment that has built-in overhead due to other factors, then the cost difference between an arraylist and a linkedlis

30、t might not matter. you might need only one type of sequence. you can even imagine the “perfect” container abstraction, which can automatically change its underlying implementation according to the way it is used. 2 the singly rooted hierarchyone of the issues in oop that has become especially promi

31、nent 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 ultimate base class is simply object. it turns out that the benefits of the singly rooted hie

32、rarchy are many. all objects in a singly rooted hierarchy have an interface in common, so they are all ultimately the same type. the alternative (provided by c+) is that you dont know that everything is the same fundamental type. from a backward-compatibility standpoint this fits the model of c bett

33、er and can be thought 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 thats built into other oop languages. and in any new class library you acquire, some other incompatible interface will be u

34、sed. it requires effort (and possibly multiple inheritance) to work the new interface into your design. is the extra “flexibility” of c+ worth it? if you need itif you have a large investment in cits quite valuable. if youre starting from scratch, other alternatives such as java can often be more pr

35、oductive. all 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, along with creating all objects on the heap, greatly simplifies arg

36、ument passing (one of the more complex topics in c+). a singly rooted hierarchy makes it much easier to implement a garbage collector (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

37、 every object in the system. without a singly rooted hierarchy and a system to manipulate an object via a reference, it is difficult to implement a garbage collector. since run-time type information is guaranteed to be in all objects, youll never end up with an object whose type you cannot determine

38、. this is especially important with system level operations, such as exception handling, and to allow greater flexibility in programming. 3 collection libraries and support for easy collection usebecause a container is a tool that youll use frequently, it makes sense to have a library of containers

39、that are built in a reusable fashion, so you can take one off the shelf because a container is a tool that youll 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 into your program. java provides such a

40、library, which should satisfy most needs. downcasting vs. templates/genericsto make these containers reusable, they hold the one universal 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 an

41、ything. this makes containers easy to reuse. 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 to object, thus losing its identity. when you fet

42、ch 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 object that you put into the container? here, the cast is used again, but this time youre not casting up the inheritance hierarchy

43、to a more general type, you cast down the hierarchy to a more specific type. this manner of casting is called downcasting. with upcasting, you know, for example, that a circle is a type of shape so its safe to upcast, but you dont know that an object is necessarily a circle or a shape so its hardly

44、safe to downcast unless you know thats what youre dealing with. its not completely dangerous, however, because if you downcast to the wrong thing youll get a run-time error called an exception, which will be described shortly. when you fetch object references from a container, though, you must have

45、some way to remember exactly what they are so you can perform a proper downcast. downcasting and the run-time checks require extra time for the running program, and extra effort from the programmer. wouldnt it make sense to somehow create the container so that it knows the types that it holds, elimi

46、nating 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 parameterized container, the compiler could customize that container so that it would accep

47、t only shapes and fetch only shapes. parameterized types are an important part of c+, partly because c+ has no singly rooted hierarchy. in c+, the keyword that implements parameterized types is “template.” java currently has no parameterized types since it is possible for it to get byhowever awkward

48、lyusing the singly rooted hierarchy. however, a current proposal for parameterized types uses a syntax that is strikingly similar to c+ templates. form: 譯文對象的創(chuàng)建和存在時間從技術(shù)角度說，oop（面向?qū)ο蟪绦蛟O(shè)計(jì)）只是涉及抽象的數(shù)據(jù)類型、繼承以及多形性，但另一些問題也可能顯得非常重要。本節(jié)將就這些問題進(jìn)行探討。最重要的問題之一是對象的創(chuàng)建及破壞方式。對象需要的數(shù)據(jù)位于哪兒，如何控制對象的“存在時間”呢？針對這個問題，解決的方案是各異其趣的。

49、c+認(rèn)為程序的執(zhí)行效率是最重要的一個問題，所以它允許程序員作出選擇。為獲得最快的運(yùn)行速度，存儲以及存在時間可在編寫程序時決定，只需將對象放置在堆棧（有時也叫作自動或定域變量）或者靜態(tài)存儲區(qū)域即可。這樣便為存儲空間的分配和釋放提供了一個優(yōu)先級。某些情況下，這種優(yōu)先級的控制是非常有價值的。然而，我們同時也犧牲了靈活性，因?yàn)樵诰帉懗绦驎r，必須知道對象的準(zhǔn)確的數(shù)量、存在時間、以及類型。如果要解決的是一個較常規(guī)的問題，如計(jì)算機(jī)輔助設(shè)計(jì)、倉儲管理或者空中交通控制，這一方法就顯得太局限了。第二個方法是在一個內(nèi)存池中動態(tài)創(chuàng)建對象，該內(nèi)存池亦叫“堆”或者“內(nèi)存堆”。若采用這種方式，除非進(jìn)入運(yùn)行期，否則根本不知道

50、到底需要多少個對象，也不知道它們的存在時間有多長，以及準(zhǔn)確的類型是什么。這些參數(shù)都在程序正式運(yùn)行時才決定的。若需一個新對象，只需在需要它的時候在內(nèi)存堆里簡單地創(chuàng)建它即可。由于存儲空間的管理是運(yùn)行期間動態(tài)進(jìn)行的，所以在內(nèi)存堆里分配存儲空間的時間比在堆棧里創(chuàng)建的時間長得多（在堆棧里創(chuàng)建存儲空間一般只需要一個簡單的指令，將堆棧指針向下或向下移動即可）。由于動態(tài)創(chuàng)建方法使對象本來就傾向于復(fù)雜，所以查找存儲空間以及釋放它所需的額外開銷不會為對象的創(chuàng)建造成明顯的影響。除此以外，更大的靈活性對于常規(guī)編程問題的解決是至關(guān)重要的。c+允許我們決定是在寫程序時創(chuàng)建對象，還是在運(yùn)行期間創(chuàng)建，這種控制方法更加靈活。大

51、家或許認(rèn)為既然它如此靈活，那么無論如何都應(yīng)在內(nèi)存堆里創(chuàng)建對象，而不是在堆棧中創(chuàng)建。但還要考慮另外一個問題，亦即對象的“存在時間”或者“生存時間”（lifetime）。若在堆?；蛘哽o態(tài)存儲空間里創(chuàng)建一個對象，編譯器會判斷對象的持續(xù)時間有多長，到時會自動“破壞”或者“清除”它。程序員可用兩種方法來破壞一個對象：用程序化的方式?jīng)Q定何時破壞對象，或者利用由運(yùn)行環(huán)境提供的一種“垃圾收集器”特性，自動尋找那些不再使用的對象，并將其清除。當(dāng)然，垃圾收集器顯得方便得多，但要求所有應(yīng)用程序都必須容忍垃圾收集器的存在，并能默許隨垃圾收集帶來的額外開銷。但這并不符合c+語言的設(shè)計(jì)宗旨，所以未能包括到c+里。但jav

52、a確實(shí)提供了一個垃圾收集器（smalltalk也有這樣的設(shè)計(jì)；盡管delphi默認(rèn)為沒有垃圾收集器，但可選擇安裝；而c+亦可使用一些由其他公司開發(fā)的垃圾收集產(chǎn)品）。本節(jié)剩下的部分將討論操縱對象時要考慮的另一些因素。1 集合與繼承器針對一個特定問題的解決，如果事先不知道需要多少個對象，或者它們的持續(xù)時間有多長，那么也不知道如何保存那些對象。既然如此，怎樣才能知道那些對象要求多少空間呢？事先上根本無法提前知道，除非進(jìn)入運(yùn)行期。在面向?qū)ο蟮脑O(shè)計(jì)中，大多數(shù)問題的解決辦法似乎都有些輕率只是簡單地創(chuàng)建另一種類型的對象。用于解決特定問題的新型對象容納了指向其他對象的句柄。當(dāng)然，也可以用數(shù)組來做同樣的事情，那

53、是大多數(shù)語言都具有的一種功能。但不能只看到這一點(diǎn)。這種新對象通常叫作“集合”（亦叫作一個“容器”，但awt在不同的場合應(yīng)用了這個術(shù)語，所以本書將一直沿用“集合”的稱呼。在需要的時候，集合會自動擴(kuò)充自己，以便適應(yīng)我們在其中置入的任何東西。所以我們事先不必知道要在一個集合里容下多少東西。只需創(chuàng)建一個集合，以后的工作讓它自己負(fù)責(zé)好了。幸運(yùn)的是，設(shè)計(jì)優(yōu)良的oop語言都配套提供了一系列集合。在c+中，它們是以“標(biāo)準(zhǔn)模板庫”（stl）的形式提供的。object pascal用自己的“可視組件庫”（vcl）提供集合。smalltalk提供了一套非常完整的集合。而java也用自己的標(biāo)準(zhǔn)庫提供了集合。在某些庫中

54、，一個常規(guī)集合便可滿足人們的大多數(shù)要求；而在另一些庫中（特別是c+的庫），則面向不同的需求提供了不同類型的集合。例如，可以用一個矢量統(tǒng)一對所有元素的訪問方式；一個鏈接列表則用于保證所有元素的插入統(tǒng)一。所以我們能根據(jù)自己的需要選擇適當(dāng)?shù)念愋?。其中包括集、?duì)列、散列表、樹、堆棧等等。所有集合都提供了相應(yīng)的讀寫功能。將某樣?xùn)|西置入集合時，采用的方式是十分明顯的。有一個叫作“推”（push）、“添加”（add）或其他類似名字的函數(shù)用于做這件事情。但將數(shù)據(jù)從集合中取出的時候，方式卻并不總是那么明顯。如果是一個數(shù)組形式的實(shí)體，比如一個矢量（vector），那么也許能用索引運(yùn)算符或函數(shù)。但在許多情況下，這樣

55、做往往會無功而返。此外，單選定函數(shù)的功能是非常有限的。如果想對集合中的一系列元素進(jìn)行操縱或比較，而不是僅僅面向一個，這時又該怎么辦呢？辦法就是使用一個“繼續(xù)器”（iterator），它屬于一種對象，負(fù)責(zé)選擇集合內(nèi)的元素，并把它們提供給繼承器的用戶。作為一個類，它也提供了一級抽象。利用這一級抽象，可將集合細(xì)節(jié)與用于訪問那個集合的代碼隔離開。通過繼承器的作用，集合被抽象成一個簡單的序列。繼承器允許我們遍歷那個序列，同時毋需關(guān)心基礎(chǔ)結(jié)構(gòu)是什么換言之，不管它是一個矢量、一個鏈接列表、一個堆棧，還是其他什么東西。這樣一來，我們就可以靈活地改變基礎(chǔ)數(shù)據(jù)，不會對程序里的代碼造成干擾。java最開始（在1.0

56、和1.1版中）提供的是一個標(biāo)準(zhǔn)繼承器，名為enumeration（枚舉），為它的所有集合類提供服務(wù)。java 1.2新增一個更復(fù)雜的集合庫，其中包含了一個名為iterator的繼承器，可以做比老式的enumeration更多的事情。從設(shè)計(jì)角度出發(fā)，我們需要的是一個全功能的序列。通過對它的操縱，應(yīng)該能解決自己的問題。如果一種類型的序列即可滿足我們的所有要求，那么完全沒有必要再換用不同的類型。有兩方面的原因促使我們需要對集合作出選擇。首先，集合提供了不同的接口類型以及外部行為。堆棧的接口與行為與隊(duì)列的不同，而隊(duì)列的接口與行為又與一個集（set）或列表的不同。利用這個特征，我們解決問題時便有更大的靈

57、活性。其次，不同的集合在進(jìn)行特定操作時往往有不同的效率。最好的例子便是矢量（vector）和列表（list）的區(qū)別。它們都屬于簡單的序列，擁有完全一致的接口和外部行為。但在執(zhí)行一些特定的任務(wù)時，需要的開銷卻是完全不同的。對矢量內(nèi)的元素進(jìn)行的隨機(jī)訪問（存?。┦且环N常時操作；無論我們選擇的選擇是什么，需要的時間量都是相同的。但在一個鏈接列表中，若想到處移動，并隨機(jī)挑選一個元素，就需付出“慘重”的代價。而且假設(shè)某個元素位于列表較遠(yuǎn)的地方，找到它所需的時間也會長許多。但在另一方面，如果想在序列中部插入一個元素，用列表就比用矢量劃算得多。這些以及其他操作都有不同的執(zhí)行效率，具體取決于序列的基礎(chǔ)結(jié)構(gòu)是什么

58、。在設(shè)計(jì)階段，我們可以先從一個列表開始。最后調(diào)整性能的時候，再根據(jù)情況把它換成矢量。由于抽象是通過繼承器進(jìn)行的，所以能在兩者方便地切換，對代碼的影響則顯得微不足道。最后，記住集合只是一個用來放置對象的儲藏所。如果那個儲藏所能滿足我們的所有需要，就完全沒必要關(guān)心它具體是如何實(shí)現(xiàn)的（這是大多數(shù)類型對象的一個基本概念）。如果在一個編程環(huán)境中工作，它由于其他因素（比如在windows下運(yùn)行，或者由垃圾收集器帶來了開銷）產(chǎn)生了內(nèi)在的開銷，那么矢量和鏈接列表之間在系統(tǒng)開銷上的差異就或許不是一個大問題。我們可能只需要一種類型的序列。甚至可以想象有一個“完美”的集合抽象，它能根據(jù)自己的使用方式自動改變基層的實(shí)現(xiàn)方式。2 單根結(jié)構(gòu)在面向?qū)ο蟮某绦蛟O(shè)計(jì)中，由于c+的引入而顯得尤為突出的一個問題是：所有類最終是否都應(yīng)從單獨(dú)一個基礎(chǔ)類繼承。在java中（與其他幾乎所有o