Java methods: @Override vs abstract

Question

What are the advantages/disadvantages of using one of the following styles over the other for declaring a method from an abstract parent class:

OPTION 1:

Parent Class:

protected Object retrieve(String id, Object model){
        return null;
}

Child Class:

@Override
public String retrieve(Object model) {
    if (model instanceof Car)
        // ... somehow get id ...
        return getInfo(id, (Car)model);
    return null;
}

or...

OPTION 2:

Parent Class:

protected abstract Object retrieve(String id, Object model);

Child Class:

public String retrieve(String id, Object model) {
    if (model instanceof Car)
        return getInfo(id, (Car)model);
    return null;
}

Answer 1

With an abstract class, it is guaranteed that the child will override the abstract method(s), if any (or itself be abstract). They can also not be instantiated, which is important because they have missing functionality (the abstract method).

See also http://wiki.answers.com/Q/Use_of_abstract_class_in_java:

An Abstract class is similar to an interface. You cannot instantiate them, but you can extend them. Any class that extends the abstract class has to provide the implementation to the abstract methods. Hence these classes can be used as a skeleton to similar classes where some common functionality may be required. Such functionality can also be embedded into these classes. Unlike interfaces, abstract classes can have method code also. So they are very useful.

This may also be helpful: https://softwareengineering.stackexchange.com/questions/96947/why-should-i-declare-a-class-as-an-abstract-class

Answer 2

In my opinion, the first style is only needed if all of the subclasses wont be implementing this function (thought that might be better expressed with interfaces). If it is a necessary function, it is clearer to say abstract, and less error prone, since the compiler will nag you to implement it.

Answer 3

You are mixing apples and oranges here, and probably a little more:

• @Override is a compile-time (@Retention(value=SOURCE)), method-level (@Target(value=METHOD)) annotation, used by the compiler to check that the given method either:
  • implements a method from an interface (note: JDK 1.6+), or
  • implements an abstract method from an abstract class, or
  • overrides a non-final method from a parent class (whether that parent class is abstract or not);
• abstract is a language keyword which can be declared at class level or method level:
  • if at class level, this means this class cannot be directly instantiated, and therefore you must subclass it (such an abstract class can, however, bear static factory methods returning subclasses of itself);
  • if at method level, the method only has a prototype (see below) and subclasses must implement this method;

Note that it is illegal to declare a method as being abstract if the class itself is not abstract.

Also note that this is possible:

public abstract class MustHaveToString
{
    // .toString() is implemented in Object, here we FORCE children of that class
    // to re-implement it. As the method is abstract, we only declare its 
    // prototype (its return type and method arguments, in this case, none).
    // As the method originates from one of our parents (Object), 
    // we can also @Override it!
    @Override
    public abstract String toString();
}

Answer 4

First of all, your option '1' is an example of method overloading. Secondly, assuming that you meant method overriding, in option '1' you can always call 'super.method' from overridden method. This is technically not allowed in option '2'. So there are no 'advantages' or disadvantages' of these two techniques.

A more closer approach to your 'option 2' (without declaring 'abstract') is as follows:

public abstract class Parent {
  protected Object retrieve(String id, Object model) {
    throw new UnsupportedOperationException(...);
  }
}