Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!apple!sun-barr!ccut!ascgw!sh8810!okilab!icot32!isvax!uucp
From: guendel@exunido.uucp (Andreas Guendel)
Newsgroups: comp.object
Subject: Re: Eiffel, assertions, Object-Z and library books.
Message-ID: <16828@isvax.isl.melco.co.jp>
Date: 25 Dec 89 04:32:16 GMT
Sender: uucp@isvax.isl.melco.co.jp
Lines: 120









































































In article <288@oasis.mrcu> Paul Johnson asked:

> Are Multiple Inheritance and Software Contracting incompatable?
> Suppose we have the
> classes PLANE and ASSET.  From these we derive COMPANY_PLANE.  A
> precondition for FLY in PLANE is to be a qualified pilot.  A
> precondition for USE in ASSET is to be a company employee.  Hence to
> fly a company airplane, you must be a company employed qualified
> pilot.  This strengthens the pre-conditions on both base classes.

In article <1818@laura.UUCP> I answered:

> If the precondition is strengthend there is no subclass-relation semantically
> as the software contracting rule shows.

In article <1469@castle.ed.ac.uk> Dave Berry responded:

> I can see how Andreas' position applies to single-inheritance hierarchies.
> I can't see how it answers the multiple-inheritance example given by Paul
> Johnson.  Surely a company plane *is* both an asset and a plane?  This applies
> both conceptually and practically; in practice one might want to add the
> company_plane to a list of company assets and to a list of planes.
> If one accepts Andreas' position, how should this example be implemented?

Well, you are right Dave. Taking a rigid theoretical position does by itself
not help in a concrete example. Thus, here is an attempt to clarify the
example.

If you want a companys assets include complex things like a company_plane,
you have to take care while defining the class ASSET. Obviously, not any
employee may USE each of a companys assets. Why? There might be some in-house
legitimation scheme and, at least I hope so, some condition on the employees
qualification. In the special case of the subclass company_plane this will
be: qualified pilot!

If you want to model planes in a section of reality that includes ownership
relations, you have to take care while defining the class PLANE. Obviously,
not any qualified pilot may FLY each existing plane. Why? He needs the
legitimation from the owner of the plane. In the special case of the subclass
company_plane this will be: beeing an employee.

Summary: In OO-Programming it is not the main problem to build new subclasses
         of (multiple) superclasses, but to create reusable, extendable
         classes which model entities in a coherent section of reality.
         These classes will hopefully allow for semantically correct sub-
         classing (even with multiple inheritance) later on.

Hope this helps, Andreas Guendel