Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!bu.edu!purdue!haven!mimsy!mojo!disney!disney.src.umd.edu!muller From: muller@src.umd.edu (Christophe Muller) Newsgroups: comp.object Subject: Re: Examples of Multiple Inheritance? Message-ID: Date: 5 Dec 90 19:19:33 GMT References: <60700005@inmet> Sender: news@ra.src.umd.edu (The News System) Organization: SIMULOG - 3 Av. du centre - 78182 ST QUENTIN - FRANCE - Lines: 86 In article <60700005@inmet> stt@inmet.inmet.com writes: > We are looking for an example of a C++ class (or Eiffel, Objective C, > etc.) which is a "true" sub-class of two (or more) parent classes; > that is, it bears the "is-a" relationship to multiple parents. I read a couple of replies and would like to add the point of view of a modeling engineer (i.e., somebody who builds _models_ of _real_ systems to perform discrete event simulations). If MI is necessary for me, it is because MI exists *everywhere* in reality. Just like lists for example (you don't have 56 employees, you have _a certain number_ of employees that happens to be 56 at current time). I want to add however, that I'm not interested at all by speed issues or compiler implementation issues (everybody has his own problems :-). I want a program that does the job first, then if it can be fast it's even better, but that's not the main goal (I'm this kind of guy that prefers Pascal to C and Eiffel to C++ (and also both last ones to both first ones :-)). So let's take an example for MI. This one is extracted from B. Stroustrup's book (The C++ Programming Language): class temporary { ... }; class employee { ... }; class secretary : employee { ... }; class temporary_secretary : temporary, secretary { ... }; class consultant : temporary : employee { ... }; This example seems perfect to me. temporary_secretary IS-A true temporary worker and also IS-A true secretary.. Now the kind of ADTs that these three classes will define is irrelevant for me. I'm using the language first as a _design_ tool. When I'm writing a model of a factory, I start by identifying the types of objects that I could need for the simulation and the relations that they have between each other, *then* I will be thinking of ADTs (behaviors, attributes, etc..) but at the beginning I have no clue what the heck a grinder or a lathe could be used for and even less what characterizes them! Maybe there will be even *nothing* in the class temporary! (so what's the use of MI here? :-D) But it's important for me to write it down in the design document if I have this information. Now it's true that this design may not guide us to the fastest implementation, but once more I don't think it's a good idea of thinking about optimizations while writing specifications or design documents.. However why not thinking about optimizations *after*? If it's _so_ easy to write a program not using MI that does the same job, why not designing some semantic tools that will translate my slow MI-program to a fast non-MI-one? (Note: I have no idea if it's possible or not.. I leave that to the gurus :-) > Our hypothesis is that multiple inheritance can rarely be useful > unless planned for in advance, which seems to defeat the purpose. > If it does require advance planning, then we anticipate that those > situations would be amenable to other structures, perhaps, for example, > a component with a pointer to its enclosing object. I'm not sure to understand this paragraph. What does "planned for in advance" mean? There are always plenty of different possible programs that will solve a problem, but there is only one best (simplest? more readable? more maintenable? more optimized?) one. That's why OO exists. (from Ed Berard's article: "What is OO ...") << It is important to realize that Kay viewed object-oriented techniques as a means of _simplifying_ computer usage. When you hear people say things like, "object-oriented systems more closely resemble 'real life' than do, for example, functional decomposition systems," they are echoing Kay's original intentions. >> That would be my conclusion. I don't think this aspect of "programs modeling real-life" only applies to discrete event simulations. There are plenty of applications where objects are based on existing ones and not only hash- tables or io-libraries. The temporary_secretary example seems rather "cobolian" to me. So should you use MI in your company? It depends on the type of software you write, it depends if speed is an important issue for you (or if like me you are running your simulations at night :-), and it depends whether a "simplification" of your programs is important or not. Cheers, Christophe. = The C Programming Language -- A language which combines the = = flexibility of assembly language with the power of assembly language. = Brought to you by Super Global Mega Corp .com