接口和類(lèi)的區(qū)別這話題我在各種技術(shù)群里看人吵了無(wú)數(shù)次了。每次一聊到“什么時(shí)候用接口什么時(shí)候用抽象類(lèi)什么時(shí)候我就直接寫(xiě)個(gè)普通類(lèi)拉倒”總有老哥能從古早的Java教材一路談到項(xiàng)目里那坨只可意會(huì)不可言傳的祖?zhèn)鞔a。我自己帶過(guò)幾個(gè)項(xiàng)目見(jiàn)過(guò)把接口用成擺設(shè)的也見(jiàn)過(guò)把接口拆得比樂(lè)高還碎、一個(gè)功能恨不得定義五個(gè)接口的設(shè)計(jì)潔癖說(shuō)實(shí)話這兩個(gè)概念沒(méi)在真實(shí)項(xiàng)目里頓悟過(guò)一兩回靠背面試題是真的很難吃透。今天不聊教科書(shū)就著這些年踩過(guò)的坑和對(duì)源碼的一些理解把“接口”和“類(lèi)”這件事一次性捋清楚。這篇內(nèi)容不挑語(yǔ)言基礎(chǔ)只要你在寫(xiě)Java、C、PHP、Python或者其他什么面向?qū)ο蟮恼Z(yǔ)言都應(yīng)該能從中撈到點(diǎn)有用的東西。我會(huì)從底層邏輯、語(yǔ)法差異、設(shè)計(jì)思路一直到項(xiàng)目落地時(shí)的選型判斷逐層拆開(kāi)來(lái)說(shuō)。哪怕是剛學(xué)會(huì)寫(xiě)類(lèi)的小白看完也應(yīng)該能建立起一套自己的判斷標(biāo)準(zhǔn)而不是死記硬背“接口不能實(shí)例化、類(lèi)可以實(shí)例化”這種口訣。1. 先建立認(rèn)知接口和類(lèi)的本質(zhì)分工要理解它們的區(qū)別不能先背語(yǔ)法表。先想清楚一個(gè)問(wèn)題類(lèi)到底是什么接口又到底是什么類(lèi)本質(zhì)上是一個(gè)“具體的東西”。它把狀態(tài)和行為打包在一起。狀態(tài)是字段、屬性行為是方法。你new一個(gè)類(lèi)出來(lái)它就是一塊真實(shí)的、有內(nèi)存形態(tài)的對(duì)象。比如“寶馬汽車(chē)”這個(gè)類(lèi)它有顏色、有排量、有方向盤(pán)能啟動(dòng)能剎車(chē)。你說(shuō)“給我造一輛寶馬”它得真能造出來(lái)。接口本質(zhì)上是一份“契約”。它不負(fù)責(zé)任何具體實(shí)現(xiàn)只負(fù)責(zé)規(guī)定“你必須能做什么”。比如“可駕駛”這個(gè)接口規(guī)定你必須有“啟動(dòng)”和“剎車(chē)”這兩個(gè)能力但至于你是用內(nèi)燃機(jī)啟動(dòng)還是用電動(dòng)機(jī)啟動(dòng)接口不管。你說(shuō)“我要一個(gè)可駕駛的東西”可能來(lái)的是寶馬也可能來(lái)的是拖拉機(jī)。這樣一說(shuō)區(qū)別就很顯然了類(lèi)解決的是“怎么做”的問(wèn)題接口解決的是“能做什么”的問(wèn)題。我在項(xiàng)目里見(jiàn)過(guò)很多人犯一個(gè)認(rèn)知錯(cuò)誤一上來(lái)定義了個(gè)接口接口里寫(xiě)了十來(lái)個(gè)方法然后找了一個(gè)實(shí)現(xiàn)類(lèi)把所有方法都實(shí)現(xiàn)了一遍從此這個(gè)接口就再也沒(méi)被第二個(gè)類(lèi)用過(guò)。這種接口的意義幾乎為零。接口的價(jià)值不在于“我定義了個(gè)類(lèi)型”而在于“多個(gè)完全不相關(guān)的類(lèi)因?yàn)楣蚕硗环萜跫s從而可以被統(tǒng)一調(diào)度”。再往深一點(diǎn)說(shuō)類(lèi)和接口的分工也決定了它們?cè)谙到y(tǒng)中扮演的角色不同。類(lèi)是你系統(tǒng)的“血肉”負(fù)責(zé)承載業(yè)務(wù)復(fù)雜度、處理數(shù)據(jù)、組織邏輯。接口是你系統(tǒng)的“骨架”負(fù)責(zé)定義邊界、穩(wěn)定協(xié)作關(guān)系。架構(gòu)設(shè)計(jì)的時(shí)候你要先搭骨架再填血肉而不是先把血肉堆成一團(tuán)再試圖反推骨架。這就是為什么大廠里常見(jiàn)的設(shè)計(jì)是先定義接口再討論實(shí)現(xiàn)類(lèi)。我從實(shí)際項(xiàng)目里的感受是當(dāng)你發(fā)現(xiàn)自己開(kāi)始糾結(jié)“這個(gè)接口到底該怎么命名才能涵蓋未來(lái)所有可能”的時(shí)候你大概率是被設(shè)計(jì)潔癖綁架了。接口是簡(jiǎn)潔的承諾不是無(wú)所不包的預(yù)言。承諾得越少系統(tǒng)越容易演化。2. 語(yǔ)法層面的硬核區(qū)別聊完認(rèn)知來(lái)硬的。語(yǔ)法層面接口和類(lèi)的差異在各個(gè)語(yǔ)言里大同小異但以Java最為典型。我直接用表格把關(guān)鍵差異列出來(lái)再逐個(gè)展開(kāi)講。對(duì)比項(xiàng)類(lèi)Class接口Interface實(shí)例化可以new不能new方法實(shí)現(xiàn)方法可以有實(shí)現(xiàn)Java 8前不能有實(shí)現(xiàn)Java 8后可有default/static方法字段可有任意狀態(tài)字段只能有public static final常量構(gòu)造方法有沒(méi)有繼承/實(shí)現(xiàn)類(lèi)單繼承類(lèi)接口多繼承接口類(lèi)可多實(shí)現(xiàn)接口訪問(wèn)修飾符可自由指定方法默認(rèn)public抽象程度具體類(lèi)實(shí)現(xiàn)完整邏輯抽象類(lèi)可留抽象方法全是約定沒(méi)有具體狀態(tài)先來(lái)說(shuō)最關(guān)鍵的多重繼承問(wèn)題。Java的類(lèi)只能單繼承這是為了防止菱形繼承搗亂。但接口可以多實(shí)現(xiàn)一個(gè)類(lèi)可以implements好幾個(gè)接口就像“一個(gè)人可以既是司機(jī)又當(dāng)廚師還兼職攝影師”一樣幾個(gè)契約之間互不打架。C里類(lèi)的多繼承則是直接把菱形繼承問(wèn)題交給了程序員用虛繼承才能避免二義性很多C老手都栽過(guò)這個(gè)坑。然后是抽象類(lèi)。這個(gè)經(jīng)常和接口混淆。抽象類(lèi)是“不完整的類(lèi)”它已經(jīng)是類(lèi)了有構(gòu)造方法、有字段、有部分實(shí)現(xiàn)只是其中有些方法沒(méi)有實(shí)現(xiàn)留到子類(lèi)去填。它和接口的區(qū)別本質(zhì)上是抽象類(lèi)關(guān)心的是“你是誰(shuí)”接口關(guān)心的是“你能干嘛”。舉個(gè)例子“動(dòng)物”是抽象類(lèi)因?yàn)樗形锓N屬性、身高體重這些狀態(tài)也有叫喚這個(gè)抽象方法而“會(huì)飛”是接口蝙蝠和蝴蝶都能實(shí)現(xiàn)它但相處沒(méi)有任何血緣關(guān)系。如果你心里裝著“is-a”關(guān)系用抽象類(lèi)如果你是“has-a能力”、“can-do行為”用接口。字段這塊也很多人記錯(cuò)。接口里的字段不管你寫(xiě)不寫(xiě)修飾符它最終都是public static final。這意味著接口不能有狀態(tài)它的“常量”其實(shí)是為了協(xié)議定義服務(wù)的比如定義版本號(hào)、默認(rèn)配置、狀態(tài)碼。而類(lèi)的字段就是真正參與對(duì)象的生命周期和業(yè)務(wù)邏輯的。所以你要把可變狀態(tài)塞進(jìn)接口里語(yǔ)法層面直接就不允許。這也從另一個(gè)角度說(shuō)明接口是穩(wěn)定的契約不允許被狀態(tài)污染。還有一點(diǎn)容易被忽略構(gòu)造方法。類(lèi)必須有構(gòu)造方法哪怕默認(rèn)的無(wú)參構(gòu)造它也存在因?yàn)橐獙?shí)例化就要走構(gòu)造流程。接口壓根沒(méi)有構(gòu)造方法因?yàn)樗烊痪筒皇怯脕?lái)“生成對(duì)象”的。有些人會(huì)問(wèn)匿名內(nèi)部類(lèi)實(shí)現(xiàn)接口的時(shí)候好像寫(xiě)了構(gòu)造邏輯那是類(lèi)在構(gòu)造不是接口在構(gòu)造。你new的對(duì)象其實(shí)是編譯器幫你生成的匿名類(lèi)不是接口本身。再說(shuō)說(shuō)抽象類(lèi)的“類(lèi)屬性”帶來(lái)的一些后果。因?yàn)榻涌诓荒苡袑?shí)例字段所以在需要“攜帶狀態(tài)”的抽象設(shè)計(jì)上接口就很別扭。比如你要抽象一個(gè)連接池池里有大小、繁忙計(jì)數(shù)這些狀態(tài)這用接口定義起來(lái)就很不舒服。這時(shí)候抽象類(lèi)甚至普通基類(lèi)就更合適。這是我這兩年做中間件封裝時(shí)最深刻的體會(huì)接口適合定義“通道”抽象類(lèi)適合定義“底座”。3. 語(yǔ)法之外設(shè)計(jì)層面的差異才是靈魂語(yǔ)法區(qū)別背得再熟寫(xiě)不出好代碼也白搭。接口和類(lèi)真正的區(qū)別在設(shè)計(jì)中體現(xiàn)得更兇。在項(xiàng)目里我見(jiàn)過(guò)一個(gè)最常見(jiàn)的反派面向?qū)崿F(xiàn)編程。調(diào)用方直接依賴某個(gè)具體的類(lèi)比如HashMap用得爽就直接把HashMap當(dāng)參數(shù)類(lèi)型傳遍天涯海角。結(jié)果下一次需求要換并發(fā)安全的Map所有方法簽名都得跟著改光改類(lèi)型就能改一天。這就是典型的“類(lèi)依賴”帶來(lái)的耦合。而面向接口編程核心是依賴倒置高層模塊不依賴低層模塊兩者都依賴抽象。你把Map接口當(dāng)成方法參數(shù)類(lèi)型傳HashMap也好ConcurrentHashMap也罷調(diào)用方一概不感知。這時(shí)候接口就是你給代碼之間加的“緩沖墊”讓兩邊可以各自演化?；卣{(diào)機(jī)制是接口在實(shí)際業(yè)務(wù)中最典型的應(yīng)用?；卣{(diào)的本質(zhì)是某個(gè)模塊在事件發(fā)生的時(shí)候調(diào)用你注冊(cè)進(jìn)來(lái)的代碼。Java里最古典的回調(diào)方式就是定義一個(gè)接口把方法實(shí)現(xiàn)傳出去。比如你給按鈕注冊(cè)點(diǎn)擊事件public interface OnClickListener { void onClick(View v); } button.setOnClickListener(new OnClickListener() { Override public void onClick(View v) { // 點(diǎn)按之后具體干什么 } });看到?jīng)]OnClickListener是個(gè)接口它做的事情就是定義“點(diǎn)擊事件到了之后你要干什么”的契約。按鈕這個(gè)類(lèi)自己不關(guān)心你干了什么它只負(fù)責(zé)在點(diǎn)擊的時(shí)候喊一嗓子“onClick”然后具體執(zhí)行什么邏輯全由調(diào)用方實(shí)現(xiàn)。到了JDK 8之后Java引入了lambda和函數(shù)式接口這種“只定義契約不實(shí)現(xiàn)邏輯”的模式被發(fā)揮到了極致。函數(shù)式接口就是只有一個(gè)抽象方法的接口lambda表達(dá)式本質(zhì)上就是這種接口的匿名實(shí)現(xiàn)。比如list.stream().filter(x - x 5).forEach(System.out::println);這里filter接收的是PredicateIntegerforEach接收的是ConsumerInteger這對(duì)只關(guān)注語(yǔ)法的人來(lái)說(shuō)可能沒(méi)什么感覺(jué)但對(duì)理解接口的人來(lái)說(shuō)這就是接口的現(xiàn)代形態(tài)一個(gè)接口不再非要聲明成“某某Service”它完全可以是一個(gè)語(yǔ)義單一的普通接口用來(lái)承載一個(gè)函數(shù)級(jí)別的契約。也是因?yàn)檫@種設(shè)計(jì)Kotlin里干脆把lambda和接口玩成了一個(gè)東西你甚至可以拿lambda去替代大部分單方法接口。再比如Android開(kāi)發(fā)里常見(jiàn)的“回調(diào)轉(zhuǎn)掛起工具類(lèi)”。協(xié)程的suspendCancellableCoroutine本質(zhì)上就是把你那個(gè)回調(diào)式的接口轉(zhuǎn)換成一種掛起函數(shù)。背后的邏輯就是接口在這兒是一種“通道”它接收外部產(chǎn)生的事件你的工具類(lèi)負(fù)責(zé)把這個(gè)通道轉(zhuǎn)成協(xié)程能響應(yīng)的東西。如果離開(kāi)了接口這個(gè)抽象壓根不可能完成這種跨范式的轉(zhuǎn)換。接口的威力就在這里它在各種編程范式之間當(dāng)翻譯官。那類(lèi)在設(shè)計(jì)層面的定位是什么呢類(lèi)適合承擔(dān)“實(shí)體建?！焙汀熬唧w策略”的角色。在策略模式里接口定義“策略”的骨架不同的類(lèi)填充不同的算法細(xì)節(jié)。比如支付方式PaymentStrategy是接口微信支付、支付寶支付、銀行卡支付是不同類(lèi)。調(diào)用方拿著接口類(lèi)型運(yùn)行時(shí)塞進(jìn)哪個(gè)實(shí)現(xiàn)執(zhí)行的就是哪種支付策略。這里類(lèi)的職責(zé)是提供差異化的實(shí)現(xiàn)方案接口的職責(zé)是統(tǒng)一它們的對(duì)外形態(tài)。再說(shuō)一個(gè)很多人容易產(chǎn)生誤會(huì)的點(diǎn)接口和類(lèi)的設(shè)計(jì)視角。類(lèi)是自下而上的你看到業(yè)務(wù)里有一個(gè)具體的東西你把它的屬性和行為歸納出來(lái)形成一個(gè)類(lèi)。接口是自上而下的你先定義好系統(tǒng)內(nèi)角色之間的協(xié)作關(guān)系再把“誰(shuí)能承擔(dān)這個(gè)角色”的設(shè)計(jì)要求投射給實(shí)現(xiàn)方。所以我們做架構(gòu)的時(shí)候順序往往是先寫(xiě)接口再寫(xiě)實(shí)現(xiàn)類(lèi)。順序反了你就是在給代碼寫(xiě)事后說(shuō)明而不是在做設(shè)計(jì)。4. 不同語(yǔ)言生態(tài)下接口與類(lèi)的變體對(duì)比接口和類(lèi)的區(qū)別不是Java的專(zhuān)享話題。在每個(gè)語(yǔ)言里這兩者都有自己變了個(gè)樣子的表達(dá)方式搞懂它們有個(gè)共同內(nèi)核對(duì)你切換到其他語(yǔ)言會(huì)非常有幫助。Java接口語(yǔ)法演進(jìn)最典型。JDK 7時(shí)代接口只能有抽象方法一個(gè)方法都不能實(shí)現(xiàn)。JDK 8引入了default方法和static方法這時(shí)候接口開(kāi)始具備了一定“實(shí)現(xiàn)能力”。JDK 9之后又允許接口寫(xiě)私有方法專(zhuān)門(mén)給default方法當(dāng)內(nèi)部工具方法用。但無(wú)論怎么演進(jìn)接口始終沒(méi)有字段、沒(méi)有狀態(tài)這條紅線從沒(méi)破過(guò)。C沒(méi)有interface這個(gè)關(guān)鍵字。C里可以用純虛類(lèi)也叫抽象基類(lèi)模擬接口一個(gè)類(lèi)全是純虛函數(shù)沒(méi)有數(shù)據(jù)成員沒(méi)有構(gòu)造函數(shù)實(shí)現(xiàn)它就是接口。C的純虛類(lèi)比Java接口更野一點(diǎn)因?yàn)樗梢杂谐蓡T函數(shù)聲明、析構(gòu)函數(shù)甚至可以在虛析構(gòu)里有默認(rèn)實(shí)現(xiàn)。還有一個(gè)區(qū)別C沒(méi)有內(nèi)置的interface和implement的區(qū)分所以它就是靠類(lèi)的語(yǔ)法特性硬拗出了“接口”這個(gè)形態(tài)。Python走的是鴨子類(lèi)型理論上不需要接口。Python講究“看到了就是”你要的是能叫的那它只要會(huì)quack()就夠了根本不關(guān)心它是鴨子還是人。這種靈活性很爽但大型項(xiàng)目里沒(méi)約束就是災(zāi)難的溫床。所以Python的標(biāo)準(zhǔn)庫(kù)提供了abcAbstract Base Classes模塊用抽象基類(lèi)來(lái)疊加約束。再有就是typing.Protocol這個(gè)更神奇它是結(jié)構(gòu)性子類(lèi)型不需要類(lèi)顯式繼承它只要類(lèi)的結(jié)構(gòu)上有對(duì)應(yīng)方法類(lèi)型檢查器就認(rèn)可它符合這個(gè)協(xié)議。Python在接口這件事上更像是做“道德約束”而不是“法律約束”。PHPclass 和 interface 分得清清楚楚interface 里可以定義常量和方法簽名實(shí)現(xiàn)類(lèi)用implements關(guān)鍵字。PHP有個(gè)比Java現(xiàn)代的地方接口支持常量但子類(lèi)不能被 override——這在Java里其實(shí)也能做但語(yǔ)義上不太順。PHP里還能同時(shí)繼承類(lèi)和實(shí)現(xiàn)接口誰(shuí)是對(duì)誰(shuí)是什么一望即知。Go嚴(yán)格來(lái)說(shuō)Go不是傳統(tǒng)OOP語(yǔ)言但它的接口設(shè)計(jì)是我認(rèn)為最有啟發(fā)性的。Go的接口是隱式實(shí)現(xiàn)不需要你用implements聲明只要一個(gè)類(lèi)的方法集合包含了接口的全部方法它就自動(dòng)實(shí)現(xiàn)了這個(gè)接口。這種“鴨子類(lèi)型編譯期檢查”的組合讓接口在Go里用起來(lái)十分輕量接口成了組合的利器。我最早對(duì)接口的理解是純Java視角的后來(lái)接觸了Python和Go才意識(shí)到接口的本質(zhì)其實(shí)是“對(duì)能力的最小承諾”。不同語(yǔ)言只是把這同一個(gè)承諾包裝成不同的語(yǔ)法外衣罷了。所以面試問(wèn)你“接口和類(lèi)的區(qū)別”你別只背Java語(yǔ)法你要能把這種“契約vs實(shí)現(xiàn)”的底層認(rèn)知講出來(lái)那才是真正理解了。下面給一個(gè)多語(yǔ)言快速對(duì)照表語(yǔ)言接口實(shí)現(xiàn)方式類(lèi)的繼承接口是否可含實(shí)現(xiàn)特點(diǎn)備注Javaimplements interface單繼承JDK8可含default/static嚴(yán)謹(jǐn)類(lèi)型體系清晰C純虛類(lèi)多繼承純虛類(lèi)無(wú)實(shí)現(xiàn)但可有虛析構(gòu)強(qiáng)大但容易踩菱形繼承Python鴨子類(lèi)型 ABC/Protocol多繼承抽象基類(lèi)可含實(shí)現(xiàn)靈活靠自覺(jué)類(lèi)型檢查PHPimplements interface單繼承可定義方法簽名與常量與Java高度類(lèi)似Go隱式實(shí)現(xiàn)組合替代繼承接口通常只放方法簽名組合優(yōu)于繼承隱式自適應(yīng)5. 項(xiàng)目實(shí)戰(zhàn)怎樣的代碼才算用對(duì)了接口和類(lèi)原理講再多不如看兩段真實(shí)的代碼來(lái)得直觀。我拿一個(gè)業(yè)務(wù)系統(tǒng)里特別經(jīng)典的需求來(lái)說(shuō)事大家看明白之后馬上就能在自己的項(xiàng)目里用起來(lái)。假設(shè)要做多平臺(tái)的登錄對(duì)接平臺(tái)有微信、抖音、淘寶。很多人拿到需求就開(kāi)始寫(xiě)類(lèi)新建一個(gè)WechatLoginService里面一個(gè)login()方法寫(xiě)它微信授權(quán)的邏輯新建一個(gè)TiktokLoginService里面也是login()但代碼是抖音授權(quán)的邏輯。到后端的時(shí)候看起來(lái)也沒(méi)毛病就是三個(gè)類(lèi)干三套活兒。但是接下來(lái)問(wèn)題就來(lái)了。你的業(yè)務(wù)主流程要用統(tǒng)一的“登錄”入口你寫(xiě)代碼的時(shí)候就得這樣if (platform.equals(wechat)) { wechatLoginService.login(); } else if (platform.equals(tiktok)) { tiktokLoginService.login(); }這種就是典型的面向類(lèi)編程。每加一個(gè)新平臺(tái)你就要在主流程里加一分支。平臺(tái)多了之后這主流程代碼寫(xiě)著寫(xiě)著就成了一盤(pán)大雜燴每個(gè)分支里還可能混著各自平臺(tái)返回的用戶信息轉(zhuǎn)本系統(tǒng)的邏輯到最后沒(méi)人敢動(dòng)這塊代碼因?yàn)橐徊涣羯窬蛣?dòng)了誰(shuí)的奶酪。正確的做法是用接口定義登錄的契約讓每個(gè)平臺(tái)按契約各自實(shí)現(xiàn)public interface PlatformLoginService { // 每個(gè)平臺(tái)統(tǒng)一的登錄入口 LoginResult login(LoginRequest request); // 每個(gè)平臺(tái)回調(diào)校驗(yàn)的統(tǒng)一入口 UserProfile verifyCallback(String code, MapString, String params); // 給業(yè)務(wù)方用的平臺(tái)識(shí)別 PlatformEnum platform(); }然后讓微信、抖音、淘寶各自的類(lèi)去implements這個(gè)接口。主流程里只需要這樣public LoginResult login(String platform, LoginRequest request) { PlatformLoginService service serviceRegistry.get(platform); return service.login(request); }新平臺(tái)接入的時(shí)候只需要新寫(xiě)一個(gè)實(shí)現(xiàn)類(lèi)并且注冊(cè)到serviceRegistry里主流程一行代碼都不用改。這就是“開(kāi)閉原則”對(duì)擴(kuò)展開(kāi)放對(duì)修改關(guān)閉。而能把擴(kuò)展打開(kāi)的那把鑰匙就是接口。我再補(bǔ)充一個(gè)我在真實(shí)項(xiàng)目里踩過(guò)的坑。很多人確實(shí)會(huì)模仿這個(gè)寫(xiě)法創(chuàng)建接口但實(shí)現(xiàn)類(lèi)里干的一件事是把接口里定義的方法參數(shù)、返回值類(lèi)型直接用自己家的自定義類(lèi)比如LoginResult這個(gè)類(lèi)型是微信平臺(tái)定制的里面有微信特有的字段。結(jié)果其他平臺(tái)想實(shí)現(xiàn)的時(shí)候發(fā)現(xiàn)返回值根本沒(méi)法用只能往這個(gè)類(lèi)里硬塞一堆null字段。接口一旦被具體實(shí)現(xiàn)“劫持”了類(lèi)型定義它就不再是契約了而是一張某實(shí)現(xiàn)類(lèi)的皮。這里特別考驗(yàn)設(shè)計(jì)者的火候接口里的類(lèi)型必須是通用抽象層的東西不能是某個(gè)實(shí)現(xiàn)專(zhuān)屬的東西。再說(shuō)一個(gè)很多人的疑問(wèn)接口和類(lèi)在實(shí)際底層源碼里編譯器是怎么處理它們的關(guān)系的Java里interface編譯之后也會(huì)生成一個(gè).class文件和普通類(lèi)的字節(jié)碼格式基本一致。關(guān)鍵在于JVM的invokeinterface指令和invokevirtual指令兩者方法分派的邏輯不同。接口方法是JVM運(yùn)行時(shí)動(dòng)態(tài)找具體實(shí)現(xiàn)類(lèi)的走的是“它得先確認(rèn)你能調(diào)這個(gè)接口方法”的路徑所以直接用接口引用調(diào)用方法會(huì)走invokeinterface性能上會(huì)比invokevirtual稍微差一丁點(diǎn)?，F(xiàn)代JVM會(huì)做各種優(yōu)化比如內(nèi)聯(lián)緩存這點(diǎn)差異在絕大多數(shù)業(yè)務(wù)場(chǎng)景里幾乎可以忽略不計(jì)。但面試官如果問(wèn)到“接口方法和類(lèi)方法的JVM調(diào)用區(qū)別”能答到這個(gè)層次絕對(duì)是個(gè)加分項(xiàng)。6. 避坑指南實(shí)踐中常見(jiàn)的選型問(wèn)題與排查思路聊到具體項(xiàng)目里的經(jīng)驗(yàn)必須得把那些年寫(xiě)代碼時(shí)流過(guò)的血淚一并說(shuō)出來(lái)。這里我整理幾個(gè)高頻踩坑場(chǎng)景方便各位直接對(duì)照。第一個(gè)問(wèn)題接口越抽象越好嗎不是。接口定義的粒度應(yīng)該和業(yè)務(wù)協(xié)作的真實(shí)需求匹配。我見(jiàn)過(guò)有人為了“可擴(kuò)展性”把接口方法拆到極細(xì)一個(gè)doStep1()、一個(gè)doStep2()、一個(gè)doStep3()。結(jié)果實(shí)現(xiàn)類(lèi)根本沒(méi)幾個(gè)反倒是調(diào)用方要組合調(diào)用一堆接口方法才能完成一個(gè)完整業(yè)務(wù)動(dòng)作。好的接口應(yīng)該是“一次調(diào)用完成一個(gè)完整業(yè)務(wù)動(dòng)作”而不是把動(dòng)作的每一個(gè)細(xì)節(jié)都暴露出去。接口是給外部看的門(mén)面不是給內(nèi)部看的結(jié)構(gòu)。第二個(gè)問(wèn)題如何判斷該用接口還是抽象類(lèi)看兩個(gè)東西一看是否有狀態(tài)要共享二看子類(lèi)之間是否天然互相替換。如果這些類(lèi)有一個(gè)共同的“身份”比如都是數(shù)據(jù)庫(kù)驅(qū)動(dòng)、都是消息中間件客戶端而且它們需要共享連接池、配置加載這類(lèi)基礎(chǔ)設(shè)施字段那就用抽象類(lèi)作為基類(lèi)。如果這些類(lèi)的能力是一致的但實(shí)現(xiàn)完全八竿子打不著比如日志記錄器、序列化器、緩存都是“插拔式能力”那就是接口的菜。有一個(gè)很土的判斷口訣我一直拿它救命抽象類(lèi)適合“都是XX”接口適合“都能XX”。都是動(dòng)物都能飛前者用抽象類(lèi)后者用接口。都能序列化、都能緩存、都能登錄找接口都是一個(gè)體系的通信協(xié)議、都有公共的連接管理字段找抽象類(lèi)。第三個(gè)問(wèn)題接口方法參數(shù)的校驗(yàn)要放在哪一層這是特別容易被忽視的點(diǎn)。很多初學(xué)者把實(shí)現(xiàn)類(lèi)內(nèi)部做了一堆if (request null) throw new IllegalArgumentException()這種防御性代碼。老實(shí)說(shuō)不是不行但更好的做法是接口方法的javadoc里明確說(shuō)明參數(shù)約束實(shí)現(xiàn)類(lèi)再各自校驗(yàn)。但如果你把校驗(yàn)放在接口層上比如default方法里做通用校驗(yàn)?zāi)悄憔涂梢詫?shí)現(xiàn)全局統(tǒng)一約束不會(huì)出現(xiàn)微信實(shí)現(xiàn)校驗(yàn)了、抖音實(shí)現(xiàn)忘了校驗(yàn)這種“同一接口實(shí)現(xiàn)之間約束不一致”的鬧劇。Java 8允許接口寫(xiě)default方法就是干這個(gè)用的。第四個(gè)問(wèn)題接口里突然要加一個(gè)方法怎么辦這是老Java程序員的最痛。假設(shè)你的接口已經(jīng)被幾十個(gè)實(shí)現(xiàn)類(lèi)繼承了現(xiàn)在新需求要求所有實(shí)現(xiàn)類(lèi)必須支持“導(dǎo)出”。你往接口里一加抽象方法所有實(shí)現(xiàn)類(lèi)全部編譯報(bào)錯(cuò)。這里有兩個(gè)方案但都得分清代價(jià)方案一把新方法聲明為default方法并給一個(gè)合理的默認(rèn)實(shí)現(xiàn)比如直接throw new UnsupportedOperationException(當(dāng)前實(shí)現(xiàn)不支持導(dǎo)出)。好處是改動(dòng)極小壞處是有些實(shí)現(xiàn)類(lèi)可能悄悄“不支持”但不報(bào)錯(cuò)屬于靜默失敗。方案二忍受一次全量修改。把方法加進(jìn)去然后跑到每個(gè)實(shí)現(xiàn)類(lèi)里編譯報(bào)錯(cuò)了一個(gè)個(gè)補(bǔ)。適合實(shí)現(xiàn)類(lèi)不太多并且每個(gè)都得真正實(shí)現(xiàn)的情況。我個(gè)人的經(jīng)驗(yàn)是能預(yù)計(jì)到未來(lái)會(huì)有哪些變法的接口定義的時(shí)候盡量窄真到擴(kuò)展的那一天寧可新建一個(gè)子接口不要?jiǎng)永系慕涌?。比如定義UserQueryService放查詢方法再定義UserCommandService extends UserQueryService放寫(xiě)操作方法。這樣老實(shí)現(xiàn)類(lèi)不受影響新實(shí)現(xiàn)類(lèi)按需選擇實(shí)現(xiàn)哪個(gè)接口。接口的演進(jìn)策略本質(zhì)上也是一個(gè)系統(tǒng)的演進(jìn)策略。第五個(gè)問(wèn)題接口和類(lèi)在“類(lèi)加載”這個(gè)環(huán)節(jié)有什么關(guān)系這個(gè)話題挺冷門(mén)但接熱詞聊一下。Java的類(lèi)加載機(jī)制對(duì)類(lèi)和接口都有效但兩者有個(gè)細(xì)微差別類(lèi)的初始化會(huì)觸發(fā)靜態(tài)塊、靜態(tài)字段賦值接口也有初始化機(jī)制但接口的初始化只發(fā)生在使用到接口里的常量/靜態(tài)字段時(shí)且接口沒(méi)有靜態(tài)代碼塊。所以在排查“為什么接口里的常量死活不生效”或“接口的static字段為null”這類(lèi)問(wèn)題時(shí)第一反應(yīng)就是去看看類(lèi)加載順序和初始化時(shí)機(jī)是否因?yàn)橐梅绞讲煌a(chǎn)生了差異。這個(gè)一般出現(xiàn)在搞模塊化、自定義ClassLoader、熱部署的場(chǎng)景。平時(shí)寫(xiě)業(yè)務(wù)估計(jì)感覺(jué)不到但面試和排查疑難雜癥時(shí)這是拉開(kāi)差距的知識(shí)點(diǎn)。第六個(gè)問(wèn)題IDE里怎么快速查一個(gè)import的類(lèi)到底是從哪個(gè)依賴包來(lái)的這個(gè)看似和接口類(lèi)區(qū)別沒(méi)關(guān)系但實(shí)際干活時(shí)天天用到。比如項(xiàng)目里有兩個(gè)jar包都定義了UserService接口你的import com.xxx.UserService到底引的是誰(shuí)在IDEA里直接按CtrlN或輸入類(lèi)名后CtrlAlt組合鍵看彈出框能全局搜類(lèi)但要看類(lèi)的來(lái)源最直接的方法是光標(biāo)點(diǎn)在那個(gè)import上按F4跳到定義處右側(cè)Project面板會(huì)自動(dòng)顯示當(dāng)前類(lèi)所在的jar包位置或者直接看左下角Project標(biāo)簽頁(yè)里的External Libraries。還有一個(gè)快捷鍵是CtrlAltB跳到實(shí)現(xiàn)處用它能確認(rèn)實(shí)現(xiàn)類(lèi)和接口的從屬關(guān)系這在排查“為什么這里注入的實(shí)現(xiàn)不是我以為的那個(gè)”時(shí)特別管用。再補(bǔ)充一個(gè)和“接口冪等性”相關(guān)的點(diǎn)。很多人在設(shè)計(jì)接口這里就指HTTP API了的時(shí)候把冪等性理解成“后端做個(gè)去重表”。其實(shí)接口HTTP冪等性和你代碼里的接口/類(lèi)的設(shè)計(jì)也有呼應(yīng)。HTTP接口本質(zhì)也是“契約”說(shuō)好這個(gè)接口是冪等的那它就是冪等的不管調(diào)用方重試多少次服務(wù)端都應(yīng)該保證業(yè)務(wù)結(jié)果一致。這和Java接口的設(shè)計(jì)理念一樣契約說(shuō)出去的話實(shí)現(xiàn)類(lèi)必須無(wú)條件遵守。所以一個(gè)實(shí)現(xiàn)類(lèi)里如果沒(méi)實(shí)現(xiàn)好冪等那不是HTTP的問(wèn)題是你把“契約”簽壞了。凡是寫(xiě)對(duì)外API必須在接口設(shè)計(jì)文檔里寫(xiě)明冪等語(yǔ)義而不是指望調(diào)用方講武德。7. 現(xiàn)代工具鏈上的工程實(shí)踐聊完語(yǔ)法和設(shè)計(jì)再補(bǔ)一段現(xiàn)代工程里接口和類(lèi)的真實(shí)應(yīng)用場(chǎng)景特別是接口配置、接口文檔、接口測(cè)試這類(lèi)“接口”的另一個(gè)維度。熱詞里有個(gè)“多源倉(cāng)庫(kù)接口配置”很多人可能一臉懵感覺(jué)像是某種神秘功能。其實(shí)它就是很常見(jiàn)的“配置驅(qū)動(dòng)”模式原來(lái)你的代碼里硬編碼了調(diào)用哪個(gè)數(shù)據(jù)源、哪個(gè)倉(cāng)庫(kù)地址現(xiàn)在把這些東西抽出來(lái)通過(guò)外部配置文件動(dòng)態(tài)指定。這個(gè)“接口”不是Java的interface更像是一個(gè)“配置條目”它是系統(tǒng)對(duì)外暴露的接入點(diǎn)。這種模式對(duì)接口和類(lèi)的設(shè)計(jì)啟示在于接口不僅是代碼層面的關(guān)鍵字更是系統(tǒng)層面的“對(duì)外協(xié)議”。比如你做數(shù)據(jù)聚合要對(duì)接多個(gè)外部API源每個(gè)源的數(shù)據(jù)格式、認(rèn)證方式、限流策略都不一樣。你可以為每個(gè)API源寫(xiě)一個(gè)實(shí)現(xiàn)類(lèi)然后通過(guò)配置文件把“哪個(gè)源用哪個(gè)實(shí)現(xiàn)類(lèi)”映射起來(lái)。Java里可以用SPIService Provider Interface機(jī)制或者干脆用Spring的配置文件策略注入讓接口在運(yùn)行時(shí)動(dòng)態(tài)綁定到指定實(shí)現(xiàn)。這樣操作的一個(gè)好處是以后要接入一個(gè)新的數(shù)據(jù)源不用改主流程代碼部署完新實(shí)現(xiàn)的jar包或者僅僅是調(diào)整配置系統(tǒng)就能自動(dòng)感知新源。這就是把“類(lèi)”作為實(shí)現(xiàn)單元把“接口”作為集成單元的理想形態(tài)。我做數(shù)據(jù)中臺(tái)的時(shí)候這套配置驅(qū)動(dòng)方式救了不少急改配置而不重新發(fā)版的能力在線上問(wèn)題處理時(shí)實(shí)在太珍貴了。接口文檔也是一樣。你現(xiàn)在寫(xiě)好接口定義后續(xù)的實(shí)現(xiàn)類(lèi)都是“履約”。所以對(duì)工程團(tuán)隊(duì)來(lái)說(shuō)文檔先行、接口先行遠(yuǎn)比代碼先行靠譜。我用過(guò)的做法是先定義好接口類(lèi)和DTO數(shù)據(jù)傳輸對(duì)象寫(xiě)清楚每個(gè)接口的入?yún)?、出參、異常語(yǔ)義甚至直接用OpenAPI注解把接口描述掛上去然后讓不同人并行去寫(xiě)實(shí)現(xiàn)類(lèi)。這樣團(tuán)隊(duì)協(xié)作時(shí)大家對(duì)“契約”的理解是一致的不會(huì)出現(xiàn)A寫(xiě)的實(shí)現(xiàn)期望傳入的是userIdB寫(xiě)的調(diào)用方傳的是用戶對(duì)象這種雞同鴨講的情況。這也從工程管理的角度印證了接口和類(lèi)的關(guān)系接口在協(xié)作流程里就是大家共同對(duì)齊的“合同”。日志也是一個(gè)被忽略的視角。很多團(tuán)隊(duì)的日志打印得亂七八糟其中一個(gè)原因就是用接口還是用類(lèi)導(dǎo)致了日志歸屬混亂。如果你在接口類(lèi)里通過(guò)LoggerFactory.getLogger(this.getClass())來(lái)取日志那么日志會(huì)正確落到具體實(shí)現(xiàn)類(lèi)的名字上排查問(wèn)題的時(shí)候非常有幫助。反過(guò)來(lái)如果你在某一個(gè)工具類(lèi)里硬編碼了日志名那所有走這個(gè)工具類(lèi)的日志都會(huì)混在一起。所以接口和類(lèi)在工程落地時(shí)連日志這種細(xì)枝末節(jié)都會(huì)影響可維護(hù)性。我自己的習(xí)慣是不要在接口里定義靜態(tài)日志那沒(méi)有意義日志Logger一律放在具體類(lèi)中且用this.getClass()動(dòng)態(tài)獲取保證日志歸屬永遠(yuǎn)清晰。8. 經(jīng)驗(yàn)總結(jié)與小技巧寫(xiě)到這里也差不多了。把最核心的幾件事用最簡(jiǎn)單的話收個(gè)尾。實(shí)際開(kāi)發(fā)中我內(nèi)心始終帶著這樣一條判斷鏈路拿到一個(gè)需求先想“業(yè)務(wù)里有沒(méi)有多個(gè)實(shí)現(xiàn)要隨時(shí)切換、有沒(méi)有跨系統(tǒng)的協(xié)作點(diǎn)”如果有那就先定義接口再想“這幾個(gè)類(lèi)有沒(méi)有公共字段和公共邏輯可以沉淀到基類(lèi)”如果有那就在抽象類(lèi)或普通基類(lèi)里做沉淀最后才輪到普通類(lèi)的具體業(yè)務(wù)邏輯落地。順序反了寫(xiě)著寫(xiě)著就擰巴了。一個(gè)小技巧送給大家寫(xiě)完一個(gè)接口或者類(lèi)之后退一步看一眼它的名字。接口的名字應(yīng)該像形容詞可飛的、可序列化的、可登錄的類(lèi)的名字應(yīng)該像名詞微信登錄服務(wù)、數(shù)據(jù)庫(kù)連接池、訂單實(shí)體。如果你的接口叫LoginServiceImpl那你肯定是在用類(lèi)思維寫(xiě)接口。如果你的類(lèi)叫SomeAbility那你可能是在用接口思維寫(xiě)類(lèi)。這個(gè)判斷方法我從沒(méi)失手過(guò)。還有一個(gè)我經(jīng)常安利給新同事的快速審查法把接口的所有方法都改成“返回void”然后看看調(diào)用方還怎么用。如果調(diào)用方一下子就不知道怎么組織代碼了說(shuō)明接口的方法設(shè)計(jì)得偏底層、偏細(xì)節(jié)顆粒度不對(duì)如果調(diào)用方依然能順暢地編排業(yè)務(wù)流程說(shuō)明接口確實(shí)暴露的都是業(yè)務(wù)動(dòng)作。這個(gè)方法簡(jiǎn)單粗暴但特別見(jiàn)效果適合在做code review的時(shí)候快速捉妖。最后再多提一嘴接口和類(lèi)并不是互相對(duì)立的存在它們是面向?qū)ο笤O(shè)計(jì)的一體兩面。真正的高手不會(huì)為了用接口而用接口也不會(huì)鄙視接口、覺(jué)得都是多余的。他們只是很清楚系統(tǒng)里哪些位置需要穩(wěn)定的契約哪些位置需要靈活的實(shí)體。想清楚了這個(gè)接口和類(lèi)的區(qū)別自然就不需要背了因?yàn)槟阋呀?jīng)知道在代碼里它倆各該站在哪里了。