"Modeling the real world" in the sense you seem to be using it often leads to quite inferior, if not totally inadequate, designs.
Let's take your example - there are a whole load of problems with having a Child class inherit from Mother and Father classes:
- a Child can be - or at least become - a Mother or Father, too
- a Child doesn't inherit all attributes and operations from both Mother and Father - it inherits some from Mother, some from Father
- when we talk about inheriting attributes, in your real life example we mean attribute *values*, like eye-color: green. In class inheritance, we mean the *existance* of an attribute, such as "has an eye-color".
- object oriented programming is much more about behavior (operations) than attributes. And by that, I mean the behavior of objects in the software system, not the behavior of "objects" in the "real world".
So, before we can decide on a design, we need to know what the system is supposed to do, and what design forces we therefore experiences *in the code*.
For example, for some system, it might in fact make more sense to have Person class with two attributes "father" and "mother" that again point to Person instances.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jun 18, 2003
Thanks for the wonderful explanation, and I completely agree.
What I am still interested in knowing is that let us say we are in a situation where we are designing a medical system that keeps track of attributes / behaviors inherited from parents into child and clearly identify that it is inherited from father or mother....so there are 3 important entities father , mother and child.
Then in such a scenario what should be a good approach to start with our class design?
IMO that makes it difficult to easily identify features that are inherited from both mother and father, although obviously that's a matter of a simple utility method. To me it seems like features exist as an isolated trait, and *may* be inherited from the mother, the father, or nobody: maybe it'd make more sense to have a map of features, with a possible list of who they're inherited from.
Joined: Jul 05, 2005
David Newton wrote:IMO that makes it difficult to easily identify features that are inherited from both mother and father
No problem, just add getInheritedFeaturesFromBothMotherAndFather method.
Actually, I just want to point out that this requirement needn't multiple inheritance at all.
Multiple inheritance--and all the problems it generates--was discarded from Java. The desirable features of multiple inheritance are provided by interfaces--conceptually similar to Objective C protocols.
A Java-based "interface" class is a type of "class." A Java-based "concrete" class is also a type of "class."
The Java language supports multiple inheritance of interface classes, not concrete classes. A deep understanding of "what a class is", is required to accurately interpret the material on the web pages referenced above.
With only a cursory understanding, limited to web page content only, then it will be difficult know what it means when it is written, "Java does not support multiple inheritance."
Again, the Java language supports multiple inheritance of interface classes. The author of the material quoted above chose not to include the adjective "concrete." That is all.
Java's alternative to mulitple concrete class inheritance is mulitple interface class inheritance.
Good discussion. I would like to follow this. I am still not sure what I should be the correct answer. Interfaces are like contracts without the implementation details. Not sure if they would classify as inheritance