Re: Interesting but sensitive topic to discuss (HELP: - OOP and CASE tools)

[stt@houdini.camb.inmet.com (Tucker Taft)]

Robert C. Martin (rmartin@oma.com) wrote:

: ... Imagine a program that trasmits files between computers using
: modems.  That program could deal with lots of different kinds of modems in
: several different ways.  It could use a switch statement every time it needed 
: to interact with a modem, choosing the correct modem each time and executing
: the right code.  Or it could create an abstract Modem class and then create
: derivative for each type of modem.  

: In the first example, adding a new modem means ripping through all the code
: and finding every place where there is a switch statement and adding the
: new modem to it.

: In the second example, adding a new modem is a easy as writing a new derivative
: class of Modem.

: On the other hand,  if we need to add a new function to all the modems, then
: in the first example, all we have to do is add a switch statement, but in
: the second example, we must modify the abstract modem class and all its 
: derivatives.

: This is an architectural choice; and it is based upon which kind of change
: is more likely.  If it is more likely that new functions will be added to
: existing modems, then the switch statement is probably the better choice.
: If it is more likely that new kinds of modems will be added, then the class
: structure is probably better.

This is certainly a good point, but I think that the class structure
still has certain advantages over the "switch" structure even when adding 
new "functions" is somewhat more common than adding new modem variants.

In the "switch" world (in which I have spent many pleasant hours ;-),
one tends to presume that almost every new function requires its
own personal switch statement.  In the "class" world, when adding
a new operation, one has the option of implementing it in terms of
some preexisting more primitive operation, rather than creating
a new operation for every modem variant.  

Although this is difficult to prove, my sense is that by being 
forced by the "class" structure to express the differences between 
type variants by a set of primitive operations, one is more likely 
to find that many new "interesting" operations are implementable 
in terms of the existing operations.  In the "switch" structure,
you often don't ever get around to defining the "primitive"
operations, but instead just keep defining miscellaneous operations,
each with their own switch statement, without any great thought
to creating a minimal but complete set of "primitive" operations.
The net effect is that when you want to change some aspect of
the implementation, or fix a bug, there is much more cut & paste
that has happened in the "switch" world, and hence much more of
a maintenance problem.

To reiterate, when it comes to writing a new operation, with the "switch"
structure, you will often have to write a new switch statement, probably
partially copying and then editing some existing switch statement.
With the "class" structure, it is more likely that you will only
have to write a small amount code, containing calls on preexisting 
operations.  

: Robert C. Martin    | Design Consulting   | Training courses offered:
: Object Mentor       | rmartin@oma.com     |   Object Oriented Design
: 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
: Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA