qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

Java 接口和抽象类区别

1.概述

一个软件设计的好坏，我想很大程度上取决于它的整体架构，而这个整体架构其实就是你对整个宏观商业业务的抽象框架，当代表业务逻辑的高层抽象层结构 合理时，你底层的具体实现需要考虑的就仅仅是一些算法和一些具体的业务实现了。当你需要再开发另一个相近的项目时，你以前的抽象层说不定还可以再次利用 。面对对象的设计，复用的重点其实应该是抽象层的复用，而不是具体某一个代码块的复用。

说到了抽象，我就不能不提到曾让我头痛的Java接口和Java抽象类了，这也是本文我想说的重点。

既然面向对象设计的重点在于抽象，那Java接口和Java抽象类就有它存在的必然性了。

Java接口(interface)和Java抽象类(abstract class)代表的就是抽象类型，就是我们需要提出的抽象层的具体表现。OOP面向对象的编程，如果要提高程序的复用率，增加程序 的可维护性，可扩展性，就必须是面向接口的编程，面向抽象的编程，正确地使用接口、抽象类这些有用的抽象类型作为你结构层次上的顶层。

Java接口和Java抽象类有太多相似的地方，又有太多特别的地方，究竟在什么地方，才是它们的最佳位置呢？把它们比较一下，你就可以发现了。

  1. Java接口和Java抽象类最大的一个区别，就在于Java抽象类可以提供某些方法的部分实现，而Java接口不可以（就是interface中只能定义方法，而不能有方法的实现，而在abstract class中则可以既有方法的具体实现，又有没有具体实现的抽象方法），这大概就是Java抽象类唯一的优点吧，但这个优点非常有用。如果向一个抽象类里加入一个新的具体方法时，那么它所有的子类都一下子都得到了这个新方法，而Java接口做不到这一点，如果向一个Java接口里加入一个 新方法，所有实现这个接口的类就无法成功通过编译了，因为你必须让每一个类都再实现这个方法才行，这显然是Java接口的缺点。这个在我的另外一篇博客mapreduce 新旧API 区别中有提到类似的问题，在新的mapreduce api中更倾向于使用抽象类，而不是接口，因为这更容易扩展。原因就是上面划线部分所说的。
  2. 一个抽象类的实现只能由这个抽象类的子类给出，也就是说，这个实现处在抽象类所定义出的继承的等级结构中，而由于Java语言的单继承性，所以抽象类作为类型定义工具的效能大打折扣。在这一点上，Java接口的优势就出来了，任何一个实现了一个Java接口所规定的方法的类都可以具有这个接口的类型，而一个类可以实现任意多个Java接口，从而这个类就有了多种类型。（使用抽象类，那么继承这个抽象类的子类类型就比较单一，因为子类只能单继承抽象类；而子类能够同时实现多个接口，因为类型就比较多。接口和抽象类都可以定义对象，但是只能用他们的具体实现类来进行实例化。）
  3. 从第2点不难看出，Java接口是定义混合类型的理想工具，混合类表明一个类不仅仅具有某个主类型的行为，而且具有其他的次要行为。
  4. 结合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，代码如下所示：

  1. package org.springframework.webflow.execution;  
  2. public interface Action {  
  3.     public Event execute(RequestContext context) throws Exception;  
  4. }  
在这个接口中，定义了一个没有具体实现的方法，方法名叫做execute()，返回类型是Event。如前面第一条所述，接口中的方法都是没有实现的。这些方法的具体实现是在实现(implements)这个接口的类中给出的。

再来看一个实现Action接口的抽象类AbstractAction，代码如下。

  1. package org.springframework.webflow.action;  
  2.   
  3. import org.apache.commons.logging.Log;  
  4. import org.apache.commons.logging.LogFactory;  
  5. import org.springframework.beans.factory.BeanInitializationException;  
  6. import org.springframework.beans.factory.InitializingBean;  
  7. import org.springframework.util.ClassUtils;  
  8. import org.springframework.webflow.core.collection.AttributeMap;  
  9. import org.springframework.webflow.execution.Action;  
  10. import org.springframework.webflow.execution.Event;  
  11. import org.springframework.webflow.execution.RequestContext;  
  12.   
  13. public abstract class AbstractAction implements Action, InitializingBean {  
  14.   
  15.     protected final Log logger = LogFactory.getLog(getClass());  
  16.   
  17.     public EventFactorySupport getEventFactorySupport() {  
  18.         return new EventFactorySupport();  
  19.     }  
  20.   
  21.     public void afterPropertiesSet() throws Exception {  
  22.         try {  
  23.             initAction();  
  24.         } catch (Exception ex) {  
  25.             throw new BeanInitializationException("Initialization of this Action failed: " + ex.getMessage(), ex);  
  26.         }  
  27.     }  
  28.   
  29.     protected void initAction() throws Exception {  
  30.     }  
  31.   
  32.     protected Event success() {  
  33.         return getEventFactorySupport().success(this);  
  34.     }  
  35.   
  36.     protected Event success(Object result) {  
  37.         return getEventFactorySupport().success(this, result);  
  38.     }  
  39.   
  40.     protected Event error() {  
  41.         return getEventFactorySupport().error(this);  
  42.     }  
  43.   
  44.     protected Event error(Exception e) {  
  45.         return getEventFactorySupport().error(this, e);  
  46.     }  
  47.   
  48.     protected Event yes() {  
  49.         return getEventFactorySupport().yes(this);  
  50.     }  
  51.   
  52.     protected Event no() {  
  53.         return getEventFactorySupport().no(this);  
  54.     }  
  55.   
  56.     protected Event result(boolean booleanResult) {  
  57.         return getEventFactorySupport().event(this, booleanResult);  
  58.     }  
  59.   
  60.     protected Event result(String eventId) {  
  61.         return getEventFactorySupport().event(this, eventId);  
  62.     }  
  63.   
  64.     protected Event result(String eventId, AttributeMap resultAttributes) {  
  65.         return getEventFactorySupport().event(this, eventId, resultAttributes);  
  66.     }  
  67.   
  68.     protected Event result(String eventId, String resultAttributeName, Object resultAttributeValue) {  
  69.         return getEventFactorySupport().event(this, eventId, resultAttributeName, resultAttributeValue);  
  70.     }  
  71.   
  72.     public final Event execute(RequestContext context) throws Exception {  
  73.         Event result = doPreExecute(context);  
  74.         if (result == null) {  
  75.             result = doExecute(context);  
  76.             doPostExecute(context);  
  77.         } else {  
  78.             if (logger.isInfoEnabled()) {  
  79.                 logger.info("Action execution disallowed; pre-execution result is '" + result.getId() + "'");  
  80.             }  
  81.         }  
  82.         return result;  
  83.     }  
  84.   
  85.     protected String getActionNameForLogging() {  
  86.         return ClassUtils.getShortName(getClass());  
  87.     }  
  88.   
  89.     protected Event doPreExecute(RequestContext context) throws Exception {  
  90.         return null;  
  91.     }  
  92.   
  93.     //抽象方法  
  94.     protected abstract Event doExecute(RequestContext context) throws Exception;  
  95.   
  96.     protected void doPostExecute(RequestContext context) throws Exception {  
  97.     }  
  98. }  
在抽象类AbstractAction中，既有具体实现的方法，又有没有具体实现的抽象方法

  1. //抽象方法  
  2. protected abstract Event doExecute(RequestContext context) throws Exception;  
需要注意的是在抽象类中，如果方法没有具体实现（就是方法后面没有{}），那么必须加上abstract来声明这个方法，而接口中不需要使用abstract来声明（抽象类之所以被称为抽象类，就是因为它包含有抽象方法。含有抽象方法的类叫做抽象类）。

posted on 2014-08-12 09:48 顺其自然EVO 阅读(232) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。
网站导航:
 
<2014年8月>
日一二三四五六
272829303112
3456789
10111213141516
17181920212223
24252627282930
31123456

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜