【正文】 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 Shape so it’s hardly safe to downcast unless you know that’s what you’re dealing with. It’s not pletely dangerous, however, because if you downcast to the wrong thing you’ll get a runtime error called 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. Downcasting and the runtime 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 holds, eliminating the need for the downcast and a possible mistake? The solution is parameterized types, which are classes that the piler can automatically customize to work with particular types. For example, with a parameterized container, the piler could customize that container so that it would accept 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 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. 譯文 對象的創(chuàng)建和存在時間 從技術角度說， OOP（面向?qū)ο蟪绦蛟O計）只是涉及抽象的數(shù)據(jù)類型、繼承以及多形性，但另一些問題也可能顯得非常重要。s the lifetime of an object. With languages that allow objects to be created on the stack, the piler determines how long the object lasts and can automatically destroy it. However, if you create it on the heap the piler 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 don’t do it correctly (and this is a mon problem 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, the 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 iterators If you don’t know how many objects you’re going to need to solve a particular problem, or how long they will 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 runtime. The solution to most problems in objectoriented 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 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 “container”), will expand itself whenever necessary to acmodate everything you place inside it. So you don’t need to know how manyobjects you’re going to hold in a container. Just create a container object and let it take care of the details. Fortunately, a good OOP language es with a set of containers as part of the package. In C++, it’s 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