📄 tij318.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">
<!--
This document was converted from RTF source:
By r2net 5.8 r2netcmd Windows
See http://www.logictran.com
-->
<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Thinking in Java, 3rd ed. Revision 4.0: 16: Analysis and Design</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css"></head>
<body >
<CENTER> <a href="http://www.MindView.net"> <img src="mindview.gif" alt="MindView Inc." BORDER = "0"></a> <Font FACE="Verdana, Tahoma, Arial, Helvetica, Sans"> <h2>Thinking in Java, 3<sup>rd</sup> ed. Revision 4.0</h2> <FONT size = "-1"><br> [ <a href="README.txt">Viewing Hints</a> ] [ <a href="http://www.mindview.net/Books/TIJ/">Book Home Page</a> ] [ <a href="http://www.mindview.net/Etc/MailingList.html">Free Newsletter</a> ] <br> [ <a href="http://www.mindview.net/Seminars">Seminars</a> ] [ <a href="http://www.mindview.net/CDs">Seminars on CD ROM</a> ] [ <a href="http://www.mindview.net/Services">Consulting</a> ] <br><br> </FONT></FONT> </CENTER>
<font face="Georgia"><div align="CENTER"><a href="TIJ317.htm" target="RightFrame"><img src="./prev.gif" alt="Previous " border="0"></a>
<a href="TIJ319.htm" target="RightFrame"><img src="./next.gif" alt="Next " border="0"></a>
<a href="TIJ3_t.htm"><img src="./first.gif" alt="Title Page " border="0"></a>
<a href="TIJ3_i.htm"><img src="./index.gif" alt="Index " border="0"></a>
<a href="TIJ3_c.htm"><img src="./contents.gif" alt="Contents " border="0"></a>
</div>
<hr>
<h1>
<a name="_Toc375545505"></a><a name="_Toc375545421"></a><a name="_Toc472654691"></a><a name="_Toc24272655"></a><a name="_Toc24775969"></a><a name="Heading24340"></a>16:
Analysis and Design</h1>
<p class="Intro">The object-oriented paradigm is a new and different way of thinking about programming.<br></p>
<p><a name="Index2072"></a><a name="Index2073"></a><a name="Index2074"></a><a name="Index2075"></a>Many people have trouble at first knowing how to approach an OOP project. Now that you understand the concept of an object, and as you learn to think more in an object-oriented style, you can begin to create “good” designs that take advantage of all the benefits that OOP has to offer. This chapter introduces the ideas of analysis, design, and some ways to approach the problems of developing good object-oriented programs in a reasonable amount of time. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_251" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc24775970"></a><a name="Heading24343"></a>Methodology<br></h2>
<p><a name="Index2076"></a>A <i>methodology</i> (sometimes simply called a <i>method</i>)<i> </i>is a set of processes and heuristics used to break down the complexity of a programming problem. Many OOP methodologies have been formulated since the dawn of object-oriented programming. This section will give you a feel for what you’re trying to accomplish when using a methodology. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_252" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Especially in OOP, methodology is a field of many experiments, so it is important to understand what problem the methodology is trying to solve before you consider adopting one. This is particularly true with Java, 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, simple methodologies may suffice in Java for a much larger class of problems than you could handle using simple methodologies with procedural languages. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_253" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>It’s also important to realize that the term “methodology” is often too grand and promises too much. Whatever you do now when you design and write a program is a methodology. It may be your own methodology, 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 Java. If you are not satisfied with your productivity and the way your programs turn out, you may want to consider adopting a formal methodology, or choosing pieces from among the many formal methodologies.<i> </i><font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_254" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>While you’re going through the development process, the most important issue is this: Don’t get lost. It’s easy to do. Most of the analysis and design methodologies are intended to solve the largest of problems. Remember that most projects don’t fit into that category, so you can usually have successful analysis and design with a relatively small subset of what a methodology recommends.<a name="Index2077"></a><sup><a name="fnB102" href="#fn102">[102]</a></sup> But some sort of process, no matter how small or limited, will generally get you on your way in a much better fashion than simply beginning to code. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_255" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>It’s also easy to get stuck, to fall into “analysis paralysis,” where you feel like you can’t move forward because you haven’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’t reveal themselves until design time, and more things that won’t reveal themselves until you’re coding, or not even until a program is up and running. Because of this, it’s crucial to move fairly quickly through analysis and design, and to implement a test of the proposed system. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_256" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index2079"></a><a name="Index2080"></a>This point is worth emphasizing. Because of the history we’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 Database Management System (<i>DBMS</i>), it pays to understand a customer’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 “wild-card” (my term) variety, in which the solution isn’t simply re-forming a well-known solution, but instead involves one or more “wild-card<a name="Index2081"></a> factors”—elements for which there is no well-understood previous solution, and for which research is necessary.<sup><a name="fnB103" href="#fn103">[103]</a></sup> Attempting to thoroughly analyze a wild-card problem before moving into design and implementation results in analysis paralysis because you don’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’re trying to do something new and the potential rewards are higher). It may seem like the risk is compounded by “rushing” into a preliminary implementation, but it can instead reduce the risk in a wild-card project because you’re finding out early whether a particular approach to the problem is viable. Product development is risk management. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_257" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>It’s often proposed that you “build one to throw away.” With OOP, you may still throw <i>part</i> of it away, but because code is encapsulated into classes, during the first pass 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 pass, it also creates a code foundation. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_258" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>That said, if you’re looking at a methodology that contains tremendous detail and suggests many steps and documents, it’s still difficult to know when to stop. Keep in mind what you’re trying to discover: <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_259" title="Send BackTalk Comment">Feedback</a></font><br></p>
<ol>
<li>What are the objects? (How do you partition your project into its component
parts?)</li>
<li>What are their interfaces? (What messages do you need to send to each
object?)</li></ol><p>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’t get away with any less. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_260" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>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 size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_261" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc408018410"></a><a name="_Toc472654692"></a><a name="_Toc24775971"></a><a name="Heading24358"></a>Phase
0: Make a plan</h2>
<p>You must first decide what steps you’re going to have in your process. It sounds simple (in fact, <i>all</i> of this sounds simple), and yet people often don’t make this decision before they start coding. If your plan is “let’s jump in and start coding,” fine. (Sometimes that’s appropriate when you have a well-understood problem.) At least agree that this is the plan. <font size="-2"><a href="mailto:TIJ3@MindView.net?Subject=[TIJ3]Chap01_262" title="Send BackTalk Comment">Feedback</a></font><br></p>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -