doubt on mutiple inheritance

java does not support multiple inheritance of classes to prevent inheritance of a same method or a variable twice or more and to prevent any discrepancy regarding it but however it supports the same through interface and will not the same discrepancy creep in here?
pls explain

Yes, it will. For example MyClass won't compile:

then y is that multiple inheritance is allowed thro interface when it is not the case in a class???

Sorry, no idea.

(Please read this).

Apart from the spelling:

The reason multiple inheritance is allowed via an interface and not via classes is that the designers of Java decided so.

You can have multiple inheritance via classes; C++ and Eiffel use it. In fact, I am learning Eiffel at the moment and Bertrand Meyer who designed Eiffel doesn't only take the opposite approach from Java with just about every decision made, he also says Eiffel is right and Java is wrong.
I think the reason Gosling chose this approach was to keep the language as simple as possible. Ther is a white paper on the Java website which explains that, but only very briefly.

That same white paper says there are no more enum types, but when we get to J2SE5.0, we find the enum type has reappeared. Also generics which were available in languages like Eiffel and Smalltalk were dropped by Java, and reintroduced in J2SE5.0, because of requests (or maybe complaints) from developers.

CR

so is that there is no specific reason, why multiple inheritance was allowed in interfaces but it is not so in classes?

Here's how I justified it in my own mind just so I could go on with life ...

If you implement two interfaces with the same method signature and you decide they both have the same semantics you can implement one method to satisfy them both. If you decide they don't have the same semantics you probably shouldn't implement both.

If you extend two classes with the same method signature, the compiler has to make some decisions for you about which method to call. Unless we add new syntax to let you specify which one to call.

So Java trusts humans to make their own choices about interfaces, but doesn't put the compiler in the position of making choices about classes.

BTW: How does Eiffel handle it? Can you call a method on an object without knowing the object's class extends two different classes with the same method? How do you avoid breaking the Law of Demeter?

Originally posted by Stan James:

BTW: How does Eiffel handle it? Can you call a method on an object without knowing the object's class extends two different classes with the same method? How do you avoid breaking the Law of Demeter?

I can give the answer for Perl. The list of multiple base classes that a class subclasses is ordered. If a method (sub) is not explicitly defined in the leaf class, a depth-first search of the inheritance hierarchy is done trying to find the sub.



...would produce...

Hello from class A
More from class B

It's a beutiful thing.

I'm not sure I understand your Law of Demeter question. Does the LoD concern itself with where the methods that methods are allowed to call is defined or how inheritance is handled? As long as the programmer verifies that a multiple inheritance hierarchy is done correctly, then it's just like any single inheritance scheme. i.e. We don't need to know exactly what class defined a method as long as we can get to it, via certain object references.

The simplest explanation is not to think of implementing interfaces as inheritance, but rather to think of implementing interfaces as "Upholding a contract". The purpose of an interface is to make sure that it's implementing classes contain two things: 1) the constants defined in that interface, and 2) an implementation of the methods defined in that interface.

With this in mind, and using your example above, interface One and interface Two both define a method doStuff(). Same signature, same return type. As far as "upholding the contract" goes, implementing both of these interfaces will definitely uphold the contract. So it's not an issue. It's terrible OO design, but it's legal... if this weren't legal, than no two interfaces would be able to contain the same method name and signature, even for totally unrelated interfaces that will never be used together. Where you will get in trouble is if you do something like this:


Because of polymorphism, we get the behavior of the actual instantiated class. The point of the code above is that using interfaces the wrong way may lead to unexpected behavior, and more importantly, when combining interfaces with methods that have the same name and signature we can quickly lose desired functionality. It's this reason why care must be used with interfaces (as well as multiple inheritance in C++ and other fine languages). Because something is legal doesn't mean we should look for ways to abuse it.

As far as I know if you are implementing two interfaces containing methods with same signatures, your implementing class (which is going to implement both these interfaces) can and will have only single implementation for both these methods.

Hence no multiple inheritence problem.

How does Eiffel handle it?

I haven't got that far yet, but having a quick 2-minute look at the chapter (in Meyer B, Object Oriented Software Construction 2/e, Upper Saddle River NJ: Prentice Hall, 1997, page 519ff) suggests:-

In Eiffel you can inherit from several classes, some of which eg STORABLE, COMPARABLE, have similar functions to well-known Java interfaces like Serializable and Comparable

Each class you inherit from can have concrete methods, not just the abstract methods you find in Java interfaces.

If you have a function foo in both parent classes, you cannot inherit, BUT you can rename the foo from one parent class (or both) in the child class.

You cannot have two different versions of the same function with the same name in the same class.

I can see where Meyer is coming from saying that double inheritance is useful; it would be nice to have concrete methods one can take from an "interface" like structure without having to implement them the same several times.
I haven't however used this renaming yet, but it sounds a bit awkward.

CR

I think the simplest reason for omitting multiple inheritance from the language was that the extra complexity wasn't worth the extra benefit (which was small, in the designers' minds).