java – 接口的意图与抽象方法的抽象类有何不同？

在Java中,如果使用抽象方法声明抽象类,例如

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();
}

你可以有效地声明一个具有各种“默认行为”的类(m_id的getter和setter),以及强制该类由必须实现“缺失”(抽象)方法的子类实例化,例如：

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; }
}

甚至可能覆盖超类中的方法.

所以看起来抽象方法的抽象类就像是一个接口,

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

因为要使用它,它必须最终指向一个实际的对象.

问题

它几乎看起来好像在现有的接口和抽象类与抽象方法(ACWAM)中没有任何意义,因为它们看起来非常相似.

> ACWAM看起来非常类似于界面！我认为根本区别在于他们的意图.
>我理解该接口旨在提供一种方法,库用户可以与库“交谈”,而不依赖于库的实现.是否正确解释接口旨在“向公众展示某些东西”,而ACWAM是供图书馆开发人员“同意”的东西,但是提供默认的“额外奖励” (覆盖)行为？
>与ACW??AM同时使用接口是否有意义？

你能提供一个或两个简单的例子(指向另一个文件会很好)来说明这两个人的意图(或“好用”)的差异,即接口和ACWAM？