Thread View: comp.lang.eiffel
1 messages
1 total messages
Started by day@grand.UUCP (
Wed, 21 Dec 1988 18:18
Re: Object oriented design or 'to inherit or not to inherit'
Author: day@grand.UUCP (
Date: Wed, 21 Dec 1988 18:18
Date: Wed, 21 Dec 1988 18:18
57 lines
3036 bytes
3036 bytes
From: Dave Robbins <drobbins@gte.com> Date: Tue, 22 Nov 88 08:58:31 EST I think that the "defect" described by Jos is something that illustrates the difference between inheritance of "specification" and inheritance of "implementation." The two are distinctly different concepts. 1) Inheritance of specification is inheritance of behavior, or protocol. A class inherits behavior from another class when it intends to behave the same way, and in such cases it is clearly expected that the subclass will respond appropriately to all the same operations to which the superclass responds. 2) Inheritance of implementation is no more and no less than a way to implement a class by sharing its implementation with that of another class. A class that inherits for implementation purposes (such as FIXED_STACK in Jos' message) has absolutely no intention of behaving in all respects like the class from which it inherits. It is easy to get the two concepts confused, especially when dealing with languages that make no distinction between the two concepts of inheritance. Off the top of my head, I don't recall whether or not Meyer in his book draws such a distinction. I do think that Eiffel is somewhat schizoid about this: some of its rules (e.g., those for pre- and post-conditions on redefined routines) are rather clearly intended to preserve behavior in subclasses, thus supporting a specification-inheritance view, while other rules (e.g., permitting a subclass to not export a feature exported in the superclass) seem more in line with an implementation-inheritance view. The problem Jos points out is that FIXED_STACK intends to inherit the implementation *but not the specification* of ARRAY. In the class of object-oriented languages exemplified by Smalltalk, there is no formal notion of specification at all -- inheritance is always implementation inheritance. In the class of object-oriented languages exemplified by Eiffel, inheritance leans toward that of specification, but retains implementation inheritance as well. Trellis/Owl is the one object-oriented language that I am familiar with that treats inheritance strictly as inheritance of specification. It is my opinion that the distinction between the two forms of inheritance is very important, and that languages such as Eiffel must come to grips with that distinction. Eiffel has not, at this point, dealt effectively with that distinction. Both forms of inheritance are desirable, but the two must not be inextricably intertwined. A language must permit inheritance of specification when that is desired, and inheritance of implementation *but not specification* when that is desired. Jan's suggestion of "private" inheritance may have some merit. I recall reading at least one or two papers in OOPSLA '87 that address the two concepts of inheritance. Enough for now. Dave Robbins GTE Laboratories Incorporated drobbins@gte.com 40 Sylvan Rd. ..!harvard!bunny!drobbins Waltham, MA 02254
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads