Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!seismo!uunet!decwrl!sun-barr!newstop!exodus!margot.Eng.Sun.COM!donm
From: donm@margot.Eng.Sun.COM (Don Miller)
Newsgroups: comp.software-eng
Subject: Re: Reusability considered harmful??(!!)
Summary: Object Oriented software development
Message-ID: <7085@exodus.Eng.Sun.COM>
Date: 31 Jan 91 18:36:14 GMT
References: <12385@pucc.Princeton.EDU>
Sender: news@exodus.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 89


...in response to semantic argument about "reusability"...

In article <12385@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes:
>
>                                             .....      "Reusable"
>software components are very often ugly to use because they do more
>at run time than the potential reuser wants them to do.  Even when this
>is not the case, there is a perception problem, somehwat similar to
>the perception of reusability that Brad describes: programmers tend to
>be highly suspicious of buying a pig in a poke, of having to pay for
>someone else's mistakes, or just of coming up with a less than optimal
>product.

   This is my primary concern with reuse-facilitating OO languages
   like C++.  The nature of the craftsman/inventor is to "build a
   better mousetrap".  I believe that programmers will be tempted
   to modify or ignore reusable functions because they are not a
   good fit with the exact application or the fit cannot be measured
   because it is unclear what the code does.  

   It seems that the best way to address this problem is to treat
   code intended for reuse with great respect.  This essentially 
   means documentation to the level of a system or library call.
   Yes, that means a man page.  It also means focused functionality.
   Code which tries to be all things to all people is unlikely
   to be really useful to anyone.

> ...
>
>Reusability is not like motherhood, good no matter what.  We badly need
>a theory of what constitutes good reusability and what constitutes bad
>reusability.  Unfortunately, in an era of computing cultures that
>are expand globally, at dizzying speed, it is unlikely that we can
>come to any such agreement any time soon.  I therefore predict that
>code, globally speaking, will be in future even LESS modular...more
>highly adapted to a particular environment...than it is today.

   
   In the Journal of Object Oriented Programming (Jan 1990 p13),
   an article entitled "Adequate Testing and Object-Oriented 
   Programming" addresses the testing perspective.  The authors
   describe four features common to many OO languages which 
   bely an intuitive assumption that reuse will not mean retest.
   Test adequacy is addressed in the article as the combination
   of specification-based (black box) and program-based (white box).

   Antiextensionality:  "If two programs compute the same function
   (that is, they are semantically close), a test set adequate for
   one is not necessarily adequate for the other." 

   General Multiple Change:  "When two programs are syntactically
   similar (that is, they have the same shape), they usually 
   require different test sets."

   Antidecomposition:  "Testing a program component in the context
   of an enclosing program may be adequate with respect to that
   enclosing program, but not necessarily for other uses of the
   component".

   Anticomposition:  "Adequately testing each individual program
   component in isolation does not necessarily suffice to adequately
   test the entire program.


   After a discussion of the application of these adequacy criteria
   in the context of object oriented features such as encapsulation,
   method overriding, and multiple inheritance, the authors conclude:

      "Encapsulation together with inheritance, which intuitively
      out to bring a reduction in testing problems, compounds
      them instead.

      Where non-inheritance languages make the effects of changes
      explicit, inheritance languages tend to make these implicit
      and dependent on the various underlying, and complicated,
      inheritance models."

   There are several interesting observations which lead to this
   conclusion.  These observations directly relate to what might
   be "good" and "bad".  


    
--
Don Miller                              |   #include <std.disclaimer>
Software Quality Engineering            |   #define flame_retardent \
Sun Microsystems, Inc.                  |   "I know you are but what am I?"
donm@eng.sun.com                        |