ClothingList implements Clothing, List? Not!
No language is perfect, but as languages go, Java comes as close as any I know. So what should one do when one likes a language a lot?
Criticize it!
One of Java's deficits is its lack of disambiguation of declared methods whose names conflict. Imagine you have a class, ClothingList that implements two interfaces, say List and Clothing. It's going to be a list of your closet contents, with the additional stipulation that the articles all fit you. (Yes, it's a kinda lame example. It's after midnight.) Both interfaces declare a method "size()". List.size() is of course intended to tell you the number of items in the list, while Clothing.size() is intended to tell you how big the articles are (medium, thank you).
What we really want is a way to implement both methods and then distinguish between them. Java doesn't do this. It assumes that if two interfaces both declare a method with the same signature, then clearly they must be intended to do the same thing. And should they declare a different return type, then Java will not let you implement both interfaces at all.
So this:
public class ClothingList implements Clothing, List {
public String size() {
return null;
}
}
interface Clothing {
String size();
}
interface List {
int size();
}
isn't even legal.
This leave us with an unpleasant decision to make. If we control the interface Clothing, then we can just change names. If we don't, then we really can't use that interface at all! We could do some crazy stuff with delegates, but calling outside methods that expect a Clothing item is going to be awkward. Been there. Done that. Didn't like it.
The point is that a language should support us in what we want to do. We shouldn't have to adjust our design to fit the language.

