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