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

[rmartin@oma.com (Robert C. Martin)]

In article <32891BA4.4AA5@concentric.net>, Alan Lovejoy
<alovejoy@concentric.net> wrote:

> Robert C. Martin wrote:
> > 
> > In article <328109CD.6685@concentric.net>, Alan Lovejoy
> > <alovejoy@concentric.net> wrote:
> > 
> > > The architecture and design of a program is a function of what
> > **objects** it contains and
> > > how they interact.
> > 
> > I disagree.  The architecture of a program is a function of the way
> > it manages to decouple the source code while allowing the interactions
> > to remain unaffected.
> >
> > This is true irrespective of language.  It is as true in Smalltalk as
> > it is in Java or C++.
> 
> I have to admit that I don't really understand what you mean. Perhaps
you could 
> clarify?

Sure.  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.

The point is that the interactions between the program and the modems
remain identical regardless of which architecture you choose.  The 
architecture is strategy for decoupling the source code so that changes
are easily made.

> As I have used the term "design" in earlier posts, it refers to what you
have called
> the "dynamic model" (assuming I have correctly understood you). My
thesis is not that 
> the "static model" is unimportant, but rather that one needs to know
what dynamic model 
> one wants to achieve before one can optimally derive a static model. 
The dynamic model 
> is the heart of the design, because it is where the real work gets done,
and because
> the purpose of the static model is the specification of the dynamic
model.  You can't
> implement a good static model that specifies a dynamic model without
having a good idea 
> of what dynamic model you intend to specify!

Damn straight!  Static models are meaningless without dynamic models to
justify them.  By the same token, dynamic models are fantasies without
static models to support them.  Both are important.  Neither can
stand alone.  One cannot create a static model without a decent
dynamic model.  But by the same token, one cannot create a realistic
dynamic model without it being constrained by a good static model.

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

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan