There are
more decisions to be made in the design of an OO program than in a conventional
one.
In the conventional program, you design some function by programming
a series of steps. In an OO program, you need to do that too; and additionally,
you need to decide which object should perform which steps; and what objects
there should be. This distribution of tasks between objects doesn't make
the program any more powerful than a non-OO equivalent: programs in both
styles will produce the right answer, and the conventional one will probably
run faster (because it doesn't have to jump around between objects).
The only benefit of distributing the program between objects is that
it's easier to change later; and longer term, you'll be able to reuse object
designs, and so build new systems more quickly. But it's important to emphasise
that you only get the benefit if you do the distribution properly. Many
teams have written poorly-separated software in an OO language, and later
complained that the result isn't any cheaper to manage than before. The
essence of object design isn't using C++ or Java: it's separating concerns,
'decoupling'.
At the stage of an object design when the classes are first drafted,
it is useful to create a dependency chart, showing how the parts of the
software use each other. The nodes can be classes or packages defining
groups of related procedures and data -- again, it doesn't matter whether
you're using an OO language. A good dependency chart is a lattice with
no loops, discernible layers without cross-layer jumps, and few nodes with
high connection counts.
Normally the first dependency diagram looks a mess. The process of OO
design involves the application of an appropriate series of 'design
patterns', most of which are aimed at reducing coupling.
The dependency assessment is a crucial part of a process that begins
with domain modeling and requirements capture, and continues through architecture,
design and implementation. Testing comes into each part of the process.
Depending on the size of the project, a lighter or a more systematic process
may be chosen. In the separate tracks of component based development, the
overall architecture is done more systematically than the development of
individual components, and component assembly is most rapid. For assembly
and small projects, eXtreme Programming may
be appropriate; for component architecture, component development, and
high-integrity projects, Catalysis
provides high reliability.
In all cases, object oriented design is well-suited to the incremental
model of development. Because object designs can readily be extended and
changed, it makes sense to develop a vertical slice of the project at an
early stage, and obtain feedback from the prospective users in time to
influence the development of the other parts.
complete solutions for object oriented analysis and design
(consultancy, courses, workshops, mentoring, seminars, development)
