I’m reproducing a picture that Jean posted in google plus to exemplify multiple inheritance.
I don’t like the mechanism of multiple inheritance (at the conceptual level is sometimes useful but too easy to get it wrong and at the implementation level is just a nightmare since most technologies do not support it so you are forced to find a workaround for it), this examples shows that sometimes is a very elegant solution to express the relationship between a set of concepts. What about you? Do you use multiple inheritance in your models? If so, how do you then deal with it during code-generation?
UPDATE: Via Jean, another great graphical example of multiple inheritance (Jean says that “the drawing below is composed from a Venn Diagram of Twitter@@LeBlancRose_”).
FNR Pearl Chair. Head of the Software Engineering RDI Unit at LIST. Affiliate Professor at University of Luxembourg. More about me.
Interesting post, Jordi.
I’ll relpy by saying something that has been said a lot of times: inheritance is just a mechanism by which the conceptual semantics of generalisation/specialisation take place. In my opinion, things become clearer if we think of multiple generalisation rather than multiple inheritance. In the picture above that Jordi has posted, I should see a class (AwkwardBenchBarrow perhaps) that is doubly (multiply) generalised into two other classes (Bench and WheelBarrow).
From a conceptual modelling point of view, this is not a problem at all. The fact that few situations in real life need to use this feature of modelling languages doesn’t mean that the feature should be deemed illegal; cardinalities of exactly 6 (for example) are also uncommon but we don’t ban them!
My work involves a lot of conceptual modelling the cultural heritage realm. A recent example of genuine need for multiple generalisation is that of the concept of Structure. To our domain experts, a structure is “a place that has been delimited through the addition, modification or removal of matter”; examples are a building or a cave, but also a fireplace or a pit. Structures have a strong spatial aspect (they are places) plus a strong material aspect (they are made of stuff). Having classes in our model for Place and Material Entity, it was only logical to make Structure specialise from both. After much analytical checking and fieldwork testing, this model still looks good. So far!
In summary: yes, multiple generalisation makes sense, especially at the conceptual level. The ConML (www.conml.org) language that we have developed for conceptual modelling does support it and encourages judicisouly use of discriminants.
Whether your implementation language of choice makes things easy or hard at the code level is another story altogether. But again, we shouldn’t judge a conceptual construct by the merits of the implementation tools.
Happy to discuss. 😉
César, I´m not saying that we should ban multiple inheritance. As the picture “proves” there are occasions in which is so much better that other representations that we should use it. I´m just saying that we should make sure every time we use it we are before one of these cases, given the complexity that using this construct brings to the model. Not only when aiming at generating code from the models but also at the model-level itself. I´d say (but without any evidence) that using multiple inheritance can negatively affect the comprehension of the model.
Cesar, I agree with you concerning the need to keep separated conceptual and implementation constructs. But when both are used as tools to build complex systems, they play an instrumental role. Hence, transitioning smoothly from analysis to design and implementation can be a crucial in order to realize a maintainable system.
This is my cent 😉
Andrea
I agree with Andrea on this. In an ideal world, we should be able to use the best modeling constructs to represent the domain but in the real one bridging from high-level models to low-level code has a cost so using modeling primitives that make this transformation difficult has to be very justified. I´m just not sure that this is the case of multiple inheritance.
Hi,
interesting and funny. But, are they really examples of multiple inheritance? I believe those are rather examples of multi-instanciation.
Cheers.
True, the pictures show insantiations of the classes that form the multiple inheritance relationship (e.g. class PolarBearGuitarPlayer, DuckPianoPlayer,…)
I agree that multiple inheritance is often conceptually dubious – and I think we need a modelling language that supports mixins (for things like consistent attribute name/type sets) that are not conceived of as object types (and I don’t mean XML Schema 😉 But what we get with O-O is Classes, and so we use inheritance…
|<