6.6. Object-Oriented Analysis and Design Before you program anything, other than a trivial demonstration program, you need to take two steps: 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 (such as computing the Fibonacci series), 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. The Fibonacci Series The Fibonacci series is the values 0,1,1,2,3,5,8,13.... The series is named for Fibonacci (Leonardo Pisano), who in 1202 investigated how fast rabbits could breed under ideal circumstances. To simplify, you derive the series by writing 0,1,1 and then adding the previous two numbers to get the next (thus the seventh value in the series, 8, is the sum of the previous two values: 5 + 3). The ratio of consecutive Fibonacci numbers converges to the "golden ratio" F (phi), and F in turn has implications in many natural phenomena (the number of petals in flowers, the ratio of spirals in Sunflowers, the ratio of parts of your finger, and more). See the Internet for much more on the Fibonacci series. |
Once you've analyzed the problem, you design the solution. Imagining the classes you will use and their inter-relationships is key to the design process. 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. How much time you put into design [*] before you begin coding will depend on the philosophy of the organization you work for, the size of your team, and your background, experience, and training. [  ] [*] See The Unified Modelling Language User Guide , Second Edition, by Grady Booch, Ivar Jacobson, and James Rumbaugh (Addison Wesley, 2005). [ ] See Agile Software Development Principles, Patterns, and Practices by Robert C. Martin (Prentice Hall, 2003).  | 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 agree with one of the best developers I've ever met, Ed Belove, that the ideal size for a team of developers 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, so we'll stay focused on C# 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 primer on C#. The complexity of these problems gets in the way of what you're trying to learn about. Because of necessity, the examples in this book will be extremely simple. The simplicity may hide some of the motivation for the technique, but it makes the technique clearer. You'll have to take it on faith, for now, that these techniques scale up well to very complex problems. Most of the chapters of this book focus on the syntax of C#. 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 semanticsmeaning of the constructis the hard part. Throughout this book, I work hard to explain not only how you do something, but why and when you do it. |
|
