3.9 Object-Oriented Analysis and Design
The steps before programming
anything, other than a trivial demonstration program, 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 (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.
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. One
interesting controversy that has arisen recently is between
traditional object-oriented design on the one hand and
eXtreme
programming on the other.
There are other competing approaches as well. How much time
you'll 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 C# programming, rather than on design debates.
|
|
|
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 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.
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
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.
|
|
