Yesterday I met Rémy Fannader, author of Caminao: a simple but very powerful modelization approach compatible with MDE practices. During a part of the discussion about how wide was the modeling state of art (as wide as at least one track for each artist ;D), popped out a simple illustration question: “May an abstract class inherit from a concrete class?”.

Remy’s answer is: “No, because the property “instantiable” from the parent class may not be verified by the child class”. Let’s challenge this sensible answer…

1. From a requirements expression standpoint (my interpretation of Rémy’s standpoint)
   An abstract class is not instantiable because it doesn’t match with a real life business object. Abstract classes may be used during analysis time to merge various uses cases, but if we admit use of  inheritance a specialized class always inherits from a concrete class.
   And in another way, multiple inheritance produces critical problems  as soon as we want to prove that the analysis model match appropriately with the business need. Mathematical proofs are given by Lyskov (IMHO Lyskov just explains how transitivity applies to inheritance).
   So an abstract class may not derive from a concrete class in a requirement model.
2. From a requirements expression standpoint, alternative version…
   An abstract class is by definition a class that can’t be instantiated. So, the propriety “instantiable” has some value at instantiation time, but before this time it doesn’t mean anything worthwhile!? Let’s imagine that we define some value to the “abstract” property during modeling time ; by example saying that abstract means “does not represent any real life business object”. Such an abstract class still may be useful at modeling time to represent… Say a type of non abstract classes? I can’t see, at modeling time, why we couldn’t have a class hierarchy as X (concrete) > Y (abstract) > Y1, Y2 (concrete). Following Lyskov rules, Y1 & Y2 inherit from X’s properties. No problem.
   By the way, multiple inheritance neither cause any problem at modeling time. As far as we don’t apply instantiation.
3. At PIM time with generation/constraints?
   No way. This is not a question. What does become an abstract class when trying to generate/transform it into a programming object is irrelevant. A PIM is independent from any specific platform, so as from any programming language.
4. Why using an abstract class into a model if we can’t instantiate it?
   Because it has been found useful and valuable by the person who used it in the model!
   For sure the “interface” notion, in Java by example, is a good way to instantiate  this class. And furthermore, even without such a notion, an abstract class may be compiled. The resulting executable object just contains pointers that are to be resolved later. At link time (static or dynamic library) or even at execution time (through indirection parameters, code injection at runtime…). We could even imagine that the instantiation details decision are left to a programmer that will fill up the code generated from the model.

Conclusion:

If we consider the question from a modeling context where the concrete/abstract instantiation properties mean something, as far as modeling is concerned an abstract class may inherit from a concrete class in a PIM… Unless modeling validation rules forbid it. Answer may be yes!

If we talk of modeling a program targeting a specific programming language… The answer is given by the language compiler!!

Well, how all this is related with lazy modeling? Answer is: don’t model with compiling constraints. For compiling matters we’ll see later…

PS: I found this idea of “lazy modeling” while walking this morning toward my office, inspired by Paris’s nice streets. Surprisingly (not so in fact as it becomes harder and harder to invent something today ), I found one interesting paper on this idea of “late binding” for models:
http://www.ics.uci.edu/~tproenca/icse2010/flexitools/papers/12a.pdf

Featured image taken from http://www.sanaeishida.com/weblog/