B設(shè)計(jì)論文(C)外文文獻(xiàn)中英文翻譯(Object)

1、皮晨暉軟件081班7023108043Object landscapes and lifetimesTech nically, OOP is just about abstract data typing, in herita nee, and polymorphism, but other issues can be at least as importa nt. The rema in der of this sect ion will cover these issues.One of the most importa nt factors is the way objects are

2、created and destroyed. Where is the data for an object and how is the lifetime of the object con trolled? There are differe nt philosophies at work here. C+ takes the approach that con trol of efficie ncy is the most importa nt issue, so it gives the programmer a choice. For maximum run-time speed,

3、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. This places a priority on the speed of storage allocatio n and release, and con trol of these c

4、an be very valuable in some situati ons. However, you sacrifice flexibility because you must know the exact qua ntity, lifetime, and type of objects while youre writing the program. If you are trying to solve a more general problem such as computer-aided desig n, warehouse man ageme nt, or air-traff

5、ic con trol, this is too restrictive.The sec ond approach is to create objects dyn amically in a pool of memory called the heap. In this approach, you dont know un til run-time how many objects you n eed, what their lifetime is, or what their exact type is. Those are determined at the spur of the mo

6、ment while the program is runnin g. If you n eed a new object, you simply make it on the heap at the point that you n eed it. Because the storage is man aged dyn amically, at run-time, the amount of time required to allocate storage on the heap is sig ni fica ntly Ion ger tha n the time to create st

7、orage on the stack. (Creat ing storage on the stack is ofte n a si ngle assembly in structio n to move the stack poin ter dow n, and ano ther to move it back up.) The dyn amic approach makes the gen erally logical assumpti on that objects tend to be complicated, so the extra overhead of finding stor

8、age and releas ing that storage will not have an importa nt impact on the creati on of an object .In additi on, the greater flexibility is esse ntial to solve the gen eral program ming problem.Java uses the sec ond approach, exclusively1. Every time you want to create an object, you use the new keyw

9、ord to build a dyn amic in sta nee of that object.Theres ano ther issue, however, and thats the lifetime of an object. With Ian guages that allow objects to be created on the stack, the compiler determines how long the object lasts and canautomatically destroy it. However, if you create it on the he

10、ap the compiler has no knowledge ofits lifetime. In a language like C+, you must determine programmatically when to destroy theobject, which can lead to memory leaks if you don t do it correctly (and this is a common problemin C+ programs). Java provides a feature called a garbage collector that aut

11、omatically 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, the garbage collector provides a much higher level of insurance against the in

12、sidious 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.The singly rooted hierarchyOne of the issues in OOP that has become especially prominent since the introduction of C+is

13、 whether all classes should ultimately be inherited from a single base class. In Java (as with simply Object. It turns out that the benefits of the singly rooted hierarchy are many.virtually all other OOP languages) the answer is ?yesandtitmheatneabmaeseofctlahsissuislAll objects in a singly rooted

14、hierarchy have an interface in common, so they are all ultimately the same type. The alternative (provided by C+) is that you don tknow thateverything 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

15、 when you want to do full-on object- oriented programming you must then build your own hierarchy to provide the same convenience that busilt 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 i

16、nheritance) to work the new interface into your design. Is the extra“ flexibility ” of C+ woritfh it? If you need ityou have a large investment in C it qsuite valuable. If you restarting from scratch, other alternatives such as Java can often be more productive.All objects in a singly rooted hierarc

17、hy(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 argument passing (one of the more complex topics in

18、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 every object in the system. Without a singly root

19、ed 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, you ll never end up withobject whose type you cannot determine. This is especially important with system level opera

20、tions, such as exception handling, and to allow greater flexibility in programming.2.Collection libraries and support for easy collection useBecause 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

21、one off the shelf Because a container is a tool that youfrequenlltluys,eit makes sense to have a library of containers that arebuilt in a reusable fashion, so you can take one off the shelf and plug it into your program. Java provides such a library, which should satisfy most needs.Downcasting vs. t

22、emplates/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 anything. This makes containers easy to reuse.To use such a c

23、ontainer, 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 fetch it back, you get an Object reference, and not a reference

24、 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 you re not casting up the inheritance hierarchy to amore general type, you cast down the hierarchy to a more

25、 specific 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 dont knoOwbtjheactt aisnnecessarily a Circle or a Shape so it s hardlysafe to downcast unless you know that s what you re dealing with

26、.It s not completely dangerous, however, because if you downcast to the wrong thing you get a run-time error called an exception, which will be described shortly. When you fetch objectreferences from a container, though, you must have some way to remember exactly what they are so you can perform a p

27、roper downcast.Downcasting and the run-time checks require extra time for the running program, and extra effort from the programmer. Wouldnmake st eitnse to somehow create the container so that itknows the types that it holds, eliminating the need for the downcast and a possible mistake? The solutio

28、n 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 accept only Shapes and fetch only Shapes.Java cuParameterized types are a

29、n important part of C+, partly because C+ has no singly rooted hierarchy. In C+, the keyword that implements parameterized types is“ template.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 paramete

30、rized types uses a syntax that is strikingly similar to C+ templates.對象的創(chuàng)建和存在時間從技術(shù)角度說， 00P（面向?qū)ο蟪绦蛟O(shè)計(jì)）只是涉及抽象的數(shù)據(jù)類型、繼承以及多形性，但另一些問題也可能顯得非常重要。本節(jié)將就這些問題進(jìn)行探討。最重要的問題之一是對象的創(chuàng)建及破壞方式。對象需要的數(shù)據(jù)位于哪兒，如何控制對象的“存在時間”呢？針對這個問題，解決的方案是各異其趣的。C+認(rèn)為程序的執(zhí)行效率是最重要的一個問題，所以它允許程序員作出選擇。為獲得最快的運(yùn)行速度，存儲以及存 在時間可在編寫程序時決定，只需將對象放置在堆棧（有時也叫作自動或定域

31、變量）或者 靜態(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)行期，否則根本不知道到底需要多少個對象，也不知道它們 的存在時間有多長，以及準(zhǔn)確的類型是什么。這些參數(shù)都在程序正式運(yùn)行時才決定的。若 需一個新對象，只需在需要它的時候在內(nèi)存堆里簡

32、單地創(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)建，這種控制方法更加靈 活。大家或許認(rèn)為既然它如此靈活，那么無論如何都應(yīng)在內(nèi)存堆里創(chuàng)建對象，而不是在堆 棧中創(chuàng)建。但 還 要 考慮 另 外一 個問 題 ， 亦 即對 象 的

33、 “ 存 在 時 間 ” 或者“ 生存 時 間（ Lifetime ）。若在堆?；蛘哽o態(tài)存儲空間里創(chuàng)建一個對象，編譯器會判斷對象的持續(xù)時 間有多長，到時會自動“破壞”或者“清除”它。程序員可用兩種方法來破壞一個對象： 用程序化的方式?jīng)Q定何時破壞對象，或者利用由運(yùn)行環(huán)境提供的一種“垃圾收集器”特 性，自動尋找那些不再使用的對象，并將其清除。當(dāng)然，垃圾收集器顯得方便得多，但要 求所有應(yīng)用程序都必須容忍垃圾收集器的存在，并能默許隨垃圾收集帶來的額外開銷。但這并不符合C+語言的設(shè)計(jì)宗旨，所以未能包括到C+里。但Java確實(shí)提供了一個垃圾收集器（ Smalltalk 也有這樣的設(shè)計(jì)；盡管 Delphi

34、默認(rèn)為沒有垃圾收集器，但可選擇安裝；而C+亦可使用一些由其他公司開發(fā)的垃圾收集產(chǎn)品）。本節(jié)剩下的部分將討論操縱對象時要考慮的另一些因素。1 單根結(jié)構(gòu)在面向?qū)ο蟮某绦蛟O(shè)計(jì)中，由于C+的引入而顯得尤為突出的一個問題是：所有類最終是否都應(yīng)從單獨(dú)一個基礎(chǔ)類繼承。在Java中（與其他幾乎所有 OOP語言一樣），對這個問題的答案都是肯定的，而且這個終級基礎(chǔ)類的名字很簡單，就是一個“ Object ”。這種 “單根結(jié)構(gòu)”具有許多方面的優(yōu)點(diǎn)。單根結(jié)構(gòu)中的所有對象都有一個通用接口，所以它們最終都屬于相同的類型。另一種方案（就象 C+那樣）是我們不能保證所有東西都屬于相同的基本類型。從向后兼容的角 度看，這一方案

35、可與 C 模型更好地配合，而且可以認(rèn)為它的限制更少一些。但假期我們想進(jìn)行純粹的面向?qū)ο缶幊?，那么必須?gòu)建自己的結(jié)構(gòu)，以期獲得與內(nèi)建到其他OOP語言里的同樣的便利。需添加我們要用到的各種新類庫，還要使用另一些不兼容的接口。理所當(dāng) 然地，這也需要付出額外的精力使新接口與自己的設(shè)計(jì)方案配合（可能還需要多重繼承）。為得到 C+額外的“靈活性”，付出這樣的代價值得嗎？當(dāng)然，如果真的需要一一 如果早已是 C 專家，如果對 C 有難舍的情結(jié)那么就真的很值得。但假如你是一名新 手，首次接觸這類設(shè)計(jì)，象 Java 那樣的替換方案也許會更省事一些。單根結(jié)構(gòu)中的所有對象（比如所有 Java 對象）都可以保證擁有一些

36、特定的功能。在自 己的系統(tǒng)中，我們知道對每個對象都能進(jìn)行一些基本操作。一個單根結(jié)構(gòu)，加上所有對象 都在內(nèi)存堆中創(chuàng)建，可以極大簡化參數(shù)的傳遞（這在C+里是一個復(fù)雜的概念）。利用單根結(jié)構(gòu)，我們可以更方便地實(shí)現(xiàn)一個垃圾收集器。與此有關(guān)的必要支持可安裝 于基礎(chǔ)類中，而垃圾收集器可將適當(dāng)?shù)南l(fā)給系統(tǒng)內(nèi)的任何對象。如果沒有這種單根結(jié) 構(gòu)，而且系統(tǒng)通過一個句柄來操縱對象，那么實(shí)現(xiàn)垃圾收集器的途徑會有很大的不同，而 且會面臨許多障礙。由于運(yùn)行期的類型信息肯定存在于所有對象中，所以永遠(yuǎn)不會遇到判斷不出一個對象 的類型的情況。這對系統(tǒng)級的操作來說顯得特別重要，比如違例控制；而且也能在程序設(shè) 計(jì)時獲得更大的靈活性。2 集合庫與方便使用集合由于集合是我們經(jīng)常都要用到的一種工具，所以一個集合庫是十分必要的，它應(yīng)該可 以方便地重復(fù)使用。這樣一來，我們就可以方便地取用各種集合，將其插入自