dmitry@hpcllca.HP.COM (Dmitry Lenkov) (11/24/88)
Software reuse is one of the major areas in software development
which is gaining more attention nowadays. Object-oriented
languages are claimed to support software reuse by their nature.
Here come to mind two points recently made in notes.
1. Jim Adcock (HP Lake Stevens, WA) writes:
> Code reuse comes with code that was designed
> for reuse. Code that was not designed for
> reuse cannot be easily reused. Whatever language
> one uses, one needs to realize that
> reusability has to be a deliberate design
> goal for any code to be reused on future
> projects.
This approach puts emphasis on a full design (possibly object-
oriented) and an advance generalization of code planned to be
reused later.
2. Ralph Johnson (University of Illinois at Urbana-Champain) writes:
> The main reason that o-o programming is so popular is code reuse.
> Reusable code is harder to write than other code because, in addition
> to being correct, it must be reusable. The only way to see whether or
> not code is reusable is to reuse it. If some classes will work in
> three previous projects then they are more likely to be reusable than
> classes that have only been used in one project, which is one of the
> reasons why reusable code is usually a result of generalizing from
> earlier projects. I believe it is code reuse that makes the iterative
> life-cycle model so important to object-oriented programming.
The iterative life-cycle model is often associated with the object-
oriented design by prototyping. With this respect, here is an approach
which suggests the design process of reusable code as a dynamic
generalization from the prototyping phases of several parallel
projects (ignoring the time factor) or subprojects within the same
project.
It is interesting that the above approaches, while being very
different in their nature, both concentrate on the design phase.
So it does probably help when one designs reusable software if he
has a design tool supporting the object-oriented programming
paradigm or an object-oriented prototyping language. However:
1. Does one really need an object-oriented implementation language ?
2. What particular features of object-oriented languages help
an implementation of reusable software after it has been designed
to be reusable ?
Those questions deal with the case when the software has been
designed to be reusable. Let us consider a different situation.
Suppose someone was to assemble a system from existing pieces of
software implemented in the same programming language. For example,
he needs to reuse the text editor part of a window-oriented text
editor with a different windowing package, or he needs to build
a compiler front-end from the parser and lexical analyzer of one
compiler, semantic analyzer of another compiler, and symbol table
package of yet another one. Questions:
3. Will it help if the existing pieces of software are written in
an object-oriented language comparing with the languages like C
or Pascal ??? Or one will glue those pieces by writing whatever
code is necessary as usual.
4. Wouldn't it even be harder at least for some object-oriented
languages because of more restrictive rules for changing
interfaces ?
Yet another aspect of software reuse comes from the fact that
there already exists large amount of software written in
non-object-oriented languages and not designed to support
the object-oriented programming paradigm. In regard to that:
5. Is there any reasonable approach which would allow to reuse
this software either by pieces incorporated into new software
or at the system level by integrating it into object-oriented
or object-based environments, or do we have to limit the
scope of applications of object-oriented programming techniques
to new software developments only ?
ANY OPINIONS AND THOUGHTS ???
|
| Dmitry Lenkov (HP), dmitry@hpcllca
|vaughan@cadillac.CAD.MCC.COM (Paul Vaughan) (12/01/88)
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
akwright@watdragon.waterloo.edu (Andrew K. Wright) (12/01/88)
In article <612@cadillac.CAD.MCC.COM> vaughan@cadillac.CAD.MCC.COM (Paul Vaughan) writes: > 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 ... > 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 How does this help the incrementality problem? In what way can you incrementally modify a program which you could not before? ie. I have a pre-existing class STRING (built by someone else), which I am not allowed to modify. Then I cannot sort it, unless the designer anticipated my need and caused STRING to inherit from SORTABLE. Andrew K. Wright akwright@watmath.waterloo.edu CS Dept., University of Waterloo, Ont., Canada.
vaughan@cadillac.CAD.MCC.COM (Paul Vaughan) (12/03/88)
> How does this help the incrementality problem? In what way can > you incrementally modify a program which you could not before? Here is an example. Suppose you have an interactive graphics editor that you want to use to edit simulation models. Further suppose that the graphics editor defines a class to represent sheets (drawing areas, empty pages), and defines that when a user puts a new graphic object onto the sheet, the message add-object will be sent to the sheet. Knowing this, it is possible to define a class based on the sheet class which has an "after" method for add-object which also updates the simulation data structures. I've managed to do this sort of thing a couple of times now and this leads me to believe that a well designed object-oriented graphics editor could be a standard component for alot of applications. It's incremental in that the designer of the graphics editor need not know very much about how the editor will be used. Unfortunately, he does have to guess about what information client applications will need to know about things that go on in the editor. Of course, it is possible to define explicit program hooks in an ordinary language and to document these. The object oriented approach makes it more natural and has one more advantage. Even when the program designer hasn't anticipated a need, it is often possible to examine the source and discover what messages are called. At this point it is possible to define "after" methods for these methods do what needs to be done, without modifying the original program. (Of course, relying on undocumented features is not an especially good idea, but it can get the job done.) > ie. I have a pre-existing class STRING (built by someone else), > which I am not allowed to modify. Then I cannot sort it, unless > the designer anticipated my need and caused STRING to inherit from > SORTABLE. Coming from a Lisp background, my answer is that STRINGs are obviously derived from SEQUENCEs, which are sortable. But I see your point. However, you can still sort the STRING as long as STRING provides some way of accessing and setting the elements in order. Any design of STRING which doesn't let you do that is deficient. -- 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
owen@cod.NOSC.MIL (Wallace E. Owen) (12/06/88)
In article <10121@watdragon.waterloo.edu> akwright@watdragon.waterloo.edu (Andrew K. Wright) writes: >ie. I have a pre-existing class STRING (built by someone else), >which I am not allowed to modify. Then I cannot sort it, unless >the designer anticipated my need and caused STRING to inherit from >SORTABLE. This problem 'goes away' with multiple inheritance. Derive a class SORTABLE_STRING from SORTABLE and STRING. BTW: When do 'we' get C++ v2.0? >Andrew K. Wright akwright@watmath.waterloo.edu >CS Dept., University of Waterloo, Ont., Canada. Wallace Owen Naval Ocean Systems Center cod.nosc.mil!owen
akwright@watdragon.waterloo.edu (Andrew K. Wright) (12/06/88)
In article <1319@cod.NOSC.MIL> owen@cod.nosc.mil.UUCP (Wallace E. Owen) writes: >In article <10121@watdragon.waterloo.edu> akwright@watdragon.waterloo.edu (Andrew K. Wright) writes: >>ie. I have a pre-existing class STRING (built by someone else), >>which I am not allowed to modify. Then I cannot sort it, unless >>the designer anticipated my need and caused STRING to inherit from >>SORTABLE. >This problem 'goes away' with multiple inheritance. Derive a class >SORTABLE_STRING from SORTABLE and STRING. This problem does *not* go away with multiple inheritance. The solution you propose is not acceptable because it requires me to modify existing code to use SORTABLE_STRING rather than STRING. Someone else has written a procedure which returns arrays of STRINGs (perhaps it is in a library). It is inviolate, you cannot touch it (perhaps you only have it in binary form, because you bought it from a software supplier). Single or multiple inheritance, you have no way of sorting this array. Andrew K. Wright akwright@watmath.waterloo.edu CS Dept., University of Waterloo, Ont., Canada.