4.5 Object-Oriented Analysis and Design

The steps to take before programming anything are analysis and design. Analysis is the process of understanding and detailing the problem you are trying to solve. Design is the actual planning of your solution.

With trivial problems (e.g., computing the Fibonacci series^[2]), you may not need an extensive analysis period, but with complex business problems, the analysis process can take weeks or even months. One powerful analysis technique is to create what are called use-case scenarios, in which you describe in some detail how the system will be used. Among the other considerations in the analysis period are determining your success factors (how do you know if your program works) and writing a specification of your program's requirements.

^[2] The Fibonacci series is the sum of the values 0,1,1,2,3,5,8,13... The series is named for Fibonacci, who in 1202 investigated how fast rabbits could breed in ideal circumstances. The series works by adding the previous two numbers to get the next (thus 8 is the sum of 5+3).

Once you've analyzed the problem, you design the solution. Key to the design process is imagining the classes you will use and their inter-relationships. You might design a simple program on the fly, without this careful planning; but in any serious business application, you will want to take some time to think through the issues.

There are many powerful design techniques you might use, most of which are beyond the scope of this book. One interesting controversy that has arisen recently is between traditional object-oriented design on the one hand^[3] and eXtreme programming on the other.^[4]

^[3] See The Unified Modeling Language User Guide, The Unified Software Development Process, and The Unified Modeling Language Reference Manual, all by Grady Booch, Ivar Jacobson, and James Rumbaugh (Addison-Wesley).

^[4] See Planning Extreme Programming by Kent Beck and Martin Fowler (Addison-Wesley).

There are other competing approaches as well. How much time you put into these topics will depend, in large measure, on the complexity of the problems you are trying to solve, and the size of your development team.

My personal approach to managing complexity is to keep team size very small. I have worked on large development teams, and over the years I've come to believe that the ideal size is three. Three highly skilled programmers can be incredibly productive, and with three you don't need a manager. Three people can have only one conversation at a time. Three people can never be evenly split on a decision. One day I'll write a book on programming in teams of three, but this isn't it, and so we'll stay focused on VB.NET programming, rather than on design debates.

About the Examples in This Book Object-oriented programming is designed to help you manage complex programs. Unfortunately, it is very difficult to show complex problems and their solutions in a tutorial on VB.NET. The complexity of these problems gets in the way of what you're trying to learn about. The examples in this book will be extremely simple. The simplicity may hide some of the motivation for the technique, but the simplicity makes the technique clearer. You'll have to take it on faith, for now, that these techniques scale up well to very complex problems. The beginning chapters of this book focus on the syntax of VB.NET. You need the syntax of the language to be able to write a program at all, but it's important to keep in mind that the syntax of any language is less important than its semantics. The meaning of what you are writing and why you're writing it are the real focus of object-oriented programming and thus of this book. Don't let concern with syntax get in the way of understanding the semantics. The compiler can help you get the syntax right (if only by complaining when you get it wrong), and the documentation can remind you of the syntax, but understanding the semantics, the meaning of the construct, is the hard part. Throughout this book, I work hard to explain not only how you do something, but why and when you do it.