object oriented design — how do you do it?

how do you do it?

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 modelling 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)

what is object oriented design? | how do you do it?
email us  or  telephone   UK: 01625 850 839    International: +44 1625 850 839