tij318.htm

这也是我们java老师给我们的thinking in java的一些资料

href="mailto:[e-mail]?Subject=[TIJ3]Chap01_279" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>The &#147;collaborations&#148; of the class: What other classes does it
interact with? &#147;Interact&#148; is an intentionally broad term; it could
mean aggregation or simply that some other object exists that will perform
services for an object of the class. Collaborations should also consider the
audience for this class. For example, if you create a class <b>Firecracker</b>,
who is going to observe it, a <b>Chemist</b> or a <b>Spectator</b>? The former
will want to know what chemicals go into the construction, and the latter will
respond to the colors and shapes released when it explodes. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap01_280" title="Send BackTalk
Comment">Feedback</a></font></li></ol><p>You may feel that the cards should be bigger because of all the information you&#146;d like to get on them. However, they are intentionally small, not only to keep your classes small but also to keep you from getting into too much detail too early. If you can&#146;t fit all you need to know about a class on a small card, then the class is too complex (either you&#146;re getting too detailed, or you should create more than one class). The ideal class should be understood at a glance. The idea of CRC cards is to assist you in coming up with a first cut of the design so that you can get the big picture and then refine your design. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_281" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>One of the great benefits of CRC cards is in communication. It&#146;s best done in real time, in a group, without computers. Each person takes responsibility for several classes (which at first have no names or other information). You run a live simulation by solving one scenario at a time, deciding which messages are sent to the various objects to satisfy each scenario. As you go through this process, you discover the classes that you need along with their responsibilities and collaborations, and you fill out the cards as you do this. When you&#146;ve moved through all the use cases, you should have a fairly complete first cut of your design. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_282" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Before I began using CRC cards, the most successful consulting experiences I had when coming up with an initial design involved standing in front of a team&#151;who hadn&#146;t built an OOP project before&#151;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. Effectively, I was managing all the &#147;CRC cards&#148; on the whiteboard. The team (who knew what the project was supposed to do) actually created the design; they &#147;owned&#148; 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 size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_283" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Once you&#146;ve come up with a set of CRC cards, you may want to create a more formal description of your design using UML.<sup><a name="fnB109" href="#fn109">[109]</a></sup> You don&#146;t need to use UML, but it can be helpful, especially if you want to put up a diagram on the wall for everyone to ponder, which is a good idea (there is a plethora of UML diagramming tools available). An alternative to UML is a textual description of the objects and their interfaces, or, depending on your programming language, the code itself.<a name="Index2100"></a><sup><a name="fnB110" href="#fn110">[110]</a></sup> <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_284" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>UML also provides an additional diagramming notation for describing the dynamic model of your system. This is helpful in situations in which the state transitions of a system or subsystem are dominant enough that they need their own diagrams (such as in a control system). You may also need to describe the data structures, for systems or subsystems in which data is a dominant factor (such as a database). <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_285" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>You&#146;ll know you&#146;re done with Phase 2 when you have described the objects and their interfaces. Well, most of them&#151;there are usually a few that slip through the cracks and don&#146;t make themselves known until Phase 3. But that&#146;s OK. What&#146;s important is that you eventually discover all of your objects. It&#146;s nice to discover them early in the process, but OOP provides enough structure so that it&#146;s not so bad if you discover them later. In fact, the design of an object tends to happen in five stages, throughout the process of program development. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_286" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc408018413"></a><a name="_Toc312373799"></a><a name="_Toc24775975"></a><a name="Heading24402"></a>Five
stages of object design<br></h3>
<p><a name="Index2102"></a><a name="Index2103"></a>The design life of an object is not limited to the time when you&#146;re writing the program. Instead, the design of an object appears over a sequence of stages. It&#146;s helpful to have this perspective because you stop expecting perfection right away; instead, you realize that the understanding of what an object does and what it should look like happens over time. This view also applies to the design of various types of programs; the pattern for a particular type of program emerges through struggling again and again with that problem (which is chronicled in the book <i>Thinking in Patterns (with Java)</i> at <i>www.BruceEckel.com</i>). Objects, too, have their patterns that emerge through understanding, use, and reuse. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_287" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><b>1. Object discovery. </b>This stage occurs during the initial analysis of a program. Objects may be discovered by looking for external factors and boundaries, duplication of elements in the system, and the smallest conceptual units. Some objects are obvious if you already have a set of class libraries. Commonality between classes suggesting base classes and inheritance may appear right away, or later in the design process. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_288" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><b>2. Object assembly. </b>As you&#146;re building an object you&#146;ll discover the need for new members that didn&#146;t appear during discovery. The internal needs of the object may require other classes to support it. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_289" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><b>3. System construction. </b>Once again, more requirements for an object may appear at this later stage. As you learn, you evolve your objects. The need for communication and interconnection with other objects in the system may change the needs of your classes or require new classes. For example, you may discover the need for facilitator or helper classes, such as a linked list, that contain little or no state information and simply help other classes function. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_290" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><b>4. System extension. </b>As you add new features to a system you may discover that your previous design doesn&#146;t support easy system extension. With this new information, you can restructure parts of the system, possibly adding new classes or class hierarchies. This is also a good time to consider taking features <i>out</i> of a project. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_291" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><b>5. Object reuse. </b><a name="Index2104"></a>This is the real stress test for a class. If someone tries to reuse the class in an entirely new situation, they&#146;ll probably discover some shortcomings. As you change it to adapt to more new programs, the general principles of the class will become clearer, until you have a truly reusable type. However, don&#146;t expect most objects from a system design to be reusable&#151;it is perfectly acceptable for the bulk of your objects to be system-specific. Reusable types tend to be less common, and they must solve more general problems in order to be reusable. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_292" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc24775976"></a><a name="Heading24409"></a>Guidelines for object
development<br></h3>
<p><a name="Index2105"></a><a name="Index2106"></a>These stages suggest some guidelines when thinking about developing your classes: <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_293" title="Send BackTalk Comment">Feedback</a></font><br></p>
<ol>
<li>Let a specific problem generate a class, then let the class grow and mature
during the solution of other problems. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap01_294" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>Remember, discovering the classes you need (and their interfaces) is the
majority of the system design. If you already had those classes, this would be
an easy project. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap01_295" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>Don&#146;t force yourself to know everything at the beginning. Learn as you
go. This will happen anyway. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap01_296" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>Start programming. Get something working so you can prove or disprove your
design. Don&#146;t fear that you&#146;ll end up with procedural-style
spaghetti code&#151;classes partition the problem and help control anarchy and