📄 chapter01.html
字号:
choice to use the singly-rooted hierarchy in common with most other
object-oriented programming
languages.</FONT><A NAME="_Toc375545201"></A><A NAME="_Toc408018398"></A><BR></P></DIV>
<A NAME="Heading31"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
Collection libraries and support <BR>for easy collection use</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Because a collection is a tool that
you’ll use frequently, it makes sense to have a library of collections
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 library, although it is fairly
limited in Java 1.0 and 1.1 (the Java 1.2 collections library, however,
satisfies most needs).</FONT><BR></P></DIV>
<A NAME="Heading32"></A><FONT FACE = "Verdana"><H4 ALIGN="LEFT">
Downcasting vs. templates/generics</H4></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">To make these collections reusable,
they contain the one universal type in Java that was previously mentioned:
<B>Object</B>. The singly-rooted hierarchy means that everything is an
<B>Object</B>, so a collection that holds <B>Object</B>s can hold anything. This
makes it easy to reuse.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">To use such a collection, you
simply add object handles to it, and later ask for them back. But, since the
collection holds only <B>Object</B>s, when you add your object handle into the
collection it is upcast to <B>Object</B>, thus losing its identity. When you
fetch it back, you get an <B>Object</B> handle, and not a handle 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 collection?</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Here, the cast is used again, but
this time you’re not casting <I>up</I> the inheritance hierarchy to a more
general type, you cast <I>down</I> the hierarchy to a more specific type. This
manner of casting is called <I>downcasting</I>. With upcasting, you know, for
example, that a <B>Circle</B> is a type of <B>Shape</B> so it’s safe to
upcast, but you don’t know that an <B>Object</B> is necessarily a
<B>Circle</B> or a <B>Shape</B> so it’s hardly safe to downcast unless you
know that’s what you’re dealing with.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It’s not completely
dangerous, however, because if you downcast to the wrong thing you’ll get
a run-time error called an <I>exception,</I> which will be described shortly.
When you fetch object handles from a collection, though, you must have some way
to remember exactly what they are so you can perform a proper
downcast.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Downcasting and the run-time checks
require extra time for the running program, and extra effort from the
programmer. Wouldn’t it make sense to somehow create the collection so
that it knows the types that it holds, eliminating the need for the downcast and
possible mistake? The solution is <I>parameterized types</I>, which are classes
that the compiler can automatically customize to work with particular types. For
example, with a parameterized collection, the compiler could customize that
collection so that it would accept only <B>Shape</B>s and fetch only
<B>Shape</B>s.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">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 <B>template</B>. Java
currently has no parameterized types since it is possible for it to get by
– however awkwardly – using the singly-rooted hierarchy. At one
point the word <B>generic</B> (the keyword used by Ada for its templates) was on
a list of keywords that were “reserved for future implementation.”
Some of these seemed to have mysteriously slipped into a kind of “keyword
Bermuda Triangle” and it’s difficult to know what might eventually
happen.</FONT><A NAME="_Toc375545202"></A><A NAME="_Toc408018399"></A><BR></P></DIV>
<A NAME="Heading33"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
The housekeeping dilemma: <BR>who should clean up?</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Each object requires resources in
order to exist, most notably memory. When an object is no longer needed it must
be cleaned up so that these resources are released for reuse. In simple
programming situations the question of how an object is cleaned up doesn’t
seem too challenging: you create the object, use it for as long as it’s
needed, and then it should be destroyed. It’s not too hard, however, to
encounter situations in which the situation is more complex.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Suppose, for example, you are
designing a system to manage air traffic for an airport. (The same model might
also work for managing crates in a warehouse, or a video rental system, or a
kennel for boarding pets.) At first it seems simple: make a collection to hold
airplanes, then create a new airplane and place it in the collection for each
airplane that enters the air-traffic-control zone. For cleanup, simply delete
the appropriate airplane object when a plane leaves the zone.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">But perhaps you have some other
system to record data about the planes; perhaps data that doesn’t require
such immediate attention as the main controller function. Maybe it’s a
record of the flight plans of all the small planes that leave the airport. So
you have a second collection of small planes, and whenever you create a plane
object you also put it in this collection if it’s a small plane. Then some
background process performs operations on the objects in this collection during
idle moments.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Now the problem is more difficult:
how can you possibly know when to destroy the objects? When you’re done
with the object, some other part of the system might not be. This same problem
can arise in a number of other situations, and in programming systems (such as
C++) in which you must explicitly delete an object when you’re done with
it this can become quite
complex.</FONT><A NAME="fnB6" HREF="#fn6">[6]</A><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">With Java, the garbage collector is
designed to take care of the problem of releasing the memory (although this
doesn’t include other aspects of cleaning up an object). The garbage
collector “knows” when an object is no longer in use, and it then
automatically releases the memory for that object. This, combined with the fact
that all objects are inherited from the single root class <B>Object</B> and that
you can create objects only one way, on the heap, makes the process of
programming in Java much simpler than programming in C++. You have far fewer
decisions to make and hurdles to overcome.</FONT><BR></P></DIV>
<A NAME="Heading34"></A><FONT FACE = "Verdana"><H4 ALIGN="LEFT">
Garbage collectors <BR>vs. efficiency and flexibility</H4></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If all this is such a good idea,
why didn’t they do the same thing in C++? Well of course there’s a
price you pay for all this programming convenience, and that price is run-time
overhead. As mentioned before, in C++ you can create objects on the stack, and
in this case they’re automatically cleaned up (but you don’t have
the flexibility of creating as many as you want at run-time). Creating objects
on the stack is the most efficient way to allocate storage for objects and to
free that storage. Creating objects on the heap can be much more expensive.
Always inheriting from a base class and making all function calls polymorphic
also exacts a small toll. But the garbage collector is a particular problem
because you never quite know when it’s going to start up or how long it
will take. This means that there’s an inconsistency in the rate of
execution of a Java program, so you can’t use it in certain situations,
such as when the rate of execution of a program is uniformly critical. (These
are generally called <I>real time </I>programs, although not all real-time
programming problems are this
stringent.)</FONT><A NAME="fnB7" HREF="#fn7">[7]</A><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The designers of the C++ language,
trying to woo C programmers (and most successfully, at that), did not want to
add any features to the language that would impact the speed or the use of C++
in any situation where C might be used. This goal was realized, but at the price
of greater complexity when programming in C++. Java is simpler than C++, but the
tradeoff is in efficiency and sometimes applicability. For a significant portion
of programming problems, however, Java is often the superior
choice.</FONT><A NAME="_Toc375545203"></A><A NAME="_Toc408018400"></A><BR></P></DIV>
<A NAME="Heading35"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Exception handling: <BR>dealing with errors</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Ever since the beginning of
programming languages, error handling has been one of the most difficult issues.
Because it’s so hard to design a good error-handling scheme, many
languages simply ignore the issue, passing the problem on to library designers
who come up with halfway measures that can work in many situations but can
easily be circumvented, generally by just ignoring them. A major problem with
most error-handling schemes is that they rely on programmer vigilance in
following an agreed-upon convention that is not enforced by the language. If the
programmer is not vigilant, which is often if they are in a hurry, these schemes
can easily be forgotten.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia"><I>Exception handling</I> wires
error handling directly into the programming language and sometimes even the
operating system. An exception is an object that is “thrown” from
the site of the error and can be “caught” by an appropriate
<I>exception handler</I> designed to handle that particular type of error.
It’s as if exception handling is a different, parallel path of execution
that can be taken when things go wrong. And because it uses a separate execution
path, it doesn’t need to interfere with your normally-executing code. This
makes that code simpler to write since you aren’t constantly forced to
check for errors. In addition, a thrown exception is unlike an error value
that’s returned from a function or a flag that’s set by a function
in order to indicate an error condition, These can be ignored. An exception
cannot be ignored so it’s guaranteed to be dealt with at some point.
Finally, exceptions provide a way to reliably recover from a bad situation.
Instead of just exiting you are often able to set things right and restore the
execution of a program, which produces much more robust
programs.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Java’s exception handling
stands out among programming languages, because in Java, exception-handling was
wired in from the beginning and you’re <I>forced</I> to use it. If you
don’t write your code to properly handle exceptions, you’ll get a
compile-time error message. This guaranteed consistency makes error-handling
much easier.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It’s worth noting that
exception handling isn’t an object-oriented feature, although in
object-oriented languages the exception is normally represented with an object.
Exception handling existed before object-oriented
languages.</FONT><A NAME="_Toc375545204"></A><A NAME="_Toc408018401"></A><BR></P></DIV>
<A NAME="Heading36"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Multithreading</H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">A fundamental concept in computer
programming is the idea of handling more than one task at a time. Many
programming problems require that the program be able to stop what it’s
doing, deal with some other problem and return to the main process. The solution
has been approached in many ways. Initially, programmers with low-level
knowledge of the machine wrote <I>interrupt service routines</I> and the
suspension of the main process was initiated through a hardware interrupt.
Although this worked well, it was difficult and non-portable, so it made moving
a program to a new type of machine slow and expensive. </FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Sometimes interrupts are necessary
for handling time-critical tasks, but there’s a large class of problems in
which you’re simply trying to partition the problem into
separately-running pieces so that the whole program can be more responsive.
Within a program, these separately-running pieces are called <I>threads</I> and
the general concept is called <I>multithreading</I>. A common example of
multithreading is the user interface. By using threads, a user can press a
button and get a quick response rather than being forced to wait until the
program finishes its current task.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Ordinarily, threads are⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -