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