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