Should We @Override an Interface's Method Implementation

Should we @Override an interface's method implementation?

You should use @Override whenever possible. It prevents simple mistakes from being made. Example:

class C {
    @Override
    public boolean equals(SomeClass obj){
        // code ...
    }
}

This doesn't compile because it doesn't properly override public boolean equals(Object obj).

The same will go for methods that implement an interface (1.6 and above only) or override a Super class's method.

Can we override an interface method with visibility that is not public?

If the method signature you defined in interface has public access specifier then you have to override that method, with the same method signature (that means with public access specifier) whenever you implement the interface to any class.

Implementing a method of interface is overriding or not in java

The term "overriding" applies when there is an existing implementation of the method . The correct term is "implementing" for interfaces and other abstract declarations.

The @Override tag is used for both cases - it is used when:

The method does override or implement a method declared in a supertype. --javadocs

And from Wikipedia:

Method overriding, in object oriented programming, is a language feature that allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes.

Note that interfaces can have default methods - redefining these methods overrides them:

When you extend an interface that contains a default method, you can ... redefine the default method, which overrides it.

Besides linking to "canonical" sources, I'm not sure what advice to offer on winning a semantic argument with your friend. Perhaps you could ask him what the distinction is between "implementing" and "overriding", and what word he would use instead of "overriding" for the concept of redefining an existing method.

Why do we need to override abstract methods from an interface?

See here by default your ide will add this method to SampleClickListener, and you need to add on click implementation for your application here.
Using override is not necessary, but it is highly recommended. It warns you when you write a function that you think overrides another one but you misspelled something.

Why can't I override my interface methods?

Interface's methods are not overriden, they are implemented. You are confused with abstract/virtual methods which can be overriden.

Example:

public interface IFoo    
{
    void DoA();
}

public abstract class BaseFoo : IFoo
{
    public void DoA() { } // *this HAS to be implemented*
    public virtual void DoB() { } 
}

public abstract class MyFoo : BaseFoo
{
    // *this CAN be implemented, which would override the default implementation*
    public override void DoB() { } 
}

As others metioned, ToString is a virtual method of the base class object, that is why you can override it.

Why should we use interface if we can simply override methods of the superclass or use abstract classes?

To explain why interfaces are used, you have to first understand a problem with inheritance. It's called the Diamond Problem. Simply, if a class, D inherits from two classes B and C, and B and C both inherit from the same class A, which implementation of the methods from A does D get?

What we're left with is a method ambiguity that Java does not like! So the way of preventing this is to make sure that D can only ever have one superclass, so it could inherit from either A, B or C, but never more than one. So that prevents the problem, but we lose all of the perks that multiple inheritance offers!

Enter the Interface. This allows us to have the perks of multiple inheritance (referencing the single class as various different types) and still avoid the diamond problem, because the implementing class provides the method. This removes the method ambiguity.

This means that, for example:

public abstract class MyClass {
    public void doSomething();
}

public class MyConcreteClass extends MyClass {
    public void doSomething() {
        // do something
    }
}

You can either refer to an instance of MyConcreteClass as

 MyClass class = new MyConcreteClass();

or

 MyConcreteClass class = new MyConcreteClass();

But never anything else, given this implementation. You can't extend more classes because you'll potentially get the diamond problem, but you CAN include an Interface

public class MyConcreteClass extends MyClass implements Serializable {
}

All of a sudden, you can say..

Seralizable myClass = new MyConcreteClass();

Because myClass is a Serializable. This is excellent for decoupling classes from one another, when a method might not need to know that it is an instance of MyConcreteClass, only that it has a necessary subset of methods.

In short: You can implement many interfaces, but you can only inherit one class.

---

Related Topics