Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!p.cs.uiuc.edu!johnson
From: johnson@p.cs.uiuc.edu
Newsgroups: comp.sw.components
Subject: Re: Inheritance vs. component efficienc
Message-ID: <130200007@p.cs.uiuc.edu>
Date: 20 Jun 89 17:12:00 GMT
References: <5682@hubcap.clemson.edu>
Lines: 26
Nf-ID: #R:hubcap.clemson.edu:5682:p.cs.uiuc.edu:130200007:000:1320
Nf-From: p.cs.uiuc.edu!johnson    Jun 20 12:12:00 1989


>> This is just inheritance via another name.  Isn't it better to have this as
>> a language feature instead of an external hack?

>   No, because the automatically generated code will eventually be
>   rewritten, and there needs to be the separation between specification
>   and implementation so that the rewrite will not obsolete lots of code.
>
Sometimes subclasses are rewritten, and sometimes they are not.  A subclass
is more likely to be rewritten in the early stages of a project, while the
abstractions are still being discovered.  Later on, once the class library 
becomes mature and application programmers are using it instead of the 
developer and his/her friends, few classes are rewritten.

>   Another negative aspect is that inheritance tends to focus attention
>   on the underlying layer of abstraction, instead of the current layer
>   of abstraction.  With calls to an underlying abstraction, the focus 
>   on how to implement the current abstraction is maintained.
 
The way inheritance is introduced in papers, the underlying layer
of abstraction, i.e. the abstraction represented by the superclass,
encompasses the current abstraction.  Further, the superclass directs
your focus to the procedures that you need to implement.  Thus, I don't
think that this is really a problem.

Ralph Johnson