Newsgroups: comp.lang.c++,comp.object,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!satisfied.elf.com!news.mathworks.com!hookup!olivea!uunet!rcm!rmartin
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Teaching OO
References: <1994Dec26.162401.6570@rcmcon.com> <RFR0lOfN33q2071yn@IIA> <AKV.95Jan8184845@srl03.usl.edu> <3ettm9$rj3@seralph9.essex.ac.uk> <3evfec$5ah@nova.umd.edu> <3evjp1$13fg@news-s01.ny.us.ibm.net>
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Wed, 11 Jan 1995 14:34:49 GMT
Message-ID: <1995Jan11.143449.24323@rcmcon.com>
Lines: 159
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:106870 comp.object:24900 comp.lang.smalltalk:19432

bfelton@ibm.net writes:

>>>rmartin@rcmcon.com (Robert Martin) writes:
>>
>>>>But lets properly define OOD for the purposes of this conversation.
>>>>OOD is the use of abstract interfaces for the managment of
>>>>dependencies in a software application.  The end result of that
>>>>management is the creation of modules whose independence (gained by
>>>>managing dependencies) makes them reusable and maintainable.  

Bill Said:

>>>I would submit that this is a highly unusual, and virtually useless
>>>(outside academia and camp-follower seminar'ing) definition.  OOD
>>>is designing software using objects.  To reduce that (or is it to
>>>overly-complexify it?) to the point where objects are consdered
>>>solely as intefaces, and then only from the point of view of
>>>abstractions, is to engage in a type of theorizing of no use
>>>whatsoever to those attempting to deliver solutions to business.

Bob Said:
>> That is quite a claim.  I think you would find it hard to
>>substantiate. 

>>Consider.  What makes a class reusable?  A reusable class is a class
>>which can be removed from the context for which it was designed and
>>inserted, unchanged, into a new context.  In order to achieve this,
>>the reusable class *must not depend* upon any of the details in the
>>original context.  Thus, the dependencies of that class must be
>>managed.

Bill Said:
>Well, I have at least as much trouble with this as I do with the
>proposed definition of OOD.  First off, the focus of OO is not and
>ought not to be, reuse.  It had better be on use, or reuse will not
>and cannot happen.  For an object to be reusable is certainly a plus,
>but it is NOT the sine qua non of OO.  Far from it.  

And I think that this is part of the problem with many software
systems today.  The focus of the software was only upon the "here and
now" and not enough attention was paid to what might happen down the
road.    

Designing for reuse is more complex than simply making a bunch of
components that others might be able to use one day.  Designing for
reuse is to admit that the software you are producing has a lifecycle
that it must survive.  If one focuses only upon "use" as you suggest,
then the code you produce will become unmaintainable in a short time.
However, if one focuses upon "reuse", then the code will be reusable
in its current context during the maintenance cycle.

Remember, maintenance is a form of reuse, since you are changing the
application and then asserting that all the unchanged code can be
reused in the changed context.

>Secondly, the
>notion that in order to be reusable an object must able to be yanked
>bleeding out of its original context and plugged willy-nilly into any
>old other context and function -- or it is not a reusable class -- is
>nonsense.  

I never said, or implied that.  A class is reusable if it can be used,
unchanged, in more than one detailed context.

>I agree that one must understand the boundaries of
>the contexts within which an object can usefully play a role -- and
>that this may well involve managing the interface (and
>implementation) of the object(s) in question.  But I do not believe
>that these are core issues, let alone core OO design issues.

What do you believe are the core design issues?  

>>If A is the class we want to reuse, and B is a class in the original
>>context, and if instances of A must send X messages to instances of B,
>>then how can be make A reusable?  By creating a new class AbstractB
>>which has X defined as a pure interface.  Now A can send X messages to
>>AbstractB, not to B directly.  B derives from AbstractB and so can
>>receive the X message.

>However, given the existence of bounded contexts, there is no such
>thing as "pure" or 'abstract' interface with no dependance whatsoever
>on implementation.  

Of course there is.  

class AbstractB
{
  public:
   virtual void X() = 0;
};

The class AbstractB has utterly no dependency at all upon any
potential implementation of X in a derived class.

>Further, the practical overhead of "pure
>interface" classes and objects is too high a price to pay for the
>purported reusability of some of the objects which will play roles in
>"commercial" sofware [defined as software for which someone other
>than the developer is willing to pay for development, and with the
>notion that the end result will be usable].

The cost of managing dependencies with abstract interfaces *is* high.
So the benefits better be there to offset the costs.  The benefits are
that the modules within the application are not interdependent.  When
changes are made in one module, they do not propogate to others.  Bugs
can be fixed, and features added, without introducing lots of new bugs
in unrelated parts of the code.

>>When A is resused in a new context, a new derivative of AbstractB will
>>need to be created, one that is germane to the new context.
>>
>>Now, note.  The existence of AbstractB, which is essential to the
>>ability to reuse A, is not required at all for the original
>>application.  It is not until one considers reuse that one would
>>design AbstractB into the solution.

>And this is, in its heart, my argument against your definition of OOD
>-- we must design usable objects before we can worry about reuse.
>Reuse is important, but it is not the whole story, nor the central
>theme of the tale.  Further, and most problematic, your definition is
>of no use whatsoever in the design of usable objects.  Because of its
>single-minded focus on reuse, it misses the tree in service of the
>forest.

We can use Structured Analysis and Design to create modules that can
be "used".  But, as history has shown, we need something more.  Not
only must modules be usable, they must be maintainable.  They must
survive their lifecycle.  And this means that we have to design the
modules for survivability.  One very important criterion is the
management of dependencies between modules.  A module with very few
dependencies is more robust than a module with many dependencies.  

>>What is
>>the goal of OOD?  What benefits are we trying to gain.  

>How to design useful objects.  

Why objects?  Why not just useful code?

>The benefits of encapsulation,

What are the benefits of encapsulation, if not the management of
dependency?

>inheritance, polymorphism, 

Why these two?  You have named mechanisms but no motivation.  Why do
you name inheritance and polymorphism as benefits and goals?

>and, yes, reuse.  But reuse last.

I disagree. 


-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++
