Java Interfaces – Implementing Methods with the Same Signature

inheritancejava

I recently found out that I can have two interfaces, one containing a method with the same signature as a method in the other interface. And I can have an interface or class that implements both of afore-mentioned interfaces. So the descendant class/interface implicitly implements two different methods as one method.

Why is this allowed in Java?

I can see numerous problems arising from this. Eclipse, for example, can only find out about implementations for one interface method, but for the second one it doesn't show any implementations at all. Also, I believe that there would be problems with automatic refactoring, like when you want to change the signature of the method in one of the interfaces and the IDE will be unable to correctly change that signature in all implementations (since they implement two different interfaces, and the IDE cannot tell which interface method the implementation is referring to.)

Why don't just make a compiler error like 'interfaces method names clashes' or something like that?

Best Answer

There is no reason why this should be forbidden. The only point of an interface is to ensure that a method with particular signature exists in each implementing class. This is satisfied by any implementing class even if the condition is posed twice.

Granted, when you write an interface you presumably expect a certain meaning for the action of invoking the method, and presumably you document it above the declaration in the interface, but that is not the concern of the compiler. It cannot check whether the implementing class does the right thing, only whether it copies the signature exactly. Asking "Why doesn't the compiler forbid one method to satisfy two interface declarations?" boils down to "why doesn't the compiler prevent me from implementing the wrong semantics when I implement an interface?", and the answer to that question is much easier to see: because it can't! (If the compiler were able to judge your method implementation and forbid it if it contained a bug, then we wouldn't need programmers in the first place, we'd need only the specifications and the compiler.)

Obviously we would like it if implementing an interface guaranteed that the implementing class does the right thing, but that's not something that interfaces can do for you. In fact, I'd argue that it would be a bad thing to add a feature to the compiler that might give the impression that it is!

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

When you need a part of the class to be implemented. The best example I've used is the template method pattern.

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

Thus, you can define the steps that will be taken when Do() is called, without knowing the specifics of how they will be implemented. Deriving classes must implement the abstract methods, but not the Do() method.

Extensions methods don't necessarily satisfy the "must be a part of the class" part of the equation. Additionally, iirc, extension methods cannot (appear to) be anything but public in scope.

edit

The question is more interesting than I had originally given credit for. Upon further examination, Jon Skeet answered a question like this on SO in favour of using interfaces + extension methods. Also, a potential downside is using reflection against an object hierarchy designed in this way.

Personally, I am having trouble seeing the benefit of altering a currently common practice, but also see few to no downsides in doing it.

It should be noted that it is possible to program this way in many languages via Utility classes. Extensions just provide the syntactic sugar to make the methods look like they belong to the class.

Java, Refactoring – Why Delete Method/Field/Function Refactoring Doesn’t Exist in Eclipse

The reason is, this feature is not yet implemented - see Bug 39715 Add Refactor/Remove interface method and all impls. [refactoring] in Eclipse issue tracker:

Here is something I am running into now. I am cleaning up a bunch of code that removes no longer needed methods from interfaces and all implementing classes. Right now, this is quite a tedious processes. It would be helpful to have a refactoring such that I could select an interface method and delete it along with all impl. methods in all classes...

Above request has been in turn marked a duplicate of Bug 24379 [refactoring] Change interface signature:

When adding or removing methods in interfaces it would nice to have the possibility to add or remove the method automatically in implementing classes. When adding methods it should also add a task with the note implement this method...

Bug 24379 seems to be laying dormant for more than 10 years now, "Reported: 2002-10-04" and "Target Milestone" field is not yet set.

Best Answer

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

Java, Refactoring – Why Delete Method/Field/Function Refactoring Doesn’t Exist in Eclipse

Related Topic