java抽象類(lèi)與接口的區(qū)別

　　java中的抽象類(lèi)和接口有什么區(qū)別?我們不妨來(lái)看一下。下面是學(xué)習(xí)啦小編為大家準(zhǔn)備的java抽象類(lèi)與接口的區(qū)別，希望大家喜歡!

　　java抽象類(lèi)與接口的區(qū)別

　　java抽象類(lèi)與接口的概述

　　一個(gè)軟件設(shè)計(jì)的好壞，我想很大程度上取決于它的整體架構(gòu)，而這個(gè)整體架構(gòu)其實(shí)就是你對(duì)整個(gè)宏觀商業(yè)業(yè)務(wù)的抽象框架，當(dāng)代表業(yè)務(wù)邏輯的高層抽象層結(jié)構(gòu) 合理時(shí)，你底層的具體實(shí)現(xiàn)需要考慮的就僅僅是一些算法和一些具體的業(yè)務(wù)實(shí)現(xiàn)了。當(dāng)你需要再開(kāi)發(fā)另一個(gè)相近的項(xiàng)目時(shí)，你以前的抽象層說(shuō)不定還可以再次利用 。面對(duì)對(duì)象的設(shè)計(jì)，復(fù)用的重點(diǎn)其實(shí)應(yīng)該是抽象層的復(fù)用，而不是具體某一個(gè)代碼塊的復(fù)用。

　　說(shuō)到了抽象，我就不能不提到曾讓我頭痛的Java接口和Java抽象類(lèi)了，這也是本文我想說(shuō)的重點(diǎn)。

　　既然面向?qū)ο笤O(shè)計(jì)的重點(diǎn)在于抽象，那Java接口和Java抽象類(lèi)就有它存在的必然性了。

　　Java接口(interface)和Java抽象類(lèi)(abstract class)代表的就是抽象類(lèi)型，就是我們需要提出的抽象層的具體表現(xiàn)。OOP面向?qū)ο蟮木幊?，如果要提高程序的?fù)用率，增加程序 的可維護(hù)性，可擴(kuò)展性，就必須是面向接口的編程，面向抽象的編程，正確地使用接口、抽象類(lèi)這些有用的抽象類(lèi)型作為你結(jié)構(gòu)層次上的頂層。

　　Java接口和Java抽象類(lèi)有太多相似的地方，又有太多特別的地方，究竟在什么地方，才是它們的最佳位置呢?把它們比較一下，你就可以發(fā)現(xiàn)了。

　　Java接口和Java抽象類(lèi)最大的一個(gè)區(qū)別，就在于Java抽象類(lèi)可以提供某些方法的部分實(shí)現(xiàn)，而Java接口不可以(就是interface中只能定義方法，而不能有方法的實(shí)現(xiàn)，而在abstract class中則可以既有方法的具體實(shí)現(xiàn)，又有沒(méi)有具體實(shí)現(xiàn)的抽象方法)，這大概就是Java抽象類(lèi)唯一的優(yōu)點(diǎn)吧，但這個(gè)優(yōu)點(diǎn)非常有用。如果向一個(gè)抽象類(lèi)里加入一個(gè)新的具體方法時(shí)，那么它所有的子類(lèi)都一下子都得到了這個(gè)新方法，而Java接口做不到這一點(diǎn)，如果向一個(gè)Java接口里加入一個(gè) 新方法，所有實(shí)現(xiàn)這個(gè)接口的類(lèi)就無(wú)法成功通過(guò)編譯了，因?yàn)槟惚仨氉屆恳粋€(gè)類(lèi)都再實(shí)現(xiàn)這個(gè)方法才行，這顯然是Java接口的缺點(diǎn)。這個(gè)在我的另外一篇博客mapreduce 新舊API 區(qū)別中有提到類(lèi)似的問(wèn)題，在新的mapreduce api中更傾向于使用抽象類(lèi)，而不是接口，因?yàn)檫@更容易擴(kuò)展。原因就是上面劃線部分所說(shuō)的。

　　一個(gè)抽象類(lèi)的實(shí)現(xiàn)只能由這個(gè)抽象類(lèi)的子類(lèi)給出，也就是說(shuō)，這個(gè)實(shí)現(xiàn)處在抽象類(lèi)所定義出的繼承的等級(jí)結(jié)構(gòu)中，而由于Java語(yǔ)言的單繼承性，所以抽象類(lèi)作為類(lèi)型定義工具的效能大打折扣。在這一點(diǎn)上，Java接口的優(yōu)勢(shì)就出來(lái)了，任何一個(gè)實(shí)現(xiàn)了一個(gè)Java接口所規(guī)定的方法的類(lèi)都可以具有這個(gè)接口的類(lèi)型，而一個(gè)類(lèi)可以實(shí)現(xiàn)任意多個(gè)Java接口，從而這個(gè)類(lèi)就有了多種類(lèi)型。(使用抽象類(lèi)，那么繼承這個(gè)抽象類(lèi)的子類(lèi)類(lèi)型就比較單一，因?yàn)樽宇?lèi)只能單繼承抽象類(lèi);而子類(lèi)能夠同時(shí)實(shí)現(xiàn)多個(gè)接口，因?yàn)轭?lèi)型就比較多。接口和抽象類(lèi)都可以定義對(duì)象，但是只能用他們的具體實(shí)現(xiàn)類(lèi)來(lái)進(jìn)行實(shí)例化。)

　　從第2點(diǎn)不難看出，Java接口是定義混合類(lèi)型的理想工具，混合類(lèi)表明一個(gè)類(lèi)不僅僅具有某個(gè)主類(lèi)型的行為，而且具有其他的次要行為。

　　結(jié)合1、2點(diǎn)中抽象類(lèi)和Java接口的各自?xún)?yōu)勢(shì)，具精典的設(shè)計(jì)模式就出來(lái)了：聲明類(lèi)型的工作仍然由Java接口承擔(dān)，但是同時(shí)給出一個(gè)Java 抽象類(lèi)，且實(shí)現(xiàn)了這個(gè)接口，而其他同屬于這個(gè)抽象類(lèi)型的具體類(lèi)可以選擇實(shí)現(xiàn)這個(gè)Java接口，也可以選擇繼承這個(gè)抽象類(lèi)，也就是說(shuō)在層次結(jié)構(gòu)中，Java 接口在最上面，然后緊跟著抽象類(lèi)，這下兩個(gè)的最大優(yōu)點(diǎn)都能發(fā)揮到極至了。這個(gè)模式就是“缺省適配模式”。在Java語(yǔ)言API中用了這種模式，而且全都遵循一定的命名規(guī)范：Abstract +接口名。(A extends AbstractB implements interfaceC，那么A即可以選擇實(shí)現(xiàn)(@Override)接口interfaceC中的方法，也可以選擇不實(shí)現(xiàn);A即可以選擇實(shí)現(xiàn)(@Override)抽象類(lèi)AbstractB中的方法，也可以選擇不實(shí)現(xiàn))

　　Java接口和Java抽象類(lèi)的存在就是為了用于具體類(lèi)的實(shí)現(xiàn)和繼承的，如果你準(zhǔn)備寫(xiě)一個(gè)具體類(lèi)去繼承另一個(gè)具體類(lèi)的話，那你的設(shè)計(jì)就有很大問(wèn)題了。Java抽象類(lèi)就是為了繼承而存在的，它的抽象方法就是為了強(qiáng)制子類(lèi)必須去實(shí)現(xiàn)的。

　　使用Java接口和抽象Java類(lèi)進(jìn)行變量的類(lèi)型聲明、參數(shù)是類(lèi)型聲明、方法的返還類(lèi)型說(shuō)明，以及數(shù)據(jù)類(lèi)型的轉(zhuǎn)換等。而不要用具體Java類(lèi)進(jìn)行變量的類(lèi)型聲明、參數(shù)是類(lèi)型聲明、方法的返還類(lèi)型說(shuō)明，以及數(shù)據(jù)類(lèi)型的轉(zhuǎn)換等。

　　java抽象類(lèi)與接口的實(shí)例

　　下面給出一個(gè)具體的接口Action，代碼如下所示：

　　[java] view plain copypackage org.springframework.webflow.execution;

　　public interface Action {

　　public Event execute(RequestContext context) throws Exception;

　　}

　　在這個(gè)接口中，定義了一個(gè)沒(méi)有具體實(shí)現(xiàn)的方法，方法名叫做execute()，返回類(lèi)型是Event。如前面第一條所述，接口中的方法都是沒(méi)有實(shí)現(xiàn)的。這些方法的具體實(shí)現(xiàn)是在實(shí)現(xiàn)(implements)這個(gè)接口的類(lèi)中給出的。

　　再來(lái)看一個(gè)實(shí)現(xiàn)Action接口的抽象類(lèi)AbstractAction，代碼如下。

　　[java] view plain copypackage 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 {

　　}

　　}

　　在抽象類(lèi)AbstractAction中，既有具體實(shí)現(xiàn)的方法，又有沒(méi)有具體實(shí)現(xiàn)的抽象方法

　　[java] view plain copy//抽象方法

　　protected abstract Event doExecute(RequestContext context) throws Exception;

　　需要注意的是在抽象類(lèi)中，如果方法沒(méi)有具體實(shí)現(xiàn)(就是方法后面沒(méi)有{})，那么必須加上abstract來(lái)聲明這個(gè)方法，而接口中不需要使用abstract來(lái)聲明(抽象類(lèi)之所以被稱(chēng)為抽象類(lèi)，就是因?yàn)樗谐橄蠓椒?。含有抽象方法的?lèi)叫做抽象類(lèi))。