tij0029.html

学习java的经典书籍

</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
(UML). You can get the specification for UML at 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>www.rational.com</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
UML can also be helpful as a descriptive tool during phase 1, and some of the
diagrams you create there will probably show up unmodified in phase 2. You
don&#8217;t need to use UML, but it can be helpful, especially if you want to
put a diagram up on the wall for everyone to ponder, which is a good idea. An
alternative to UML is a textual description of the objects and their interfaces
(as I described in 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>Thinking
in C++
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">),
but this can be limiting.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
most successful consulting experiences I&#8217;ve had when coming up with an
initial design involves standing in front of a team, who hadn&#8217;t built an
OOP project before, and drawing objects on a whiteboard. We talked about how
the objects should communicate with each other, and erased some of them and
replaced them with other objects. The team (who knew what the project was
supposed to do) actually created the design; they &#8220;owned&#8221; the
design rather than having it given to them. All I was doing was guiding the
process by asking the right questions, trying out the assumptions and taking
the feedback from the team to modify those assumptions. The true beauty of the
process was that the team learned how to do object-oriented design not by
reviewing abstract examples, but by working on the one design that was most
interesting to them at that moment: theirs.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">You&#8217;ll
know you&#8217;re done with phase 2 when you have described the objects and
their interfaces. Well, most of them &#8211; there are usually a few that slip
through the cracks and don&#8217;t make themselves known until phase 3. But
that&#8217;s OK. All you are concerned with is that you eventually discover all
of your objects. It&#8217;s nice to discover them early in the process but OOP
provides enough structure so that it&#8217;s not so bad if you discover them
later.
</FONT><a name="_Toc408018413"></a><P></DIV>
<A NAME="Heading57"></A><H3 ALIGN=LEFT>
Phase
3: Let&#8217;s build it!
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">If
you&#8217;re reading this book you&#8217;re probably a programmer, so now
we&#8217;re at the part you&#8217;ve been trying to get to. By following a plan
&#8211; no matter how simple and brief &#8211; and coming up with design
structure before coding, you&#8217;ll discover that things fall together far
more easily than if you dive in and start hacking, and this provides a great
deal of satisfaction. Getting code to run and do what you want is fulfilling,
even like some kind of drug if you look at the obsessive behavior of some
programmers. But it&#8217;s my experience that coming up with an elegant
solution is deeply satisfying at an entirely different level; it feels closer
to art than technology. And <A NAME="Index67"></A>elegance
always pays off; it&#8217;s not a frivolous pursuit. Not only does it give you
a program that&#8217;s easier to build and debug, but it&#8217;s also easier to
understand and maintain, and that&#8217;s where the financial value lies.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">After
you build the system and get it running, it&#8217;s important to do a reality
check, and here&#8217;s where the requirements analysis and system
specification comes in. Go through your program and make sure that all the
requirements are checked off, and that all the use-cases work the way
they&#8217;re described. Now you&#8217;re done. Or are you?
</FONT><a name="_Toc408018414"></a><P></DIV>
<A NAME="Heading58"></A><H3 ALIGN=LEFT>
Phase
4: Iteration
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">This
is the point in the development cycle that has traditionally been called
&#8220;maintenance,&#8221; a catch-all term that can mean everything from
&#8220;getting it to work the way it was really supposed to in the first
place&#8221; to &#8220;adding features that the customer forgot to mention
before&#8221; to the more traditional &#8220;fixing the bugs that show
up&#8221; and &#8220;adding new features as the need arises.&#8221; So many
misconceptions have been applied to the term &#8220;maintenance&#8221; that it
has taken on a slightly deceiving quality, partly because it suggests that
you&#8217;ve actually built a pristine program and that all you need to do is
change parts, oil it and keep it from rusting. Perhaps there&#8217;s a better
term to describe what&#8217;s going on.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">The
term is <A NAME="Index68"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>iteration</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
That is, &#8220;You won&#8217;t get it right the first time, so give yourself
the latitude to learn and to go back and make changes.&#8221; You might need to
make a lot of changes as you learn and understand the problem more deeply. The
elegance you&#8217;ll produce if you iterate until you&#8217;ve got it right
will pay off, both in the short and the long run.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">What
it means to &#8220;get it right&#8221; isn&#8217;t just that the program works
according to the requirements and the use-cases. It also means that the
internal structure of the code makes sense to you, and feels like it fits
together well, with no awkward syntax, oversized objects or ungainly exposed
bits of code. In addition, you must have some sense that the program structure
will survive the changes that it will inevitably go through during its
lifetime, and that those changes can be made easily and cleanly. This is no
small feat. You must not only understand what you&#8217;re building, but also
how the program will evolve (what I call the <A NAME="Index69"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>vector
of change
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">).
Fortunately, object-oriented programming languages are particularly adept at
supporting this kind of continuing modification &#8211; the boundaries created
by the objects are what tend to keep the structure from breaking down. They are
also what allow you to make changes that would seem drastic in a procedural
program without causing earthquakes throughout your code. In fact, support for
iteration might be the most important benefit of OOP.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">With
iteration, you create something that at least approximates what you think
you&#8217;re building, and then you kick the tires, compare it to your
requirements and see where it falls short. Then you can go back and fix it by
redesigning and re-implementing the portions of the program that didn&#8217;t
work right.
</FONT><A NAME="fnB10" HREF="#fn10">[10]</A><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
You might actually need to solve the problem, or an aspect of the problem,
several times before you hit on the right solution. (A study of 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>Design
Patterns
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">,
described in Chapter 16, is usually helpful here.)
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Iteration
also occurs when you build a system, see that it matches your requirements and
then discover it wasn&#8217;t actually what you wanted. When you see the
system, you realize you want to solve a different problem. If you think this
kind of iteration is going to happen, then you owe it to yourself to build your
first version as quickly as possible so you can find out if it&#8217;s what you
want.
</FONT><P></DIV><DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Iteration
is closely tied to <A NAME="Index70"></A></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>incremental
development
</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">.
Incremental development means that you start with the core of your system and
implement it as a framework upon which to build the rest of the system piece by
piece. Then you start adding features one at a time. The trick to this is in
designing a framework that will accommodate all the features you plan to add to
it. (See Chapter 16 for more insight into this issue.) The advantage is that
once you get the core framework working, each feature you add is like a small
project in itself rather than part of a big project. Also, new features that
are incorporated later in the development or maintenance phases can be added
more easily. OOP supports incremental development because if your program is
designed well, your increments will turn out to be discreet objects or groups
of objects.
</FONT><a name="_Toc408018415"></a><P></DIV>
<A NAME="Heading59"></A><H3 ALIGN=LEFT>
Plans
pay off
</H3>
<DIV ALIGN=LEFT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">Of
course you wouldn&#8217;t build a house without a lot of carefully-drawn plans.
If you build a deck or a dog house, your plans won&#8217;t be so elaborate but
you&#8217;ll still probably start with some kind of sketches to guide you on
your way. Software development has gone to extremes. For a long time, people
didn&#8217;t have much structure in their development, but then big projects
began failing. In reaction, we ended up with methodologies that had an
intimidating amount of structure and detail. These were too scary to use
&#8211; it looked like you&#8217;d spend all your time writing documents and no
time programming. (This was often the case.) I hope that what I&#8217;ve shown
you here suggests a middle path &#8211; a sliding scale. Use an approach that
fits your needs (and your personality). No matter how minimal you choose to
make it, 
</FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black"><I>some</I></FONT><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
kind of plan will make a big improvement in your project as opposed to no plan
at all. Remember that, by some estimates, over 50 percent of projects fail.
</FONT><a name="_Toc375545210"></a><a name="_Toc408018416"></a><P></DIV>
<HR><DIV ALIGN=LEFT><A NAME="fn9" HREF="#fnB9">[9]</A><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">
The best introduction is still Grady Booch&#8217;s 
</FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black"><I>Object-Oriented
Design with Applications
</I></FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">,
2
</FONT><SUP><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">nd</FONT></SUP><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">
edition, Wiley &amp; Sons 1996. His insights are clear and his prose is
straightforward, although his notations are needlessly complex for most
designs. (You can easily get by with a subset.)
</FONT><P></DIV>
<DIV ALIGN=LEFT><A NAME="fn10" HREF="#fnB10">[10]</A><FONT FACE="Carmina Md BT" SIZE=3 COLOR="Black">
</FONT><FONT FACE="Carmina Md BT" SIZE=2 COLOR="Black">This
is something like &#8220;rapid prototyping,&#8221; where you were supposed to
build a quick-and-dirty version so that you could learn about the system, and
then throw away your prototype and build it right. The trouble with rapid
prototyping is that people didn&#8217;t throw away the prototype, but instead
built upon it. Combined with the lack of structure in procedural programming,
this often leads to messy systems that are expensive to maintain.
</FONT><P></DIV>


<div align="right">
<a href="tij_c.html">Contents</a> | <a href="tij0028.html">Prev</a> | <a href="tij0030.html">Next</a>
</div>
</body></html>