計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)外文翻譯--對(duì)象的創(chuàng)建和存在時(shí)間_第1頁(yè)
計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)外文翻譯--對(duì)象的創(chuàng)建和存在時(shí)間_第2頁(yè)
計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)外文翻譯--對(duì)象的創(chuàng)建和存在時(shí)間_第3頁(yè)
計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)外文翻譯--對(duì)象的創(chuàng)建和存在時(shí)間_第4頁(yè)
計(jì)算機(jī)科學(xué)與技術(shù)專業(yè)外文翻譯--對(duì)象的創(chuàng)建和存在時(shí)間_第5頁(yè)
已閱讀5頁(yè),還剩11頁(yè)未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說(shuō)明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、 外文原文 Object landscapes and lifetimesTechnically, OOP is just about abstract data typing, inheritance, and polymorphism, but other issues can be at least as important. The remainder of this section will cover these issuesOne of the most important factors is the way objects are created and destroyed.

2、 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 important issue, so it gives the programmer a choice. For imum run-time speed, the storage and lifetime can b

3、e 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. This places a priority on the speed of storage allocation and release, and control of these can be very valuable in some situat

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

5、eThe 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, or what their exact type is. Those are determined at the spur of the moment while the program is running.

6、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 required to allocate storage on the heap is significantly longer than the time to create storage on the stack. Creating storage on the s

7、tack 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 that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage will not have an important

8、impact on the creation of an object. In addition, the greater flexibility is essential to solve the general programming problemJava uses the second approach, exclusively. Every time you want to create an object, you use the new keyword to build a dynamic instance of that objectThere's another is

9、sue, 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 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

10、 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 in C+ programs. Java provides a feature called a garbage collector that automatically discovers when an object is no longer in use and des

11、troys 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, the garbage collector provides a much higher level of insurance against the insidious problem of memory leaks which has brought many a C+ pro

12、ject to its kneesThe rest of this section looks at additional factors concerning object lifetimes and landscapesCollections and iteratorsIf you dont know 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

13、 can you know how much space to create for those objects? You cant, since that information isnt known until run-timeThe solution to most 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 t

14、o 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 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 i

15、tself whenever necessary to accommodate everything you place inside it. So you dont need to know how manyobjects youre going to hold in a container. Just create a container object and let it take care of the detailsFortunately, a good OOP language comes with a set of containers as part of the packag

16、e. In C+, its part of the Standard C+ Library and is sometimes called 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 libraries, a generic c

17、ontainer is considered good enough for all needs, and in others Java, for example the library has different types of containers for different 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

18、 you can choose the particular type that fits your needs. Container libraries may also include sets, queues, hash tables, trees, stacks, etcAll 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

19、 back out. But fetching elements can be more problematic, because a single-selection function is restrictive. What if you want to manipulate or compare a set of elements in the container instead of just oneThe solution is an iterator, which is an object whose job is to select the elements within a c

20、ontainer and present them to 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 thats accessing that container. The container, via the iterator, is abstracted to be simply a sequence. The

21、iterator allows you to traverse that sequence without worrying about the underlying structure?that is, whether its an ArrayList, a LinkedList, 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 b

22、egan 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 more complete container library that contains an iterator called Iterator that does more than the older EnumerationFrom a design standpoint, all you really want is a se

23、quence that can be manipulated to solve your problem. If a single type of sequence satisfied all of your needs, thered be no reason 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 st

24、ack 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 might provide a more flexible solution to your problem than the other. Second, different containers have different efficiencies for certain operations. The best example is a

25、n ArrayList and a LinkedList. Both are simple sequences that can have identical interfaces and external behaviors. But certain operations 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 e

26、lement you select. However, in a LinkedList it is expensive to move through the list to randomly select an element, and it takes longer 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

27、than in an ArrayList. These and other operations have different efficiencies depending on the underlying structure of the sequence. 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 chang

28、e from one to the other with minimal impact on your codeIn the end, remember that a container is only a storage cabinet to put objects 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 program

29、ming environment that has built-in overhead due to other factors, then the cost difference between an ArrayList and a LinkedList 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 implemen

30、tation according to the way it is usedThe singly rooted hierarchyOne of the issues in OOP that has become especially 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

31、“yes and the name of this ultimate base class is simply Object. It turns out that the benefits of the singly rooted hierarchy are manyAll 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 t

32、hat everything is the same fundamental type. From a backward-compatibility standpoint this fits the model of C better 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 bu

33、ilt into other OOP languages. And in any new class library you acquire, some other incompatible interface will be used. 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 it?if you have a large invest

34、ment in C?its quite valuable. If youre starting from scratch, other alternatives such as Java can often be more productiveAll 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

35、in your system. A singly rooted hierarchy, along with creating all objects on the heap, greatly simplifies argument 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

36、 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 rooted hierarchy and a system to manipulate an object via a reference, it is difficult to implement a garbage collectorSince run-time type information

37、 is guaranteed to be in all objects, youll never 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 programmingCollection libraries and support for easy collection useBecaus

38、e 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 Because a container is a tool that youll use frequently, it makes sense to have a library of containers that are built in a reusab

39、le fashion, so you can take one off the shelf and plug it into your program. Java provides such a library, which should satisfy most needsDowncasting vs. templates/genericsTo make these containers reusable, they hold the one universal type in Java that was previously mentioned: Object. The singly ro

40、oted hierarchy means that everything is an Object, so a container that holds Objects can hold anything. This makes containers easy to reuseTo 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 obje

41、ct reference into the container it is upcast 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 object that you put into the containe

42、rHere, the cast is used again, but this time youre not casting up the inheritance hierarchy 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 t

43、o upcast, but you dont know that an Object is necessarily a Circle or a Shape so its hardly safe to downcast unless you know thats what youre dealing withIts not completely dangerous, however, because if you downcast to the wrong thing youll get a run-time error called an exception, which will be de

44、scribed 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 downcastDowncasting and the run-time checks require extra time for the running program, and extra effort from the programmer. Wouldnt it ma

45、ke sense to somehow create the container so that it knows the types that it holds, 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

46、ameterized container, the compiler could customize that container so that it would accept only Shapes and fetch only ShapesParameterized 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 curr

47、ently 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 parameterized types uses a syntax that is strikingly similar to C+ templates /0>.中文譯文 對(duì)象的創(chuàng)立和存在時(shí)間 從技術(shù)角度說(shuō),OOP(面向?qū)ο蟪绦蛟O(shè)計(jì))只是涉及抽象的數(shù)據(jù)類型、繼承以及多形性,但另一些

48、問(wèn)題也可能顯得非常重要。本節(jié)將就這些問(wèn)題進(jìn)行探討。 最重要的問(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í)間可在編寫程序時(shí)決定,只需將對(duì)象放置在堆棧(有時(shí)也叫作自動(dòng)或定域變量)或者靜態(tài)存儲(chǔ)區(qū)域即可。這樣便為存儲(chǔ)空間的分配和釋放提供了一個(gè)優(yōu)先級(jí)。某些情況下,這種優(yōu)先級(jí)的控制是非常有價(jià)值的。然而,我們同時(shí)也犧牲了靈活性,因?yàn)樵诰帉懗绦驎r(shí),必須知道對(duì)象的準(zhǔn)確的數(shù)量、存在時(shí)間、以及類型。如果要解決的是一個(gè)較常規(guī)的問(wèn)題,如計(jì)算

49、機(jī)輔助設(shè)計(jì)、倉(cāng)儲(chǔ)管理或者空中交通控制,這一方法就顯得太局限了。 第二個(gè)方法是在一個(gè)內(nèi)存池中動(dòng)態(tài)創(chuàng)立對(duì)象,該內(nèi)存池亦叫“堆或者“內(nèi)存堆。假設(shè)采用這種方式,除非進(jìn)入運(yùn)行期,否那么根本不知道到底需要多少個(gè)對(duì)象,也不知道它們的存在時(shí)間有多長(zhǎng),以及準(zhǔn)確的類型是什么。這些參數(shù)都在程序正式運(yùn)行時(shí)才決定的。假設(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ǔ)空間以及釋放它

50、所需的額外開銷不會(huì)為對(duì)象的創(chuàng)立造成明顯的影響。除此以外,更大的靈活性對(duì)于常規(guī)編程問(wèn)題的解決是至關(guān)重要的。 C+允許我們決定是在寫程序時(shí)創(chuàng)立對(duì)象,還是在運(yùn)行期間創(chuàng)立,這種控制方法更加靈活。大家或許認(rèn)為既然它如此靈活,那么無(wú)論如何都應(yīng)在內(nèi)存堆里創(chuàng)立對(duì)象,而不是在堆棧中創(chuàng)立。 但還要考慮另外一個(gè)問(wèn)題,亦即對(duì)象的“存在時(shí)間或者“生存時(shí)間(Lifetime)。假設(shè)在堆?;蛘哽o態(tài)存儲(chǔ)空間里創(chuàng)立一個(gè)對(duì)象,編譯器會(huì)判斷對(duì)象的持續(xù)時(shí)間有多長(zhǎng),到時(shí)會(huì)自動(dòng)“破壞或者“去除它。程序員可用兩種方法來(lái)破壞一個(gè)對(duì)象:用程序化的方式?jīng)Q定何時(shí)破壞對(duì)象,或者利用由運(yùn)行環(huán)境提供的一種“垃圾收集器特性,自動(dòng)尋找那些不再使用的對(duì)象,并

51、將其去除。當(dāng)然,垃圾收集器顯得方便得多,但要求所有應(yīng)用程序都必須容忍垃圾收集器的存在,并能默許隨垃圾收集帶來(lái)的額外開銷。但這并不符合C+語(yǔ)言的設(shè)計(jì)宗旨,所以未能包括到C+里。但Java確實(shí)提供了一個(gè)垃圾收集器(Smalltalk也有這樣的設(shè)計(jì);盡管Delphi默認(rèn)為沒(méi)有垃圾收集器,但可選擇安裝;而C+亦可使用一些由其他公司開發(fā)的垃圾收集產(chǎn)品)。集合與繼承器 針對(duì)一個(gè)特定問(wèn)題的解決,如果事先不知道需要多少個(gè)對(duì)象,或者它們的持續(xù)時(shí)間有多長(zhǎng),那么也不知道如何保存那些對(duì)象。既然如此,怎樣才能知道那些對(duì)象要求多少空間呢?事先上根本無(wú)法提前知道,除非進(jìn)入運(yùn)行期。 在面向?qū)ο蟮脑O(shè)計(jì)中,大多數(shù)問(wèn)題的解決方法似

52、乎都有些輕率?只是簡(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í)候,集合會(huì)自動(dòng)擴(kuò)充自己,以便適應(yīng)我們?cè)谄渲兄萌氲娜魏螙|西。所以我們事先不必知道要在一個(gè)集合里容下多少東西。只需創(chuàng)立一個(gè)集合,以后的工作讓它自己負(fù)責(zé)好了。 幸運(yùn)的是,設(shè)計(jì)優(yōu)良的OOP語(yǔ)言都配套提供了一系列集合。在C+中,它們是以“標(biāo)準(zhǔn)模板庫(kù)(STL)的形式提供的。Object Pascal用自己

53、的“可視組件庫(kù)(VCL)提供集合。Smalltalk提供了一套非常完整的集合。而Java也用自己的標(biāo)準(zhǔn)庫(kù)提供了集合。在某些庫(kù)中,一個(gè)常規(guī)集合便可滿足人們的大多數(shù)要求;而在另一些庫(kù)中(特別是C+的庫(kù)),那么面向不同的需求提供了不同類型的集合。例如,可以用一個(gè)矢量統(tǒng)一對(duì)所有元素的訪問(wèn)方式;一個(gè)鏈接列表那么用于保證所有元素的插入統(tǒng)一。所以我們能根據(jù)自己的需要選擇適當(dāng)?shù)念愋汀F渲邪?、?duì)列、散列表、樹、堆棧等等。 所有集合都提供了相應(yīng)的讀寫功能。將某樣?xùn)|西置入集合時(shí),采用的方式是十清楚顯的。有一個(gè)叫作“推(Push)、“添加(Add)或其他類似名字的函數(shù)用于做這件事情。但將數(shù)據(jù)從集合中取出的時(shí)候,方式卻并不總是那么明顯。如果是一個(gè)數(shù)組形式的實(shí)體,比方一個(gè)矢量(Vector),那么也許能用索引運(yùn)算符或函數(shù)。但在許多情況下,這樣做往往會(huì)無(wú)功而返。此外,單項(xiàng)選擇定函數(shù)的功能是非常有限的。如果想對(duì)集合中的一系列元素進(jìn)行操縱或比擬,而不是僅僅面向一個(gè),這時(shí)又該怎么辦呢? 方法就是使用一個(gè)“繼續(xù)器(Iterator),它屬于一種對(duì)象,負(fù)責(zé)選擇集合內(nèi)的元素,并把

溫馨提示

  • 1. 本站所有資源如無(wú)特殊說(shuō)明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽,若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫(kù)網(wǎng)僅提供信息存儲(chǔ)空間,僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請(qǐng)與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

最新文檔

評(píng)論

0/150

提交評(píng)論