michael.daly@canrem.uucp (michael daly) (02/07/91)
I've been following this topic with considerable interest. I'm fairly new to the field of Object Oriented Construction but have been lucky enough to work with a "whiz-kid" system architect and have been exposed to some of the difficulties in OOC. In particular, he has exposed me to the general disrepute into which multiple inheritance has fallen . I've been thinking, in vague terms, about this and related problems. Since my only exposure to OOC has been in conjunction with relational databases, I tend to think in that context (I am not an expert in either OOC or RDBMS). I think that our current topic, with Paul Johnson's input, has verged in a direction I've been thinking. I will be quite vague in my description, as I've not fully thought out the whole thing; imagine lots of hand waving and stuttering while I present this (sort of like the wild-haired, pipe smoking academics at whose feet you (used to) rest in grad school). I present this only in the hope of stimulating the thoughts of some of you in a direction that might (might not :-) ) be a little different. paj@mrcu (Paul Johnson) said recently: >Yes. I have been thinking along precisely these lines and have come >up with some ideas which I call "Fine Grain Inheritance". Below is a >short summary. I have a couple of papers submitted to `Software -- >Practice and Experience' and ECOOP '91. (No offence to the TOOLS '91 >people, just a matter of timing). >I believe you should split your class up into lots and lots of little >superclasses, each implementing one elementary concept (such as "first >item" or "read/write current item") and usually having only one or two >attributes. Then go through your class hierarchy and split all >classes up into "read-only" and "write-only" variants. Then implement >them. Don't be frightened of the large amounts of repeated >inheritance you wind up with, its OK. Most of your classes will be >deferred and you should make all attributes into deferred functions as >well, hence allowing them to be either functions or variables in >descendant classes. ...stuff deleted ... >These ideas allow the development of totally flexible class libraries. >The only problem comes when coarse grain libraries must be reused as >well. >Of course, tools like "flat" and "short" become absolutely vital in >fine grain libraries, as does multiple inheritance. One of the things that theorists like about relational databases is the fact that there is no redundancy in the data. If you imagine a relational database (as I tend to) as a single, giant, multi-dimensional array with perfectly normalized data, we can construct any view of some aggregate data by taking a "row" out of this array. No data element will occur more than once, though it can appear in more than one "row". If we change the data in one view, the data is automatically updated in the other view. Now, let's suppose we're putting together an application. We initially set up a normalized, relational DB of all the data elements to be used in the system. Each of these data elements is, in an OO environment, a simple object which will have methods attached. We can create the data structure portion of the more complex objects as "rows" in this relational DB. In an OO sense, these more complex objects will inherit, from multiple simple objects, all of the methods of the simple objects. This seems to be what Paul Johnson is saying, though he puts it in a more elegant way. And, as he says, it requires multiple inheritance. It seems to me that what we need is the object-oriented equivalent of a "methods view", i.e. we need a way of accumulating the methods of simple objects into the methods of a complex object in a "relational manner". If the data is truly normalized, would the methods included not be truly normalized as well? What I mean by this is - in a traditional OO environment, multiple inheritance is frowned upon, in part, because of a confusion as to which of two redundant methods should be used if a method occurs in both of the parent classes. Now if the simple objects I described above are normalized, would the inherited methods necessarily conflict? For example, assume we have two simple objects, item_for_sale and cost. Both of these have a method: show_yourself. We can construct a "complex" object inventory_item defined as both item_for_sale and cost. The method inventory_item:show_yourself would be a simple concatenation of the two methods for the two inherited data elements. There would be no conflict; in fact they two methods would complement themselves. If one of the simple methods is changed, the complex method would automatically change - it would not need to have been overridden by a new method in the complex object; from a maintenance perspective, it's nice. Now the question: Is it possible that there is a way of defining "relational" methods that would not be redundant - thus allowing a special case of multiple inheritance without difficulties? Just a thought. michael.daly@canremote.uucp --- ~ DeLuxe}ab #289 ~ -- Canada Remote Systems. Toronto, Ontario NorthAmeriNet Host