Java 介面和抽象類別區別

標籤：

原文：http://blog.csdn.net/sunboard/article/details/3831823

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，代碼如下所示：

 

[java] view plaincopy 

1. package org.springframework.webflow.execution;  
2. public interface Action {  
3.     public Event execute(RequestContext context) throws Exception;  
4. }  

在這個介面中，定義了一個沒有具體實現的方法，方法名叫做execute()，傳回型別是Event。如前面第一條所述，介面中的方法都是沒有實現的。這些方法的具體實現是在實現(implements)這個介面的類中給出的。

再來看一個實現Action介面的抽象類別AbstractAction，代碼如下。

 

[java] view plaincopy 

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中，既有具體實現的方法，又有沒有具體實現的抽象方法

 

 

[java] view plaincopy 

1. //抽象方法  
2. protected abstract Event doExecute(RequestContext context) throws Exception;  

需要注意的是在抽象類別中，如果方法沒有具體實現（就是方法後面沒有{}），那麼必須加上abstract來聲明這個方法，而介面中不需要使用abstract來聲明（抽象類別之所以被稱為抽象類別，就是因為它包含有抽象方法。含有抽象方法的類叫做抽象類別）。

------------------------------------------------------------------------------------------------------------------------------------------------

含有abstract修飾符的class 即為抽象類別，abstract類不能建立執行個體對象，含有abstract的方法的類必須定義為abstract class ，abstract class 裡的方法不必是抽象的，抽象來中定義抽象方法必須放在具體子類中實現，所以呀，不能有抽象的構造方法或抽象的靜態方法，如果子類沒有實現抽象父類中的所有方法，那麼，子類也必須定義為抽象類別。

     介面（interface）可以說成是抽象類別的特例。介面中的所有方法都必須是抽象的，介面中的方法定義預設為public  abstract 。介面中的變數是全域常量，即public static final修飾的。

     看一下他們在文法上的區別吧！

   1，抽象類別裡可以有構造方法，而介面內不能有構造方法。

   2，抽象類別中可以有普通成員變數，而介面中不能有普通成員變數。

   3，抽象類別中可以包含非抽象的普通方法，而介面中所有的方法必須是抽象的，不能有非抽象的普通方法。

   4，抽象類別中的抽象方法的訪問類型可以是public ，protected和預設類型，但介面中的抽象方法只能是public類型的，並且預設即為public abstract類型。

   5，抽象類別中可以包含靜態方法，介面內不能包含靜態方法。

   6，抽象類別和介面中都可以包含靜態成員變數，抽象類別中的靜態成員變數的訪問類型可以任意，但介面中定義的變數只能是public  static類型，並且預設為public static類型。

   7，一個類可以實現多個介面，但只能繼承一個抽象類別。

再補充點兩者在應用上的區別：

   介面更多的是在系統架構設計方法發揮作用，主要定義模組之間的通訊，而抽象類別在代碼實現方面發揮作用，可以實現代碼的重用

Java 介面和抽象類別區別