Your implementing class will have one method A and this will satisfy the requirements of both interfaces. It doesn't matter what type of reference variable you use to call it, the same method will always be executed.
Of course you could have found all this out by writing a little test program.
think of it this way... if you promise your friend Thomas that you will wear a red shirt tomorrow, then you later promise your friend Michael you will wear a red shirt tomorrow, do you have to wear two red shirts?
It's the same with interfaces. you're promising to implement a method, you're just promising twice.
The two methods with the same signature must have the same intent in their respective interfaces,
Campbell, we're gonna have another disagreement. I think "must" is too strong a word. "Should" or "Hopefully will" i think would be better. nothing forces them to be similar - it is not a requirement.
Now, if they don't, you're gonna have problems somewhere, but 'must' is just not a word i would use to describe this.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
I would say must. Not as far as syntax is concerned but if the intent of one of the methods is not adhered to, its contract is broken and the code can be considered as broken.
Using your analogy, if I promised Michael to wear a blue shirt instead of a red shirt, and I can't wear two shirts, then I will have to break at least one promise. The same can hold for the methods: if keeping one contract would mean breaking the other then it's in fact a bad idea to implement both interfaces.
Instead you can choose to create a method that returns an object that implements the second interface instead:
[ November 28, 2008: Message edited by: Rob Prime ]
Disagree. "Must" is too strong a word and implies that the program will not work if violated. "Should" better captures the fact that everything will work, it just may not make semantic sense and is poor practice.
Originally posted by Bear Bibeault: Disagree. "Must" is too strong a word and implies that the program will not work if violated.
But if the user expects the behaviour of the second interface but gets the behaviour of the first interface, does that not possibly lead to a broken program?
But before we start a lengthy discussion that probably can't be won by either side, let's just say that this case should be prevented at all times. Breaking contracts is bad practice period.
Joined: Oct 13, 2005
Rob and I seem to be in agreement. Fortunately I think such a collision of incompatible intent will be rare.
I think the problem can be resolved if the interfaces' "intent" is non-specific. Look at the add() method in the List, Collection and Set interfaces, and how vaguely it is defined in Collection. That is an "intent" which is meant to be interpreted freely.
As Rob points out "hopefully will" means you might not fulfil one of the contracts of the interfaces.