抽象類和普通類有哪些區(qū)別?(具體點(diǎn))
抽象類和普通類有哪些區(qū)別?(具體點(diǎn))
1&g
大家，抽象類倒底和普通的超類有何區(qū)別
聲明方法的存在而不去實(shí)現(xiàn)它的類被叫做抽象類（abstract class），它用于要創(chuàng)建一個(gè)體現(xiàn)某些基本行為的類，并為該類聲明方法，但不能在該類中實(shí)現(xiàn)該類的情況。不能創(chuàng)建abstract 類的實(shí)例。
然而可以創(chuàng)建一個(gè)變量，其類型是一個(gè)抽象類，并讓它指向具體子類的一個(gè)實(shí)例。
不能有抽象構(gòu)造函數(shù)或抽象靜態(tài)方法。Abstract 類的子類為它們父類中的所有抽象方法提供實(shí)現(xiàn)，否則它們也是抽象類為。取而代之，在子類中實(shí)現(xiàn)該方法。知道其行為的其它類可以在類中實(shí)現(xiàn)這些方法。
接口（interface）是抽象類的變體。在接口中，所有方法都是抽象的。多繼承性可通過實(shí)現(xiàn)這樣的接口而獲得。
接口中的所有方法都是抽象的，沒有一個(gè)有程序體。接口只可以定義static final成員變量。接口的實(shí)現(xiàn)與子類相似，除了該實(shí)現(xiàn)類不能從接口定義中繼承行為。
當(dāng)類實(shí)現(xiàn)特殊接口時(shí)，它定義（即將程序體給予）所有這種接口的方法。然后，它可以在實(shí)現(xiàn)了該接口的類的任何對象上調(diào)用接口的方法。由于有抽象類，它允許使用接口名作為引用變量的類型。
通常的動態(tài)聯(lián)編將生效。引用可以轉(zhuǎn)換到接口類型或從接口類型轉(zhuǎn)換，instanceof 運(yùn)算符可以用來決定某對象的類是否實(shí)現(xiàn)了接口。
java 中interface和抽象類的區(qū)別
.概述 一個(gè)軟件設(shè)計(jì)的好壞，我想很大程度上取決于它的整體架構(gòu)，而這個(gè)整體架構(gòu)其實(shí)就是你對整個(gè)宏觀商業(yè)業(yè)務(wù)的抽象框架，當(dāng)代表業(yè)務(wù)邏輯的高層抽象層結(jié)構(gòu) 合理時(shí)，你底層的具體實(shí)現(xiàn)需要考慮的就僅僅是一些算法和一些具體的業(yè)務(wù)實(shí)現(xiàn)了。當(dāng)你需要再開發(fā)另一個(gè)相近的項(xiàng)目時(shí)，你以前的抽象層說不定還可以再次利用 。
面對對象的設(shè)計(jì)，復(fù)用的重點(diǎn)其實(shí)應(yīng)該是抽象層的復(fù)用，而不是具體某一個(gè)代碼塊的復(fù)用。
說到了抽象，我就不能不提到曾讓我頭痛的Java接口和Java抽象類了，這也是本文我想說的重點(diǎn)。既然面向?qū)ο笤O(shè)計(jì)的重點(diǎn)在于抽象，那Java接口和Java抽象類就有它存在的必然性了。Java接口(interface)和Java抽象類(abstract class)代表的就是抽象類型，就是我們需要提出的抽象層的具體表現(xiàn)。OOP面向?qū)ο蟮木幊蹋绻岣叱绦虻膹?fù)用率，增加程序 的可維護(hù)性，可擴(kuò)展性，就必須是面向接口的編程，面向抽象的編程，正確地使用接口、抽象類這些有用的抽象類型作為你結(jié)構(gòu)層次上的頂層。
Java接口和Java抽象類有太多相似的地方，又有太多特別的地方，究竟在什么地方，才是它們的**位置呢？把它們比較一下，你就可以發(fā)現(xiàn)了。Java接口和Java抽象類**的一個(gè)區(qū)別，就在于Java抽象類可以提供某些方法的部分實(shí)現(xiàn)，而Java接口不可以（就是interface中只能定義方法，而不能有方法的實(shí)現(xiàn)，而在abstract class中則可以既有方法的具體實(shí)現(xiàn)，又有沒有具體實(shí)現(xiàn)的抽象方法），這大概就是Java抽象類**的優(yōu)點(diǎn)吧，但這個(gè)優(yōu)點(diǎn)非常有用。如果向一個(gè)抽象類里加入一個(gè)新的具體方法時(shí)，那么它所有的子類都一下子都得到了這個(gè)新方法，而Java接口做不到這一點(diǎn)，如果向一個(gè)Java接口里加入一個(gè) 新方法，所有實(shí)現(xiàn)這個(gè)接口的類就無法成功通過編譯了，因?yàn)槟惚仨氉屆恳粋€(gè)類都再實(shí)現(xiàn)這個(gè)方法才行，這顯然是Java接口的缺點(diǎn)。
這個(gè)在我的另外一篇博客mapreduce 新舊API 區(qū)別中有提到類似的問題，在新的mapreduce api中更傾向于使用抽象類，而不是接口，因?yàn)檫@更容易擴(kuò)展。原因就是上面劃線部分所說的。 一個(gè)抽象類的實(shí)現(xiàn)只能由這個(gè)抽象類的子類給出，也就是說，這個(gè)實(shí)現(xiàn)處在抽象類所定義出的繼承的等級結(jié)構(gòu)中，而由于Java語言的單繼承性，所以抽象類作為類型定義工具的效能大打折扣。
在這一點(diǎn)上，Java接口的優(yōu)勢就出來了，任何一個(gè)實(shí)現(xiàn)了一個(gè)Java接口所規(guī)定的方法的類都可以具有這個(gè)接口的類型，而一個(gè)類可以實(shí)現(xiàn)任意多個(gè)Java接口，從而這個(gè)類就有了多種類型。（使用抽象類，那么繼承這個(gè)抽象類的子類類型就比較單一，因?yàn)樽宇愔荒軉卫^承抽象類;而子類能夠同時(shí)實(shí)現(xiàn)多個(gè)接口，因?yàn)轭愋途捅容^多。接口和抽象類都可以定義對象，但是只能用他們的具體實(shí)現(xiàn)類來進(jìn)行實(shí)例化。
） 從第2點(diǎn)不難看出，Java接口是定義混合類型的理想工具，混合類表明一個(gè)類不僅僅具有某個(gè)主類型的行為，而且具有其他的次要行為。 結(jié)合1、2點(diǎn)中抽象類和Java接口的各自優(yōu)勢，具精典的設(shè)計(jì)模式就出來了：聲明類型的工作仍然由Java接口承擔(dān)，但是同時(shí)給出一個(gè)Java 抽象類，且實(shí)現(xiàn)了這個(gè)接口，而其他同屬于這個(gè)抽象類型的具體類可以選擇實(shí)現(xiàn)這個(gè)Java接口，也可以選擇繼承這個(gè)抽象類，也就是說在層次結(jié)構(gòu)中，Java 接口在最上面，然后緊跟著抽象類，這下兩個(gè)的**優(yōu)點(diǎn)都能發(fā)揮到極至了。這個(gè)模式就是“缺省適配模式”。在Java語言API中用了這種模式，而且全都遵循一定的命名規(guī)范：Abstract ＋接口名。
（A extends AbstractB implements interfaceC，那么A即可以選擇實(shí)現(xiàn)(@Override)接口interfaceC中的方法，也可以選擇不實(shí)現(xiàn);A即可以選擇實(shí)現(xiàn)(@Override)抽象類AbstractB中的方法，也可以選擇不實(shí)現(xiàn)） Java接口和Java抽象類的存在就是為了用于具體類的實(shí)現(xiàn)和繼承的，如果你準(zhǔn)備寫一個(gè)具體類去繼承另一個(gè)具體類的話，那你的設(shè)計(jì)就有很大問題了。Java抽象類就是為了繼承而存在的，它的抽象方法就是為了強(qiáng)制子類必須去實(shí)現(xiàn)的。使用Java接口和抽象Java類進(jìn)行變量的類型聲明、參數(shù)是類型聲明、方法的返還類型說明，以及數(shù)據(jù)類型的轉(zhuǎn)換等。而不要用具體Java類進(jìn)行變量的類型聲明、參數(shù)是類型聲明、方法的返還類型說明，以及數(shù)據(jù)類型的轉(zhuǎn)換等。
2.實(shí)例 下面給出一個(gè)具體的接口Action，代碼如下所示：[java] view plaincopy package org.springframework.webflow.execution; public interface Action {public Event execute(RequestContext context) throws Exception; } 在這個(gè)接口中，定義了一個(gè)沒有具體實(shí)現(xiàn)的方法，方法名叫做execute()，返回類型是Event。如前面**條所述，接口中的方法都是沒有實(shí)現(xiàn)的。這些方法的具體實(shí)現(xiàn)是在實(shí)現(xiàn)(implements)這個(gè)接口的類中給出的。 再來看一個(gè)實(shí)現(xiàn)Action接口的抽象類AbstractAction，代碼如下。
[java] view plaincopy 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 { } } 在抽象類AbstractAction中，既有具體實(shí)現(xiàn)的方法，又有沒有具體實(shí)現(xiàn)的抽象方法 [java] view plaincopy //抽象方法 protected abstract Event doExecute(RequestContext context) throws Exception; 需要注意的是在抽象類中，如果方法沒有具體實(shí)現(xiàn)（就是方法后面沒有{}），那么必須加上abstract來聲明這個(gè)方法，而接口中不需要使用abstract來聲明（抽象類之所以被稱為抽象類，就是因?yàn)樗谐橄蠓椒?。含有抽象方法的類叫做抽象類）?/p>
例舉抽象類和一般類的區(qū)別？急求
抽象類不能用new來實(shí)例對象，其次抽象類中一般含有抽象的方法，需要繼承子類具體實(shí)現(xiàn)。它是Java類體系結(jié)構(gòu)中很重要的一個(gè)組成部分 ，它是介于 接口/類 之間的一種實(shí)現(xiàn)方式 。
抽象類與靜態(tài)類的區(qū)別？
抽象類不能實(shí)例化。一般用來構(gòu)造基類。
靜態(tài)類不管實(shí)例化多少個(gè)，調(diào)用的都是最初實(shí)例化的那個(gè)。
一般做程序中的全局變量（**實(shí)例）時(shí)。關(guān)于用類名來調(diào)用靜態(tài)成員函數(shù)，不管是哪個(gè)類（抽象類，靜態(tài)類，一般的類），只要是靜態(tài)成員函數(shù)，都可以寫類名來調(diào)用。
繪畫中什么叫做抽象?抽象和具像的區(qū)別是什么?如何抽象?
大多數(shù)在藝術(shù)中一般會將“抽象”當(dāng)做是抽象畫的同義詞.但它可以是指任何由現(xiàn)實(shí)世界中精煉出的物件或圖像,或者是完全無關(guān)的其他概念.在最現(xiàn)實(shí)的意義之下,抽象畫并不是真的是抽象的.藝術(shù)家羅伯特·斯塔克寫道：“距離放棄了形式的風(fēng)景畫且改去發(fā)覺不具表現(xiàn)主題地將顏料自由地涂在畫紙上之更直接的表現(xiàn)方式,已經(jīng)過了有十年的時(shí)間了,我也發(fā)展出了一個(gè)新的詞匯;明和暗、暖和冷、making marks、brush-strokes like heart-rhythms.每**都是一次獨(dú)自的作畫能力之測試.每一張畫作都會被不斷地被更改、被重制、被擦掉或被重畫,只要它還留在這個(gè)工作室里……” 抽象藝術(shù)是與具象藝術(shù)相對的名稱,也可稱為非具象藝術(shù).它的特征是缺乏描繪,用情緒的方法去表現(xiàn)概念和作畫,而這種方法基本上就是屬于表現(xiàn)主義的,最早見于康定斯基的作品.它是由各種反傳統(tǒng)的藝術(shù)影響融合而來,特別是由野獸派、立體派演變而來.“抽象”藝術(shù)在畢加索看來并不存在,他認(rèn)為只不過有人強(qiáng)調(diào)風(fēng)格,有人強(qiáng)調(diào)生活罷了.在米歇爾·塞弗爾看來,抽象藝術(shù)是：“我把一切不帶任何提醒,不帶任何對于現(xiàn)實(shí)的回憶——不管這一現(xiàn)實(shí)是否是畫家的出發(fā)點(diǎn)——的藝術(shù)都叫作抽象藝術(shù).實(shí)際上野獸派和立體派促進(jìn)了形與色的獨(dú)立發(fā)展.是康定斯基進(jìn)一步發(fā)現(xiàn)了它的奧妙,他在1910年畫了**幅斷然抽象的水彩畫,是一幅無具象愿望的、充滿活力的重疊色點(diǎn).康定斯基的創(chuàng)造性發(fā)明是從音樂中獲得美學(xué)啟迪,爾后捷克人庫普卡直接從音樂中獲取靈感進(jìn)行抽象藝術(shù)創(chuàng)作.人稱他是音樂主義畫家鼻祖,后來他們共同組成抽象派.抽象畫其實(shí)并不好畫,之所以說是抽象畫,是因?yàn)樗鼜木唧w中抽出來的,并不是隨便畫的也更不能瞎話,抽象畫要有一定的夸張,但不能隨便夸張,必須有一定的依據(jù)!每畫一點(diǎn)都是有根據(jù)的,為什么要這么話必須應(yīng)該知道,當(dāng)然多看一些**的畫是有好處的,但是一般**的抽象畫是很難懂的,看不出來他的意圖!他們所謂的隨意是必須建立在很深的繪畫基礎(chǔ)和很高深的思想上的,!
