原文:http://blog.csdn.net/sunboard/article/details/3831823
1.概述
一个软件设计的好坏,我想很大程度上取决于它的整体架构,而这个整体架构其实就是你对整个宏观商业业务的抽象框架,当代表业务逻辑的高层抽象层结构 合理时,你底层的具体实现需要考虑的就仅仅是一些算法和一些具体的业务实现了。当你需要再开发另一个相近的项目时,你以前的抽象层说不定还可以再次利用 。面对对象的设计,复用的重点其实应该是抽象层的复用,而不是具体某一个代码块的复用。
说到了抽象,我就不能不提到曾让我头痛的Java接口和Java抽象类了,这也是本文我想说的重点。
既然面向对象设计的重点在于抽象,那Java接口和Java抽象类就有它存在的必然性了。
Java接口(interface)和Java抽象类(abstract class)代表的就是抽象类型,就是我们需要提出的抽象层的具体表现。OOP面向对象的编程,如果要提高程序的复用率,增加程序 的可维护性,可扩展性,就必须是面向接口的编程,面向抽象的编程,正确地使用接口、抽象类这些有用的抽象类型作为你结构层次上的顶层。
含有abstract修饰符的class 即为抽象类,并不是说抽象类必须有抽象方法(可以一个也没有,目的是不让该类创建对象,注:接口和抽象类都不能创建对象,但是均可定义对象,通过实现子类实例化父类),但是含有abstract方法的类必须定义为abstract class ,abstract类不能创建实例(对象),抽象类中定义抽象方法必须放在具体子类中实现,所以呀,不能有抽象的构造方法或抽象的静态方法,如果子类没有实现抽象父类中的所有方法,那么,子类也必须定义为抽象类。
接口(interface)可以说成是抽象类的特例。接口中的所有方法都必须是抽象的,接口中的方法定义默认为public abstract 。接口中的变量是全局常量,即public static final修饰的。
看一下他们在语法上的区别吧!
1,抽象类里可以有构造方法,而接口内不能有构造方法。(构造器用于初始化成员变量,接口没有成员变量)
2,抽象类中可以有普通成员变量,而接口中不能有普通成员变量。
3,抽象类中可以包含非抽象的普通方法,而接口中所有的方法必须是抽象的,不能有非抽象的普通方法。
4,抽象类中的抽象方法的访问类型可以是public ,protected和默认类型,但接口中的抽象方法只能是public类型的,并且默认即为public abstract类型。
5,抽象类中可以包含静态方法,接口内不能包含静态方法。
6,抽象类和接口中都可以包含静态成员变量(接口中不能有普通成员变量,也不能具有非抽象函数),抽象类中的静态成员变量的访问类型可以任意,但接口中定义的变量只能是public static类型,并且默认为public static类型。
7,一个类可以实现多个接口,但只能继承一个抽象类。
再补充点两者在应用上的区别:
接口更多的是在系统框架设计方法发挥作用,主要定义模块之间的通信,而抽象类在代码实现方面发挥作用,可以实现代码的重用
抽象子abstract不可以与那些关键字共存:
final修饰最终类,没有子类。而抽象类必须要有子类继承。
private是私有的,子类的函数要实现对父类成员函数的全面覆盖,古抽象类中不能有私有成员。
static修饰的函数可以用类名调用,但是调用抽象函数没有意义。
Java接口和Java抽象类有太多相似的地方,又有太多特别的地方,究竟在什么地方,才是它们的最佳位置呢?把它们比较一下,你就可以发现了。
- Java接口和Java抽象类最大的一个区别,就在于Java抽象类可以提供某些方法的部分实现,而Java接口不可以(就是interface中只能定义抽象方法,而不能有方法的实现,而在abstract class中则可以既有方法的具体实现,又有没有具体实现的抽象方法),这大概就是Java抽象类唯一的优点吧,但这个优点非常有用。如果向一个抽象类里加入一个新的具体方法时,那么它所有的子类都一下子都得到了这个新方法,而Java接口做不到这一点,如果向一个Java接口里加入一个 新方法,所有实现这个接口的类就无法成功通过编译了,因为你必须让每一个类都再实现这个方法才行,这显然是Java接口的缺点。这个在我的另外一篇博客mapreduce 新旧API 区别中有提到类似的问题,在新的mapreduce api中更倾向于使用抽象类,而不是接口,因为这更容易扩展。原因就是上面划线部分所说的。
- 一个抽象类的实现只能由这个抽象类的子类给出,也就是说,这个实现处在抽象类所定义出的继承的等级结构中,而由于Java语言的单继承性,所以抽象类作为类型定义工具的效能大打折扣。在这一点上,Java接口的优势就出来了,任何一个实现了一个Java接口所规定的方法的类都可以具有这个接口的类型,而一个类可以实现任意多个Java接口,从而这个类就有了多种类型。(使用抽象类,那么继承这个抽象类的子类类型就比较单一,因为子类只能单继承抽象类;而子类能够同时实现多个接口,因为类型就比较多。接口和抽象类都可以定义对象,但是只能用他们的具体实现类来进行实例化。)
- 从第2点不难看出,Java接口是定义混合类型的理想工具,混合类表明一个类不仅仅具有某个主类型的行为,而且具有其他的次要行为。
- 结合1、2点中抽象类和Java接口的各自优势,具精典的设计模式就出来了:声明类型的工作仍然由Java接口承担,但是同时给出一个Java 抽象类,且实现了这个接口,而其他同属于这个抽象类型的具体类可以选择实现这个Java接口,也可以选择继承这个抽象类,也就是说在层次结构中,Java 接口在最上面,然后紧跟着抽象类,这下两个的最大优点都能发挥到极至了。这个模式就是“缺省适配模式”。在Java语言API中用了这种模式,而且全都遵循一定的命名规范:Abstract +接口名。(A extends AbstractB implements interfaceC,那么A即可以选择实现(@Override)接口interfaceC中的方法,也可以选择不实现;A即可以选择实现(@Override)抽象类AbstractB中的方法,也可以选择不实现)
Java接口和Java抽象类的存在就是为了用于具体类的实现和继承的,如果你准备写一个具体类去继承另一个具体类的话,那你的设计就有很大问题了。Java抽象类就是为了继承而存在的,它的抽象方法就是为了强制子类必须去实现的。
使用Java接口和抽象Java类进行变量的类型声明、参数是类型声明、方法的返还类型说明,以及数据类型的转换等。而不要用具体Java类进行变量的类型声明、参数是类型声明、方法的返还类型说明,以及数据类型的转换等。
2.实例
下面给出一个具体的接口Action,代码如下所示:
- package org.springframework.webflow.execution;
- public interface Action {
- public Event execute(RequestContext context) throws Exception;
- }
再来看一个实现Action接口的抽象类AbstractAction,代码如下。
- package org.springframework.webflow.action;
- import org.apache.commons.logging.Log;
- import org.apache.commons.logging.LogFactory;
- import org.springframework.beans.factory.BeanInitializationException;
- import org.springframework.beans.factory.InitializingBean;
- import org.springframework.util.ClassUtils;
- import org.springframework.webflow.core.collection.AttributeMap;
- import org.springframework.webflow.execution.Action;
- import org.springframework.webflow.execution.Event;
- import org.springframework.webflow.execution.RequestContext;
- public abstract class AbstractAction implements Action, InitializingBean {
- protected final Log logger = LogFactory.getLog(getClass());
- public EventFactorySupport getEventFactorySupport() {
- return new EventFactorySupport();
- }
- public void afterPropertiesSet() throws Exception {
- try {
- initAction();
- } catch (Exception ex) {
- throw new BeanInitializationException("Initialization of this Action failed: " + ex.getMessage(), ex);
- }
- }
- protected void initAction() throws Exception {
- }
- protected Event success() {
- return getEventFactorySupport().success(this);
- }
- protected Event success(Object result) {
- return getEventFactorySupport().success(this, result);
- }
- protected Event error() {
- return getEventFactorySupport().error(this);
- }
- protected Event error(Exception e) {
- return getEventFactorySupport().error(this, e);
- }
- protected Event yes() {
- return getEventFactorySupport().yes(this);
- }
- protected Event no() {
- return getEventFactorySupport().no(this);
- }
- protected Event result(boolean booleanResult) {
- return getEventFactorySupport().event(this, booleanResult);
- }
- protected Event result(String eventId) {
- return getEventFactorySupport().event(this, eventId);
- }
- protected Event result(String eventId, AttributeMap resultAttributes) {
- return getEventFactorySupport().event(this, eventId, resultAttributes);
- }
- protected Event result(String eventId, String resultAttributeName, Object resultAttributeValue) {
- return getEventFactorySupport().event(this, eventId, resultAttributeName, resultAttributeValue);
- }
- public final Event execute(RequestContext context) throws Exception {
- Event result = doPreExecute(context);
- if (result == null) {
- result = doExecute(context);
- doPostExecute(context);
- } else {
- if (logger.isInfoEnabled()) {
- logger.info("Action execution disallowed; pre-execution result is '" + result.getId() + "'");
- }
- }
- return result;
- }
- protected String getActionNameForLogging() {
- return ClassUtils.getShortName(getClass());
- }
- protected Event doPreExecute(RequestContext context) throws Exception {
- return null;
- }
- //抽象方法
- protected abstract Event doExecute(RequestContext context) throws Exception;
- protected void doPostExecute(RequestContext context) throws Exception {
- }
- }
- //抽象方法
- protected abstract Event doExecute(RequestContext context) throws Exception;