Interface VS Abstract

[gahhon]

Based on my understanding, both are doing the same way which also kind of override the methods.

Abstract method is, both childclasses are having the same methods, but different execution code.
Interface is, whenever the class implement the interface class, the class must write the execution of all the methods define in interface class.
Is my understanding correct?
If so, is possible not to use some methods?(no matter on abstract methods/interface class)

Thanks for the advance explanation.

[stultuske]

You can have an abstract class without any methods, and you can have abstract methods which only contain non-abstract methods.

so: 'both childclasses are having the same methods, but different execution code', not always.

public abstract class Person{

  private String name;

  public Person(String name){
    this.name = name;
  }

  public void sayYourName(){
    System.out.println(name);
  }
}

This is a perfectly valid abstract class. Why should it be abstract? Well, Person is a bit abstract, wouldn't you say? You'll want to specify it further, for instance using childclasses Man and Woman. So, at first sight, they 'll have the same execution code (of course, they can always override it).

An abstract class is a way to set a base for your subclasses. It's not specific enough for instantiation to be usefull, but it cal already provide business logic (through implemented methods). It can also provide abstract methods.

An interface is more a contract. It states what to do, just never how to do it. (becomes a bit closer to actual inheritance since Java 8 with default methods, though)

Do you need to implement all the methods in an extended abstract class or an implemented interface in your class? Yes, and no.

The rule is, your sub- or implementing class must provide an implementation (if it's not an abstract class itself), but that is not the same. (at least, in the case of your interfaces). It can already inherit the method from a superclass.

so:

public interface BeNice{

  void sayYourName();

}

public class Me extends Person implements BeNice{

}

Even though Me extends BeNice, I don't have to put the method sayYourName in there, because it is already inherited from Person. Your class provides an implementation, and that's good enough for the compiler to work with.

Do your abstract classes or interfaces need to have methods in them ?

No. In case of interfaces, we then talk about marker interfaces (like Serializable), that just mark implementing classes, so they 'll pass a needed test for some functionality:

if ( MyClass instanceof Serializable) okSerializeIt();
else forgetItAndThrowAnException();

Marker interfaces still exist, but the last years they are more and more getting replaced by annotations.

Same is possible for abstract classes, but there's not much use for abstract classes that don't provide an actual basis to build your subclasses on.

If you come in a situation where you need to use one, and you don't need to provide basic business logic (actual implemented instance methods), it's better to opt for an interface. In the end, you'll only be able to extend the one class, but there is no limit as to how many interfaces you can implement.

[gahhon]

Sorry i don't get your point.
Perhaps i use an code picture to represent my understand.

public abstract class Figure
{
    /* because this is an abstract method the 
       body will be blank  */
    public abstract float getArea();    
}

public class Circle extends Figure
{
    private float radius;

    public float getArea()
    {
        return (3.14 * (radius * 2));   
    }
}

public class Rectangle extends Figure
{
    private float length, width;

    public float getArea(Figure other)
    {
        return length * width;
    }
}

This is an abstract class with abstract method.
So if a class extended on it, do the class neccessary to define the method?
What if i define one more class which extends to Figure, but i am not using the method of getArea()?

An abstract class with an abstract method which mean the superclass/baseclass having the a method which applicable to all childclasses?

[JamesCherrill]

An abstract class is a class with one or more methods declared abstract (ie the signature is declared, but there is no implementation. Becuase one or more methods are not implemented, it is not possible to create an instance of an abstract class.
An abstract class can be extended by another class. If that class does not provide implementations for all the abstract methods then that class is also abstract, and cannot be instantiated.
Eventually you get to a subclass or subclasses where every method has an implemention (inherited, or defined in that subclass). Now that subclass is not abstract, and you can create instances of it.

[stultuske]

James: I disagree on this:

An abstract class is a class with one or more methods declared abstract (ie the signature is declared, but there is no implementation.

an abstract class doesn't need to have an abstract method, it just has to be declared as abstract. I agree, there is little or no point in having an abstract class which doesn't contain an abstract method, but still.

Gahon:

What if i define one more class which extends to Figure, but i am not using the method of getArea()?

Good luck in getting that baby compiled. As I explained earlier, each subclass of your abstract class (or that implemented an interface) must either be abstract, or must provide an implementation for each and any abstract method provided by said abstract class or interface.

But, no, this does not mean it has to be in that exact class.

public abstract class Do{
  public String doThis();
}

public interface Rules{
  public int getNumber();
}

Here, we know that each subclass of Do must provide an implementation of Do.

  public class Test1 extends Do{
    public String doThis(){ return "done"; }
  }

is correct. It extends Do and it provides an implementation for the method.

public class Test2 extends Test1{ }

This is also correct. It does extend Do, but it doesn't provide it's own implementation of doThis, it just inherits the implementation of Test1.

For an interface, it might be a bit more confusing if you just start out.

  public class Test3{
    public int getNumber(){ return 3; }
  }

No reason to wonder here, this class is not related to the interface, but it does provide an implementation for getNumber(). Remove the method, and it'll still be valid, since it doesn't implement the interface, and hence isn't bound by the contract that it must provide an implementation.

public class Test4 extends Test3 implements Rules{}

Here, the interface is implemented, but there is no implementation of getNumber in the class. But, still, it is valid, because you inherit the implementation described in Test3. So => It does provide an implementation, but it doesn't have to be in that class.

[JamesCherrill]

stultuske: yes - you are right. The JLS says
"A class type should be declared abstract only if the intent is that subclasses can be created to complete the implementation...", but it does not prohibit such a declaration.

[gahhon]

stultuske

According to your post.
An abstract class is not neccessary to have abstract methods. So is it possible the subclasses not to use all of the methods of the abstract class?

Since the abstract and interface is slightly similar. So in what situation i have to apply abstract or interface?

[JamesCherrill]

No. If you have any abstract methods then the class MUST be abstract.

There's no need for subclasses to use any of the parent's methods if they don't want to. But the compiler doesn't know all the contexts in which the subclass may be used, so it has to ensure that you could legally use any of those methods.

[stultuske]

According to your post.
An abstract class is not neccessary to have abstract methods. So is it possible the subclasses not to use all of the methods of the abstract class?

sure, but if the subclass is not abstract itself, it will have to provide an implementation, whether it will be used or not.

so, let's say you have

public abstract class Base{

  abstract void dontUseThis();

  abstract void doUseThis();

}

and you have a child class, which doesn't need the dontUseThis method, you have two options:

public class Kid1 extends Base{
  public void dontUseThis(){} // it is "implemented" just doesn't do anything

  public void doUseThis(){
    // business logic here
  }

}

A more used solution would be:

public class Kid2 extends Base{
  public void dontUseThis(){
        throw new UnsupportedOperationException("We don't support this functionality");
    } 

  public void doUseThis(){
    // business logic here
  }

}

this way, not only don't you have the functionality, but it is pointed out to those who try to call this method.

indeed, abstract methods and interfaces are 'slightly' the same. it's the differences that you should look at to choose which one to use.
Do you need to provide a common implementation for all child classes ? abstract class. Do you not, but you do need to be able to extend other classes in your subclasses ? interface. (for instance)

[gahhon]

So however, the subclasses are still neccessary to define the abstract methods but it doesn't have any exeuction code?

So if like that, can i say if methods are commonly used by many classes, apply interface or only some class, apply abstract?

[JamesCherrill]

If this seems a bit vague and ambiguous, then that's because it is. The technical differences between abstract and interface have been blurred even more in Java 8.
The best way to think about it is to look at the intent behind it.
If you want to define a contract that some classes can meet, then look at defining an interface. If there are multiple overlapping contracts then definitely use interfaces. eg Runnable, ActionListener, Serializable.
If you want to create a master template that other classes can use as a common standard base then define a abstract class. Eg Vehicle, RectangularShape