How to avoid multiple inheritance

Specifications BMM/Expressions
1

multipleinheritancebmm
multipleinheritancebmm1196×667 118 KB

This is a part of the inheritance schema from the BMM, the part with the three classes which have multiple inheritance in pink, and on the right and left where they inherit from, left are interfaces because that is a Java-trick to do multiple inheritance.

But the trick is not good enough, especially in Spring, and calling superclasses to return subclasses, there are problems. So this brought me to thinking.

I understand one purpose to do inheritance is to avoid code-repetition, but there other ways to avoid that.

I think the real good reason to do inheritance is, that when there is a IS-A relation between classes.

The other way to avoid code-repetition is to detect a HAS-A relation. In that case, a class to inherit from can also be a property instead of a superclass.

I think that the pink-classes have an IS-A relation with the blue/green classes, and that the relation with the orange interfaces can also be seen as a HAS-A relation.

In that case, multiple inheritance is no longer necessary in this model.

I would appreciate if you would consider such a change.

Thanks very much for thinking it over

Bert

2

I had been meaning to address that at some point. Hopefully this helps.

3

I will study it carefully. The problem is, I am making a JPA/Spring implementation, and JPA has difficulties with working with multiple inheritance-trees. But I am not done trying all JPA (mixed form) inheritance possibilities, so I will report back in a few days, how this works out for me.

Thanks
Bert

4

Well the approach there will work in Java, so it should be fine. Interested to know how you go.

5

The point in JPA/Spring code is that it is part of a framework. Using this framework means having a lot of advantage in other parts of the framework. Most enterprises only accept code that is written in JPA/Spring.

Using JPA/Spring also accepting its limitations. There are not many. But one limitation is that multiple inheritance is a big NoNo. There is no way of having a semi-multiple inheritance construct with interfaces and then still having all the JPA advantages. That is for people who reinvent the wheel, and they produce a lot of code which is often hard to maintain and hard to debug. They go for a wild road with many unexpected dangers. Snakes in the grass, dangerous bugs which can bite.

So the JPA programmer needs to rethink a model so that it can fit in the JPA philosophy. That means that sometimes the semantics of the code need to be traded against purpose of the code.

The IS-A concept in JPA is very strong. You can query a class for its routines and in one line of code retrieve both the functions as the procedures, because they are inherited from routine. This query will occur in a BMM framework many times. A web-interface will want to do these kind of things.
In this query, the inheritance construct is very important.

So having an inheritance tree for the BMM-DECLARATION side of my diagram is essential.

But do you ever query in a live BMM-model for all the entities which have a specific type or which can return null? Semantics have a price. One must ask if it is worth it in a specific situation.
So from purpose-wise, this is not necessary. Nullablity of a BMM_ROUTINE can as well be a feature instead of being brought in by inheritance, and thus it can be in a HAS-A-relation.

The fact that the BMM-created-models can support multiple inheritance does not mean that multiple inheritance must be a part of the BMM. The semantic power of the BMM-models do not have to be part of the BMM itself.

A database is not written in SQL, it offers SQL.

So, after long thinking (it is a hobby project, there is no deadline), I decided to replace the multiple inheritance IS-A relations by HAS-A relations.

Thanks for the discussion.

Best regards
Bert Verhees

6

Hi Bert,
I am not sure why you would want to map the BMM model to a DB table structure, which is what it sounds like you are doing - this is the reason for the Spring limitations AFAIK. Normally BMM is serialised to a text file, not DB data.
Also, the substitutability inheritance hierarchy you will want is from BMM_TYPED down (because there is some static typing elsewhere in the model, e.g. the Expressions part, that depends on that), not from BMM_DECLARATION down. The latter can be modelled using ‘has-a’ relationships.

7

I am not using Spring for the JPA, although it was a pleasant advantage in Spring.

I am not mapping it anymore to a DB table, it was my first setup, but I changed my mind. I am storing it in a MongoDB as a document. It is much simpler this way. There is no advantage in storing it into DB.
Also the multiple inheritance issues are easier to solve now.

But I have another problem, I come back to this in another subject