tij318.htm

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

entropy. Bad classes do not break good classes. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap01_297" title="Send BackTalk
Comment">Feedback</a></font></li>
<li>Always keep it simple. Little clean objects with obvious utility are better
than big complicated interfaces. When decision points come up, use an
Ockham&#146;s Razor<sup><a name="fnB111" href="#fn111">[111]</a></sup>
approach: Consider the choices and select the one that is simplest, because
simple classes are almost always best. Start small and simple, and you can
expand the class interface when you understand it better. It&#146;s easy to add
methods, but as time goes on, it&#146;s difficult to remove methods from a
class. <font size="-2"><a
href="mailto:[e-mail]?Subject=[TIJ3]Chap01_298" title="Send BackTalk
Comment">Feedback</a></font></li></ol><h2>
<a name="_Toc472654695"></a><a name="_Toc24775977"></a><a name="Heading24417"></a>Phase
3: Build the core</h2>
<p>This is the initial conversion from the rough design into a compiling and executing body of code that can be tested, and especially that will prove or disprove your architecture. This is not a one-pass process, but rather the beginning of a series of steps that will iteratively build the system, as you&#146;ll see in Phase 4. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_299" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Your goal is to find the core of your system architecture that needs to be implemented in order to generate a running system, no matter how incomplete that system is in this initial pass. You&#146;re creating a framework that you can build on with further iterations. You&#146;re also performing the first of many system integrations and tests, and giving the stakeholders feedback about what their system will look like and how it is progressing. Ideally, you are exposing some of the critical risks. You&#146;ll probably discover changes and improvements that can be made to your original architecture&#151;things you would not have learned without implementing the system. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_300" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Part of building the system is the reality check that you get from testing against your requirements analysis and system specification (in whatever form they exist). Make sure that your tests verify the requirements and use cases. When the core of the system is stable, you&#146;re ready to move on and add more functionality. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_301" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc408018414"></a><a name="_Toc472654696"></a><a name="_Toc24775978"></a><a name="Heading24421"></a>Phase
4: Iterate the use cases</h2>
<p><a name="Index2107"></a>Once the core framework is running, each feature set you add is a small project in itself. You add a feature set during an <a name="Index2108"></a><i>iteration</i>, a reasonably short period of development. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_302" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>How big is an iteration? Ideally, each iteration lasts one to three weeks (this can vary based on the implementation language). At the end of that period, you have an integrated, tested system with more functionality than it had before. But what&#146;s particularly interesting is the basis for the iteration: a single use case. Each use case is a package of related functionality that you build into the system all at once, during one iteration. Not only does this give you a better idea of what the scope of a use case should be, but it also gives more validation to the idea of a use case, since the concept isn&#146;t discarded after analysis and design, but instead it is a fundamental unit of development throughout the software-building process. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_303" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index2109"></a><a name="Index2110"></a>You stop iterating when you achieve target functionality or an external deadline arrives and the customer can be satisfied with the current version. (Remember, software is a subscription business.) Because the process is iterative, you have many opportunities to ship a product rather than having a single endpoint; open-source projects work exclusively in an iterative, high-feedback environment, which is precisely what makes them successful. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_304" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>An iterative development process is valuable for many reasons. You can reveal and resolve critical risks early, the customers have ample opportunity to change their minds, programmer satisfaction is higher, and the project can be steered with more precision. But an additional important benefit is the feedback to the stakeholders, who can see by the current state of the product exactly where everything lies. This may reduce or eliminate the need for mind-numbing status meetings and increase the confidence and support from the stakeholders. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_305" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc472654697"></a><a name="_Toc24775979"></a><a name="Heading24426"></a>Phase
5: Evolution</h2>
<p><a name="Index2111"></a>This is the point in the development cycle that has traditionally been called &#147;maintenance,&#148; a catch-all term that can mean everything from &#147;getting it to work the way it was really supposed to in the first place&#148; to &#147;adding features that the customer forgot to mention&#148; to the more traditional &#147;fixing the bugs that show up&#148; and &#147;adding new features as the need arises.&#148; So many misconceptions have been applied to the term &#147;maintenance&#148; that it has taken on a slightly deceiving quality, partly because it suggests that you&#146;ve actually built a pristine program and all you need to do is change parts, oil it, and keep it from rusting. Perhaps there&#146;s a better term to describe what&#146;s going on. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_306" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="Index2112"></a><a name="Index2113"></a>I&#146;ll use the term <i>evolution.</i><sup><a name="fnB112" href="#fn112">[112]</a></sup> That is, &#147;You won&#146;t get it right the first time, so give yourself the latitude to learn and to go back and make changes.&#148; You might need to make a lot of changes as you learn and understand the problem more deeply. The elegance you&#146;ll produce if you evolve until you get it right will pay off, both in the short and the long term. Evolution is where your program goes from good to great, and where those issues that you didn&#146;t really understand in the first pass become clear. It&#146;s also where your classes can evolve from single-project usage to reusable resources. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_307" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>What it means to &#147;get it right&#148; isn&#146;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&#146;re building, but also how the program will evolve (what I call the <a name="Index2116"></a><i>vector of change</i>). Fortunately, object-oriented programming languages are particularly adept at supporting this kind of continuing modification&#151;the boundaries created by the objects are what tend to keep the structure from breaking down. They also allow you to make changes&#151;ones that would seem drastic in a procedural program&#151;without causing earthquakes throughout your code. In fact, support for evolution might be the most important benefit of OOP. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_308" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>With evolution, you create something that at least approximates what you think you&#146;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 reimplementing the portions of the program that didn&#146;t work right.<sup><a name="fnB113" href="#fn113">[113]</a></sup> 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 <a name="Index2119"></a><a name="Index2120"></a><i>Design Patterns </i>is usually helpful here. You can find information in <i>Thinking in Patterns (with Java)</i> at <i>www.BruceEckel.com</i>.) <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_309" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Evolution also occurs when you build a system, see that it matches your requirements, and then discover it wasn&#146;t actually what you wanted. When you see the system in operation, you may find that you really wanted to solve a different problem. If you think this kind of evolution 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 is indeed what you want. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_310" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>Perhaps the most important thing to remember is that by default&#151;by definition, really&#151;if you modify a class, its super- and subclasses will still function. You need not fear modification (especially if you have a built-in set of unit tests to verify the correctness of your modifications). Modification won&#146;t necessarily break the program, and any change in the outcome will be limited to subclasses and/or specific collaborators of the class you change. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_311" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="_Toc408018415"></a><a name="_Toc472654698"></a><a name="_Toc24775980"></a><a name="Heading24435"></a>Plans
pay off</h2>
<p>Of course you wouldn&#146;t build a house without a lot of carefully drawn plans. If you build a deck or a dog house your plans won&#146;t be so elaborate, but you&#146;ll probably still start with some kind of sketches to guide you on your way. Software development has gone to extremes. For a long time, people didn&#146;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, primarily intended for those big projects. These methodologies were too scary to use&#151;it looked like you&#146;d spend all your time writing documents and no time programming. (This was often the case.) I hope that what I&#146;ve shown you here suggests a middle path&#151;a sliding scale. Use an approach that fits your needs (and your personality). No matter how minimal you choose to make it, <i>some</i> kind of plan will make a big improvement in your project, as opposed to no plan at all. Remember that, by most estimates, over 50 percent of projects fail (some estimates go up to 70 percent!). <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_312" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p><a name="_Toc312373783"></a>By following a plan&#151;preferably one that is simple and brief&#151;and coming up with design structure before coding, you&#146;ll discover that things fall together far more easily than if you dive in and start hacking. You&#146;ll also realize a great deal of satisfaction. It&#146;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 elegance always pays off; it&#146;s not a frivolous pursuit. Not only does it give you a program that&#146;s easier to build and debug, but it&#146;s also easier to understand and maintain, and that&#146;s where the financial value lies. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_313" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h2>
<a name="Index2121"></a><a name="_Toc472654699"></a><a name="_Toc24775981"></a><a name="Heading24438"></a>Extreme
Programming</h2>
<p>I have studied analysis and design techniques, on and off, since I was in graduate school. The concept of <a name="Index2122"></a><a name="Index2123"></a><a name="Index2124"></a><i>Extreme Programming</i> (XP) is the most radical, and delightful, that I&#146;ve seen. You can find it chronicled in <i>Extreme Programming Explained</i> by Kent Beck (Addison-Wesley, 2000) and on the Web at <i>www.xprogramming.com</i>. Addison-Wesley also seems to come out with a new book in the XP series every month or two; the goal seems to be to convince everyone to convert using sheer weight of books (generally, however, these books are small and pleasant to read). <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_314" title="Send BackTalk Comment">Feedback</a></font><br></p>
<p>XP is both a philosophy about programming work and a set of guidelines to do it. Some of these guidelines are reflected in other recent methodologies, but the two most important and distinct contributions, in my opinion, are &#147;write tests first&#148; and &#147;pair programming.&#148; Although he argues strongly for the whole process, Beck points out that if you adopt only these two practices you&#146;ll greatly improve your productivity and reliability. <font size="-2"><a href="mailto:[e-mail]?Subject=[TIJ3]Chap01_315" title="Send BackTalk Comment">Feedback</a></font><br></p>
<h3>
<a name="_Toc472654700"></a><a name="_Toc24775982"></a><a name="Heading24441"></a>Write
tests first<br></h3>