Of course a class can implement any number of interfaces, as Manoj knows. Unfortunately, they must all be compatible interfaces, meaning that if two interfaces have a method with the same name and argument list, they must also have the same return type and compatible exception specifications. In the present case, where the two methods have different return types, I'm afraid you're out of luck; one Java class can not implement both of these interfaces.
I've never had this come up in real life, but Gosling and Arnold do mention it in "The Java Programming Language."
Instead of having one class implement both interfaces, you might have the class implement only one, and then provide a method like "getImplementationOfIntefaceB()" which returns another object which implements B by calling methods of A provided for this purpose -- that second object could be an inner class.
Bauke is indeed wrong. A class can implement more than one interface. I think he may be confused with extension. A class can extend only one other class, while an interface can extend several interfaces.
As to conflicts like you mention, I've never encountered them in nearly a decade in object oriented programming (most of it using Java) or if I have they were easily avoided by small design changes. Doesn't mean they don't happen, but they're rare enough that you don't need to worry about it. [ October 27, 2006: Message edited by: Jeroen T Wenting ]
perhaps such problems may arise when people like me won't stop calling all our methods "foo" constantly.
Here's an example with two incompatible interfaces. Class A will not compile, even if it doesn't try to implement the methods (as A is abstract).
all events occur in real time
Joined: Oct 08, 2006
Forgive me for my confusion. I probably had a lack of some coffee.
Joined: Sep 11, 2006
Hi friends, thanks for the clarifications. Just to summarize,
1>The conflict is very rare and if it does happen, a slight change in design(say changing the name of one of the interface methods) would solve the problem as mentioned by our vastly experienced Jeroen .
2> Sometimes, we may not be able to make changes to the interface, then we can solve the issue in this way:
We have a class A implement Inter1 and an inner class innerA(or we can use aggregation) implementing Inter2, and have methods foo and foo2(which internally calls the foo implementation of InterfB). It seems like a rarely used design pattern we call it Ernest's Design pattern(inside the scope of this discussion).
We have a class A implement Inter1 and an inner class innerA(or we can use aggregation) implementing Inter2, and have methods foo and foo2(which internally calls the foo implementation of InterfB).
Although methods like foo2() might be useful, I was actually saying that A should have a method getAsInter2() which returns the innerA object. The innerA object is a "view" of A which implements Inter2.