Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!mailrus!iuvax!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.sw.components
Subject: Re: What is a reusable software compone
Message-ID: <71800005@m.cs.uiuc.edu>
Date: 1 Aug 90 01:20:00 GMT
References: <27705@athertn.Atherton.COM>
Lines: 55
Nf-ID: #R:athertn.Atherton.COM:27705:m.cs.uiuc.edu:71800005:000:2826
Nf-From: m.cs.uiuc.edu!johnson    Jul 31 20:20:00 1990


Paul Sander writes:
>I was under the impression that a major reason for inventing reusable
>components was to reuse code, that is to recycle implementations.
Certainly.  However, it turns out that you get better code reuse
when you think about standardizing specifications.  Futher, you can't
reuse code as often as you can reuse design.

Paul and I seem to have a different definition of specification.
A specification does not have to define a complete behavior for a
component.  In fact, the most useful specifications are incomplete.
Most components that meet a particular specification will in fact
meet much more detailed specifications as well.

I agree that it isn't crucial that we have many implementations of
specifications such as almost-constant-functions.  However, it is a
good idea to have many implementations of specifications such as
displayable objects.  It is important that all displayable objects
conform to a standard interface so that programs can manipulate images
without having to worry about their complexity.

Like I said,
>>Further, I take the point of view held by the object-oriented
>>community that it is not particular kinds of components that are
>>important, but rather sets of components and their relationships.
>>The advantage of concentrating on specification is that you end
>>up with lots of components that share the same specification.
>>When you learn one, you have learned something about all of them.
>>Also, it becomes easier to replace one component with another
>>because they will share specification.  Thus, it becomes easier
>>to write utilities that work with any of the related components.

Perhaps if you replace "specification" with "interface" then you
will understand my point better.  I believe that there is no real
difference in the terms.

I've been building object-oriented systems for a few years now.
Inheritance is nice, and I don't want to do without it, but
polymorphism is more important.  Polymorphism depends on a set
of different classes that all meet the same specification.

>In practice while programming, it turns out that the interfaces of the
>two objects may be the same, but the objects are hardly interchangeable,
>since their semantics are different.  They may not even be compatible in
>the sense that one can replace the other in some section of code.

Suppose I give the specification that a program must halt with the
variable X equal to 1.  There are lots of different programs that
meet this specification, and they are not interchangeable, unless
that is all we care about.  A summation routine only cares that its
arguments have an addition operation, but the routine that calls it
may also want the sum of two polynomials to be a polynomial.  There
is no contradiction.

Ralph Johnson -- University of Illinois at Urbana-Champaign