Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!pp!cadillac!vaughan
From: vaughan@cadillac.CAD.MCC.COM (Paul Vaughan)
Newsgroups: comp.lang.c++
Subject: Re: OOP languages and software reuse
Summary: OOPL reuse techniques
Message-ID: <612@cadillac.CAD.MCC.COM>
Date: 30 Nov 88 21:37:49 GMT
References: <1250001@hpcllca.HP.COM>
Organization: MCC VLSI-CAD Program, Austin, TX
Lines: 33


   The concept of abstract data types supports the creation of reusable
software components that do not require an object-oriented
implementation language.  However, there are two considerations which
indicate that an object-oriented language may help in creating and using
abstract data types: 1) the inheritance hierarchy may help eliminate
duplicated code in a family of related types, 2) the type specific
function invocation concept (message sending) can help avoid namespace
conflicts in using different types together.

   While these benefits are important, I see a fundamentally different
usage paradigm available in OOL's that support before, after, and around
daemons as being more important.  This concept is expressed nicely in
Sonya Keene's book (I think the title is "Object Oriented Programming In
Common Lisp"), as procedural abstraction.  It is useful to document that a
particular function always calls certain other functions.  This
essentially defines program "hooks," which can be used to implement
application specific behavior.  The result is that it is possible to
create large application components, such as an interactive graphics
system, that can be reused by creating a derived class with the addition
of a small number of daemons that serve to integrate it with other
components of the overall system.

   Although it is true that this sort of reuse also requires careful
design for reuse, I believe it is feasible to do using an incremental
approach.  Before such a resuable component can be released, it should
be tested with several systems.  Distributing the source code,
especially to a few knowledgeable users, can lead to extremely valuable
feedback for improving the usefulness of the component.
-- 

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan