[ Pobierz całość w formacie PDF ]
.Perhaps the most important thing to remember is that by default bydefinition, really if you modify a class, its super- and subclasses will stillfunction.You need not fear modification (especially if you have a built-inset of unit tests to verify the correctness of your modifications).Modification won t necessarily break the program, and any change in theoutcome will be limited to subclasses and/or specific collaborators of theclass you change.Plans pay offOf course you wouldn t build a house without a lot of carefully drawnplans.If you build a deck or a dog house your plans won t be so elaborate,but you ll probably still start with some kind of sketches to guide you onyour way.Software development has gone to extremes.For a long time,people didn t have much structure in their development, but then bigprojects began failing.In reaction, we ended up with methodologies thathad an intimidating amount of structure and detail, primarily intendedfor those big projects.These methodologies were too scary to use itlooked like you d spend all your time writing documents and no timeprogramming.(This was often the case.) I hope that what I ve shown youhere suggests a middle path a sliding scale.Use an approach that fitsyour needs (and your personality).No matter how minimal you choose tomake it, some kind of plan will make a big improvement in your project asopposed to no plan at all.Remember that, by most estimates, over 50percent of projects fail (some estimates go up to 70 percent!).By following a plan preferably one that is simple and brief and comingup with design structure before coding, you ll discover that things falltogether far more easily than if you dive in and start hacking.You ll alsorealize a great deal of satisfaction.It s my experience that coming up withan elegant solution is deeply satisfying at an entirely different level; itfeels closer to art than technology.And elegance always pays off; it s not aChapter 1: Introduction to Objects 87 frivolous pursuit.Not only does it give you a program that s easier to buildand debug, but it s also easier to understand and maintain, and that swhere the financial value lies.Extreme programmingI have studied analysis and design techniques, on and off, since I was ingraduate school.The concept of Extreme Programming (XP) is the mostradical, and delightful, that I ve seen.You can find it chronicled inExtreme Programming Explained by Kent Beck (Addison-Wesley, 2000)and on the Web at www.xprogramming.com.XP is both a philosophy about programming work and a set of guidelinesto do it.Some of these guidelines are reflected in other recentmethodologies, but the two most important and distinct contributions, inmy opinion, are write tests first and pair programming. Although heargues strongly for the whole process, Beck points out that if you adoptonly these two practices you ll greatly improve your productivity andreliability.Write tests firstTesting has traditionally been relegated to the last part of a project, afteryou ve gotten everything working, but just to be sure. It s implicitly hada low priority, and people who specialize in it have not been given a lot ofstatus and have often even been cordoned off in a basement, away fromthe real programmers. Test teams have responded in kind, going so faras to wear black clothing and cackling with glee whenever they breaksomething (to be honest, I ve had this feeling myself when breakingcompilers).XP completely revolutionizes the concept of testing by giving it equal (oreven greater) priority than the code.In fact, you write the tests before youwrite the code that will be tested, and the tests stay with the code forever.The tests must be executed successfully every time you do an integrationof the project (which is often, sometimes more than once a day).Writing tests first has two extremely important effects.88 Thinking in Java www.BruceEckel.com First, it forces a clear definition of the interface of a class
[ Pobierz całość w formacie PDF ]