chapter01.html

《C++编程思想》中文版。。。。。。。。。。。。。

will not have an important impact on the creation of an object. In addition, the
greater flexibility is essential to solve general programming
problems.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">There&#8217;s another issue, however, and
that&#8217;s the <A NAME="Index158"></A><A NAME="Index159"></A>lifetime of an
object. If you create an object on the stack or in static storage, 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
C++, the programmer must determine programmatically when to destroy the object,
and then perform the destruction using the <B>delete</B> keyword. As an
alternative, the environment can provide a feature called a
<A NAME="Index160"></A><A NAME="Index161"></A><I>garbage collector</I> that
automatically discovers when an object is no longer in use and destroys it. Of
course, writing programs using a garbage collector is much more convenient, but
it requires that all applications must be able to tolerate the existence of the
garbage collector and the overhead for garbage collection. This does not meet
the design requirements of the C++ language and so it was not included, although
third-party garbage collectors exist for
C++.</FONT><A NAME="_Toc375545203"></A><A NAME="_Toc408018400"></A><A NAME="_Toc375545198"></A><A NAME="_Toc408018395"></A><A NAME="_Toc408018408"></A><A NAME="_Toc312373795"></A><A NAME="_Toc472654690"></A><BR></P></DIV>
<A NAME="Heading29"></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&#8217;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 programmers are
not vigilant, which often occurs when they are in a hurry, these schemes can
easily be forgotten.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index162"></A><A NAME="Index163"></A><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
&#8220;thrown&#8221; from the site of the error and can be &#8220;caught&#8221;
by an appropriate <I>exception handler</I> designed to handle that particular
type of error. It&#8217;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&#8217;t need to interfere with your
normally-executing code. This makes that code simpler to write since you
aren&#8217;t constantly forced to check for errors. In addition, a thrown
exception is unlike an error value that&#8217;s returned from a function or a
flag that&#8217;s set by a function in order to indicate an error condition
&#8211; these can be ignored. An exception cannot be ignored so it&#8217;s
guaranteed to be dealt with at some point. Finally, exceptions provide a way to
recover reliably from a bad situation. Instead of just exiting the program, you
are often able to set things right and restore the execution of a program, which
produces much more robust systems.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It&#8217;s worth noting that exception
handling isn&#8217;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><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Exception handling is only lightly
introduced and used in this Volume; Volume 2 (available from
<I>www.BruceEckel.com</I>) has thorough coverage of exception
handling.</FONT><A NAME="_Toc472654691"></A><BR></P></DIV>
<A NAME="Heading30"></A><FONT FACE = "Verdana"><H2 ALIGN="LEFT">
Analysis and
design<BR><A NAME="Index164"></A><A NAME="Index165"></A><A NAME="Index166"></A><A NAME="Index167"></A></H2></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The object-oriented paradigm is a new and
different way of thinking about programming and many folks have trouble at first
knowing how to approach an OOP project. Once you know that everything is
supposed to be an object, and as you learn to think more in an object-oriented
style, you can begin to create &#8220;good&#8221; designs that take advantage of
all the benefits that OOP has to offer.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><A NAME="Index168"></A><FONT FACE="Georgia">A <I>method</I>
(often called a <I>methodology</I>)<I> </I>is a set of processes and heuristics
used to break down the complexity of a programming problem. Many OOP methods
have been formulated since the dawn of object-oriented programming. This section
will give you a feel for what you&#8217;re trying to accomplish when using a
method.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Especially in OOP, methodology is a field
of many experiments, so it is important to understand what problem the method is
trying to solve before you consider adopting one. This is particularly true with
C++, in which the programming language is intended to reduce the complexity
(compared to C) involved in expressing a program. This may in fact alleviate the
need for ever-more-complex methodologies. Instead, simpler ones may suffice in
C++ for a much larger class of problems than you could handle using simple
methodologies with procedural languages.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It&#8217;s also important to realize that
the term &#8220;methodology&#8221; is often too grand and promises too much.
Whatever you do now when you design and write a program is a method. It may be
your own method, and you may not be conscious of doing it, but it is a process
you go through as you create. If it is an effective process, it may need only a
small tune-up to work with C++. If you are not satisfied with your productivity
and the way your programs turn out, you may want to consider adopting a formal
method, or choosing pieces from among the many formal methods.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">While you&#8217;re going through the
development process, the most important issue is this: Don&#8217;t get lost.
It&#8217;s easy to do. Most of the analysis and design
<A NAME="Index169"></A>methods are intended to solve the largest of problems.
Remember that most projects don&#8217;t fit into that category, so you can
usually have successful analysis and design with a relatively small subset of
what a method
recommends</FONT><A NAME="fnB9" HREF="#fn9">[9]</A><A NAME="Index170"></A><FONT FACE="Georgia">.
But some sort of process, no matter how limited, will generally get you on your
way in a much better fashion than simply beginning to code.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It&#8217;s also easy to get stuck, to
fall into &#8220;<A NAME="Index171"></A><A NAME="Index172"></A>analysis
paralysis,&#8221; where you feel like you can&#8217;t move forward because you
haven&#8217;t nailed down every little detail at the current stage. Remember, no
matter how much analysis you do, there are some things about a system that
won&#8217;t reveal themselves until design time, and more things that
won&#8217;t reveal themselves until you&#8217;re coding, or not even until a
program is up and running. Because of this, it&#8217;s crucial to move fairly
quickly through analysis and design, and to implement a test of the proposed
system.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">This point is worth emphasizing. Because
of the history we&#8217;ve had with procedural languages, it is commendable that
a team will want to proceed carefully and understand every minute detail before
moving to design and implementation. Certainly, when creating a DBMS, it pays to
understand a customer&#8217;s needs thoroughly. But a DBMS is in a class of
problems that is very well-posed and well-understood; in many such programs, the
database structure <I>is</I> the problem to be tackled. The class of programming
problem discussed in this chapter is of the &#8220;wild-card&#8221; (my term)
variety, in which the solution isn&#8217;t simply re-forming a well-known
solution, but instead involves one or more
&#8220;wild-card<A NAME="Index173"></A> factors&#8221; &#8211; elements for
which there is no well-understood previous solution, and for which research is
necessary</FONT><A NAME="fnB10" HREF="#fn10">[10]</A><FONT FACE="Georgia">.
Attempting to thoroughly analyze a wild-card problem before moving into design
and implementation results in analysis paralysis because you don&#8217;t have
enough information to solve this kind of problem during the analysis phase.
Solving such a problem requires iteration through the whole cycle, and that
requires risk-taking behavior (which makes sense, because you&#8217;re trying to
do something new and the potential rewards are higher). It may seem like the
risk is compounded by &#8220;rushing&#8221; into a preliminary implementation,
but it can instead reduce the risk in a wild-card project because you&#8217;re
finding out early whether a particular approach to the problem is viable.
Product development is risk management.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">It&#8217;s often proposed that you
&#8220;build one to throw away.&#8221; With OOP, you may still throw <I>part</I>
of it away, but because code is encapsulated into classes, during the first
iteration you will inevitably produce some useful class designs and develop some
worthwhile ideas about the system design that do not need to be thrown away.
Thus, the first rapid pass at a problem not only produces critical information
for the next analysis, design, and implementation iteration, it also creates a
code foundation for that iteration.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">That said, if you&#8217;re looking at a
methodology that contains tremendous detail and suggests many steps and
documents, it&#8217;s still difficult to know when to stop. Keep in mind what
you&#8217;re trying to discover:</FONT><BR></P></DIV>
<OL>
<LI><FONT FACE="Verdana">	</FONT><FONT FACE="Georgia">What are the objects? (How
do you partition your project into its component
parts?)</FONT><LI><FONT FACE="Verdana">	</FONT><FONT FACE="Georgia">What are
their interfaces? (What messages do you need to be able to send to each
object?)</FONT></OL><DIV ALIGN="LEFT"><P><FONT FACE="Georgia">If you come up with
nothing more than the objects and their interfaces, then you can write a
program. For various reasons you might need more descriptions and documents than
this, but you can&#8217;t get away with any less.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">The process can be undertaken in five
phases, and a phase 0 that is just the initial commitment to using some kind of
structure.</FONT><A NAME="_Toc408018410"></A><A NAME="_Toc472654692"></A><BR></P></DIV>
<A NAME="Heading31"></A><FONT FACE = "Verdana"><H3 ALIGN="LEFT">
Phase 0: Make a plan</H3></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You must first decide what steps
you&#8217;re going to have in your process. It sounds simple (in fact,
<I>all</I> of this sounds simple) and yet people often don&#8217;t make this
decision before they start coding. If your plan is &#8220;let&#8217;s jump in
and start coding,&#8221; fine. (Sometimes that&#8217;s appropriate when you have
a well-understood problem.) At least agree that this is the
<A NAME="Index174"></A>plan.</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">You might also decide at this phase that
some additional process structure is necessary, but not the whole nine yards.
Understandably enough, some programmers like to work in &#8220;vacation
mode&#8221; in which no structure is imposed on the process of developing their
work; &#8220;It will be done when it&#8217;s done.&#8221; This can be appealing
for awhile, but I&#8217;ve found that having a few milestones along the way
helps to focus and galvanize your efforts around those milestones instead of
being stuck with the single goal of &#8220;finish the project.&#8221; In
addition, it divides the project into more bite-sized pieces and makes it seem
less threatening (plus the milestones offer more opportunities for
celebration).</FONT><BR></P></DIV>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">When I began to study story structure (so
that I will someday write a novel) I was initially resistant to the idea of
structure, feeling that when I wrote I simply let it flow onto the page. But I
later realized that when I write about computers the structure is clear enough
so that I don&#8217;t think much about it. But I still structure my work, albeit
only semi-consciously in my head. So even if you think that your plan is to just
start coding, you still somehow go through the subsequent phases while asking
and answering certain questions.</FONT><A NAME="_Toc408018411"></A><BR></P></DIV>
<A NAME="Heading32"></A><FONT FACE = "Verdana"><H4 ALIGN="LEFT">
The mission statement<BR><A NAME="Index175"></A><A NAME="Index176"></A></H4></FONT>
<DIV ALIGN="LEFT"><P><FONT FACE="Georgia">Any system you build, no matter ho