[ Pobierz całość w formacie PDF ]
.It s nice to discover them early in theprocess but OOP provides enough structure so that it s not so bad if you discover them later.Phase 3: Let s build it!If you re reading this book you re probably a programmer, so now we re at the part you vebeen trying to get to.By following a plan no matter how simple and brief and coming upwith design structure before coding, you ll discover that things fall together far more easilythan if you dive in and start hacking, and this provides a great deal of satisfaction.Gettingcode to run and do what you want is fulfilling, even like some kind of drug if you look atthe obsessive behavior of some programmers.But it s my experience that coming up with anelegant solution is deeply satisfying at an entirely different level; it feels closer to art thantechnology.And elegance always pays off; it s not a frivolous pursuit.Not only does it giveyou a program that s easier to build and debug, but it s also easier to understand andmaintain, and that s where the financial value lies.After you build the system and get it running, it s important to do a reality check, and here swhere the requirements analysis and system specification comes in.Go through yourprogram and make sure that all the requirements are checked off, and that all the use-caseswork the way they re described.Now you re done.Or are you?Phase 4: IterationThis is the point in the development cycle that has traditionally been called maintenance, acatch-all term that can mean everything from getting it to work the way it was reallysupposed to in the first place to adding features that the customer forgot to mentionbefore to the more traditional fixing the bugs that show up and adding new features asthe need arises. So many misconceptions have been applied to the term maintenance thatit has taken on a slightly deceiving quality, partly because it suggests that you ve actuallybuilt a pristine program and that all you need to do is change parts, oil it and keep it fromrusting.Perhaps there s a better term to describe what s going on.The term is iteration.That is, You won t get it right the first time, so give yourself thelatitude to learn and to go back and make changes. You might need to make a lot ofchanges as you learn and understand the problem more deeply.The elegance you ll produceif you iterate until you ve got it right will pay off, both in the short and the long run.What it means to get it right isn t just that the program works according to therequirements and the use-cases.It also means that the internal structure of the code makessense to you, and feels like it fits together well, with no awkward syntax, oversized objectsor ungainly exposed bits of code.In addition, you must have some sense that the programstructure will survive the changes that it will inevitably go through during its lifetime, andthat those changes can be made easily and cleanly.This is no small feat.You must not onlyunderstand what you re building, but also how the program will evolve (what I call thevector of change).Fortunately, object-oriented programming languages are particularly adeptat supporting this kind of continuing modification the boundaries created by the objectsChapter 1: Introduction to Objects 67 are what tend to keep the structure from breaking down.They are also what allow you tomake changes that would seem drastic in a procedural program without causingearthquakes throughout your code.In fact, support for iteration might be the mostimportant benefit of OOP.With iteration, you create something that at least approximates what you think you rebuilding, and then you kick the tires, compare it to your requirements and see where it fallsshort.Then you can go back and fix it by redesigning and re-implementing the portions ofthe program that didn t work right.10 You might actually need to solve the problem, or anaspect of the problem, several times before you hit on the right solution.(A study of DesignPatterns, described in Chapter 16, is usually helpful here.)Iteration also occurs when you build a system, see that it matches your requirements andthen discover it wasn t actually what you wanted.When you see the system, you realizeyou 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 findout if it s what you want.Iteration is closely tied to incremental development.Incremental development means that youstart with the core of your system and implement it as a framework upon which to buildthe rest of the system piece by piece.Then you start adding features one at a time.The trickto this is in designing a framework that will accommodate all the features you plan to addto it.(See Chapter 16 for more insight into this issue.) The advantage is that once you getthe core framework working, each feature you add is like a small project in itself rather thanpart of a big project.Also, new features that are incorporated later in the development ormaintenance phases can be added more easily.OOP supports incremental developmentbecause if your program is designed well, your increments will turn out to be discreetobjects or groups of objects.Plans pay offOf course you wouldn t build a house without a lot of carefully-drawn plans.If you build adeck or a dog house, your plans won t be so elaborate but you ll still probably start withsome kind of sketches to guide you on your way.Software development has gone toextremes.For a long time, people didn t have much structure in their development, but thenbig projects began failing
[ Pobierz całość w formacie PDF ]