Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!deimos.cis.ksu.edu!uxc!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: <130200003@p.cs.uiuc.edu> Date: 12 Jun 89 17:29:00 GMT References: <5682@hubcap.clemson.edu> Lines: 98 Nf-ID: #R:hubcap.clemson.edu:5682:p.cs.uiuc.edu:130200003:000:4994 Nf-From: p.cs.uiuc.edu!johnson Jun 12 12:29:00 1989 >> by me (Ralph Johnson) > by Bill Wolfe > (Note for readers unfamiliar with the terminology: "class" > is New-Speak for "type", and "method" is New-Speak for > "procedure or function"...) Class and type are not necessarily the same. Languages like C++ make them the same, but I think that is a mistake. It certainly is not true in Smalltalk or Lisp-based languages. Class doesn't mean type any more than it means package or module (which I have seen people claim). Methods and procedures are almost the same, except for the polymorphism induced by run-time binding of procedure calls. Also, Smalltalk predates Ada, so "New-Speak" is not appropriate. OOP maybe cultish or insular, but it is not new. >> This style of programming results in ugly class hierarchies and >> can lead to the inefficiencies that Bill Wolfe complained about. >> However, it is very valuable during rapid-prototyping and helps >> lead to families of interchangeable components. > My comments specifically indicated that the tactic may be useful > in isolated areas in which development costs were important and > utilization costs were not; however, this does not characterize > the software components marketplace. I'm not concerned about the component builders as much as the component users. Building an application is often similar to rapid-prototyping, because when you show it to your customer you find out that you were being misinformed when you did the requirments analysis. Further, the most important kinds of components are application specific, and so I expect that each company will continue to develop its own components, in addition to using a large supply of components developed outside. >> The third way of using inheritance is to inherit from an abstract >> class, also called a deferred class. This is the most elegant use >> of inheritance, and is essentially using the superclass as a template >> to generate new classes. > By this I presume you mean the inheritance of specifications; > if not, be precise. No. An abstract class is a class with some methods left undefined. Thus, it is not possible to make objects from it, only to make subclasses. The subclasses must define the undefined methods. That is as precise as I can get. It's pretty hard for someone who hasn't done any object-oriented programming to understand the ramifications of it. Abstract classes are a lot like using a generic package that is parameterized by a set of procedures. One big advantage of object-oriented programming is that superclasses can provide default implementations of methods. In fact, you can look upon a class as a generic package that is parameterized by ALL its procedures, since a subclass can redefine any of the methods that it is inheriting. >> We need to make software easier to change. > By constructing software in a modular manner. Modular software is good, but not enough. Inheritance lets you modify components that are not quite right. Object-oriented programming certainly promotes modularity, but it also promotes abstraction and classification of families of similar components. These are just as important. >> In fact, most software that is written is run on only a few machines. >> Few programmers are writing software that will run on thousands of machines. > Oh, but I beg to differ. A large and rapidly growing number of > programmers are writing software in Ada, a language which is > rigorously standardized, allowing one to write software which > will run on any machine having a validated Ada compiler. This > amounts to millions of machines. In fact, without this level > of standardization, it is difficult to imagine a viable software > components industry. I didn't say "COULD run on thousands of machines". Lots of languages let programmers produce portable code. The fact is, most programmers are application programmers, and that will continue to be true. Object-oriented programming is good because it makes THEIR life easier, not just the component developer. I am a great fan of software components. All object-oriented programmers are. I believe that object-oriented programming is the best current technology available to promote software reuse. That certainly includes Ada. Of course, it would be easy to fix Ada so that it is object-oriented, and several groups have done so, but the result is no longer official Ada. There is a certain company that has a great Ada programming environment. Their customers often call up and ask how a certain feature was implemented in the environment, since they have figured out that they need to do the same thing in their application. They are sheepishly told that the feature is implemented using an extension to Ada, and consequently the compiler that implements the extension is not true Ada and the company is not giving away the compiler. This extension essentially adds dynamically bound procedure calls to Ada.