计算机专业毕业设计论文外文文献中英文翻译Object.docx

1、计算机专业毕业设计论文外文文献中英文翻译Object外文资料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 issues. One of the most important factors is the way objects

2、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 efficiency is the most important issue, so it gives the programmer a choice. For maximum run-time speed, t

3、he 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 allocation and release, and control of these can

4、be very valuable in some situations. However, you sacrifice flexibility because you must know the exact quantity, lifetime, and type of objects while youre writing the program. If you are trying to solve a more general problem such as computer-aided design, warehouse management, or air-traffic contr

5、ol, this is too restrictive. The second approach is to create objects dynamically in a pool of memory called the heap. In this approach, you dont 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 t

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

7、reating 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 that objects tend to be complicated, so the extra overhead of finding storage and releasing that storage wi

8、ll 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, exclusively. Every time you want to create an object, you use the new keyword to build a dynamic instance of that o

9、bject. Theres another issue, however, and thats 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 life

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

11、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 insidious problem of memory leaks (which has

12、 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 how many objects youre going to need to solve a particular problem, or how long they will last, you also dont know ho

13、w 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 object-oriented design seems flippant: you create another type of object. The new type of object that solves this partic

14、ular 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 called a container (also called a collection, but the Java library uses that term in a different sense so this book wi

15、ll 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. Just create a container object and let it take care of the details. Fortunately, a good OOP language comes with a set

16、 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 Visual Component Library (VCL). Smalltalk has a very complete set of containers. Java also has containers in its standard

17、 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 different needs: a vector (called an ArrayList in Java) for consistent access to all elements, and a linked list for consisten

18、t 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, etc. All containers have some way to put things in and get things out; there are usually functions to add elements to a

19、 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 manipulate or compare a set of elements in the container instead of just one? The solution is an iterator, which is an objec

20、t 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 used to separate the details of the container from the code thats accessing that container. The container, via the itera

21、tor, 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 LinkedList, a Stack, or something else. This gives you the flexibility to easily change the underlying data structure with

22、out 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 more complete container library that contains an iterator called Iterator that does more than the older Enumeration. Fr

23、om 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 to have different kinds. There are two reasons that you need a choice of containers. First, containers provide differ

24、ent 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 might provide a more flexible solution to your problem than the other. Second, different containers have different efficie

25、ncies 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 operations can have radically different costs. Randomly accessing elements in an ArrayList is a constant-time operation; i

26、t 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 longer to find an element that is further down the list. On the other hand, if you want to insert an element in the midd

27、le 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. In the design phase, you might start with a LinkedList and, when tuning for performance, change to an ArrayList. Beca

28、use 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 objects in. If that cabinet solves all of your needs, it doesnt really matter how it is implemented (a basic concept wit

29、h 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 LinkedList might not matter. You might need only one type of sequence. You can even imagine the “perfect” container abstraction

30、, 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 prominent since the introduction of C+ is whether all classes should ultimately be inherited from a single base class. In J

31、ava (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 hierarchy are many. All objects in a singly rooted hierarchy have an interface in common, so they are all ultimately the

32、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 better and can be thought of as less restrictive, but when you want to do full-on object-oriented programming you must the

33、n 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 used. It requires effort (and possibly multiple inheritance) to work the new interface into your design. Is the extra “flexibility” of C+ worth it?