Newsgroups: comp.lang.beta,comp.lang.eiffel,comp.object Path: news.daimi.aau.dk!news.uni-c.dk!diku!embla.diku.dk!juul From: juul@diku.dk (Anders Juul Munch) Subject: Why inheritance is bad (was: Re: On why BETA...) Message-ID: Sender: juul@embla.diku.dk Date: Thu, 15 Sep 1994 21:13:33 GMT References: <358nrv$bpf@engnews2.Eng.Sun.COM> Organization: Department of Computer Science, U of Copenhagen Followups-To: comp.object Lines: 65 Xref: news.daimi.aau.dk comp.lang.beta:53 comp.lang.eiffel:6195 comp.object:19319 derway@ndc.com (D. Erway) writes: >Since so many smart people are saying that MI is too complicated, I assume I >must be missing something. Can you fill me in? It goes like this: Inheritance is bad. Since MI is multiple inheritance, MI is multiply bad. Simple, right ;-) Now that's a little too provocative so I guess I'd better explain. First let me make it absolutely clear that we are talking about _implementation_ inheritance. Types are assumed not to be a problem. Say that classes D1 and D2 are inherited from class B. Suppose you have an object in your hand which you know can be viewed as a B. This object has two kinds of attributes: 1) The explicit attributes, i.e. instance variables. 2) The actual class of the object -- is it a B, D1 or D2? This last attribute is not a first-class object! Because... You cannot read it. Mechanisms such as Eiffel's assignment attempt doesn't give you *all* this information. In fact you rarely want to; doing so would be an indication of poor design. Worse, you cannot *write* it. Although a few esoteric languages support run-time class metamorphosis, it has lots of problems associated and again, you rarely want to. These problems may not seem like problems to you, because since for the most part you don't want to use these things anyway, the ability to do so is hardly missed. But they are very real problems! because this means that you are horribly restricted in how you manipulate information that is hardwired in the class hierarchy this way. A simple example of the problems you can get: Base class EMPLOYEE, derived class MANAGER. Wrong already! You can't do promotions! Better design: Only one class, EMPLOYEE, with an instance variable `rank'. (Other designs are very possible.) Now I can't afford an asbestos suit, so I'd better withdraw my original statement, that inheritance is bad. Of course it isn't. But it has it's problems. And if you use inheritance too liberally, chances are you'll run into these problems. MI encourages using inheritance a lot: When you have it you use it (example: the C++ iostreams library, yuck!). Going back to the original example, using inheritance to add features such as a scrollbar or a frame to class WINDOW, of course it is extremely convenient to have inheritance to get the job done. - When someone else has supplied class WINDOW. However, it suffers from the same problems: Suppose you are holding a WINDOW in your hand, how do you determine if it has a scrollbar or not? New problems: What should a WINDOW answer when asked for it's dimensions? Should that be the size with or without frame and scrollbar. I would lay out my own design for windows, scrollbars and frames, but I don't have the time. G'night, everybody. It's night here, anyway. Followups to comp.object. Anders Munch | Department of Computer Science juul@diku.dk | University of Copenhagen, Denmark Still confused but at a higher level