标签:java interface abstract-class
解释/序言
在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是供图书馆开发人员“同意”的东西,但是提供默认的“额外奖励” (覆盖)行为?
>与ACWAM同时使用接口是否有意义?
你能提供一个或两个简单的例子(指向另一个文件会很好)来说明这两个人的意图(或“好用”)的差异,即接口和ACWAM?
解决方法:
接口和抽象类之间的最大区别是:
>抽象类强制实现“是一种”关系.您必须子类化抽象类.您永远被绑定到特定的类层次结构中
>接口强制实现“看起来像”关系.只要它遵循接口,您就可以将任何您喜欢的子类化.这使您可以在任何您喜欢的课程中进行交换.如果出现更好的一个,这尤其有用
一个好的规则就是API应该始终引用接口.
请注意,JDK中充斥着早期在使用接口应该使用的(抽象)类的错误. Stack就是一个很好的例子:Stack应该是一个接口,但它是一个类.如果你想实现自己的堆栈,你必须继承java.util.Stack,这是非常规范的 – 你可能不想这样做 – 也许你需要一个超轻量级版本等.
然而,抽象类确实有它们的位置:它们可以提供接口的默认实现.一个很好的例子是java.util.AbstractMap,这是一个java.util.Map接口的骨架实现.
标签:java,interface,abstract-class 来源: https://codeday.me/bug/20190730/1577005.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。