How does the intent of an interface differ from an abstract class with abstract methods?

Question

Explanation/preamble

In Java, if you declare an abstract class with abstract methods, e.g.

public abstract class MyAbstractClass {
  private String m_id;
  
  // default behavior
  public MyAbstractClass() { setId(null); }
  public String getId() { return m_id; }
  public void setId(String id) { m_id = id; }
  
  // overridenable method
  public void doSomething() { /* does nothing by default */ }
  
  // to-be-defined behavior
  public abstract void setSomething(Object o);
  public abstract Object getSomething();
}

you can effectively declare a class which has a "default behavior" of sorts (the getters and setters for m_id) as well as forcing that this class is instantiated by a subclass which has to implement the "missing" (abstract) methods, e.g.

public class MyClass extends MyAbstractClass {
  private Object m_o;
  
  // implements some actual complex behavior
  public void setSomething(Object o) { m_o = o; }
  public Object getSomething() { return m_o; }
}

possibly even overriding methods in the superclass.

So it seems that an abstract class with abstract methods behaves as if it were an interface,

public interface IMy {
  public void setSomething(Object o);
  public Object getSomething();
}

because to use it, it will have to eventually point to an actual object.

The questions

It almost appears as if it makes no sense in existing both interface and abstract class-with-abstract-methods (ACWAM), since they seem very similar.

1. The ACWAM seems so incredibly similar to an interface! I suppose that the essential difference is in their intent.
2. I understand that the interface intends to provide a means with which a library user can "talk" to the library without depending on the implementation of the library. Is it a correct interpretation that an interface is intended to "show something to the public" whereas an ACWAM is something that is intended for the library developer(s) to "agree on", but with the "added bonus" of providing a default (overridenable) behavior?
3. Would it make sense to use an interface at the same time as an ACWAM?

Can you provide one or two simple examples (pointing to another document would be fine) to illustrate the difference in intent (or "good use") for those two, namely interface and the ACWAM?

Answer 1

The big difference between an interface and an abstract class is:

• an abstract class imposes a "is a" relationship to the implementation. You must subclass the abstract class. You are forever tied into a particular class hierarchy
• an interface imposes a "looks like a" relationship to the implementation. You can subclass anything you like as long as it obeys the interface. This frees you up to swap in any class you like to do the job. This is especially useful if a better one comes along

A good rule to work by is that APIs should always refer to interfaces.

Note that the JDK is littered with mistakes made early on where (abstract) classes were used where interfaces should have been used. Stack is a good example: Stack should have been an interface, but it's a class. If you want to implement your own Stack, you must subclass java.util.Stack, which is very prescriptive - you may not want to do that - perhaps you need a super lightweight version etc.

Abstract classes do have their place however: They can provide default implementations of interfaces. A good example is java.util.AbstractMap, a class which is a skeletal implementation of the java.util.Map interface.

Answer 2

Java does not support multiple inheritance. Therefore, a class can implement many interfaces, but it cannot inherit from multiple base classes.