1. 一次改一個(gè)方法炸一片調(diào)用方的重構(gòu)現(xiàn)場(chǎng)這事發(fā)生在我前司一個(gè)中臺(tái)服務(wù)里印象特別深。當(dāng)時(shí)有個(gè)OrderService接口里面塞了二十多個(gè)方法從創(chuàng)建訂單、取消訂單、支付、退款到查詢(xún)明細(xì)、導(dǎo)出報(bào)表再到運(yùn)營(yíng)后臺(tái)的審核、風(fēng)控標(biāo)記全在一個(gè)接口里。我們十幾個(gè)團(tuán)隊(duì)各自截取自己需要的部分在調(diào)用看起來(lái)共享接口很規(guī)范直到有人改了其中一個(gè)方法的簽名。那個(gè)方法叫queryOrderItems(Long orderId)本來(lái)只給訂單詳情頁(yè)用。改的人想給它加一個(gè)分頁(yè)參數(shù)于是把簽名改成了queryOrderItems(Long orderId, int page, int size)。結(jié)果一編譯全公司三十多處調(diào)用同時(shí)報(bào)錯(cuò)因?yàn)樗幸蕾?lài)OrderService的代碼都直接看到了這個(gè)變化。其中至少七八處只是拿這個(gè)接口做依賴(lài)注入實(shí)際上根本沒(méi)用過(guò)queryOrderItems。他們被迫跟著改或者臨時(shí)包一層適配。這就是接口隔離原則Interface Segregation PrincipleISP要解決的問(wèn)題。它說(shuō)得很直白客戶(hù)端不應(yīng)該被迫依賴(lài)它不使用的方法。當(dāng)年Robert C. Martin提出這一條的時(shí)候針對(duì)的是胖接口帶來(lái)的耦合放到今天反而更值得重視——我們有了Spring Boot、微服務(wù)、各種RPC框架接口的粒度直接決定了改一個(gè)東西要不要拉動(dòng)一群人開(kāi)會(huì)。如果你正在學(xué)Java設(shè)計(jì)模式或者準(zhǔn)備設(shè)計(jì)模式期末考試這條原則很多人會(huì)背定義但真正理解它為什么存在、什么時(shí)候該下手拆、拆到什么程度為止才是筆試和面試?yán)锢_(kāi)差距的地方。這篇文章我把自己的踩坑經(jīng)歷、拆分過(guò)程和判斷標(biāo)準(zhǔn)完整寫(xiě)出來(lái)按我的習(xí)慣先講事故再講原理最后給能直接抄的實(shí)踐。1.1 事故背后的代碼結(jié)構(gòu)當(dāng)時(shí)那個(gè)OrderService大概長(zhǎng)這樣public interface OrderService { void createOrder(Order order); void cancelOrder(Long orderId); void payOrder(Long orderId, PaymentMethod method); void refundOrder(Long orderId); ListOrderItem queryOrderItems(Long orderId); void exportOrders(ExportRequest request); void auditOrder(Long orderId); void markFraudOrder(Long orderId); }注意看這里payOrder和auditOrder完全不是一種性質(zhì)的方法。前者是C端用戶(hù)在交易鏈路里的核心動(dòng)作每秒可能幾百次調(diào)用后者是運(yùn)營(yíng)在后臺(tái)偶爾點(diǎn)擊的管理操作一天調(diào)用幾十次。它們的變化頻率不同、調(diào)用方不同、出問(wèn)題的影響面也不同卻因?yàn)槎己陀唵斡嘘P(guān)被塞進(jìn)了同一個(gè)接口。網(wǎng)上搜接口隔離原則的時(shí)候最常見(jiàn)的描述是用多個(gè)專(zhuān)門(mén)的接口優(yōu)于一個(gè)臃腫的總接口這句話(huà)沒(méi)錯(cuò)但光記住這句話(huà)沒(méi)用。你得能識(shí)別出哪些方法屬于同一種變化哪些方法只是碰巧屬于同一個(gè)業(yè)務(wù)領(lǐng)域。前者應(yīng)該放一起后者應(yīng)該拆開(kāi)。1.2 為什么大家一起改會(huì)變成災(zāi)難回到那次事故。讓我把事情說(shuō)得更細(xì)改方法的人只通知了自己團(tuán)隊(duì)因?yàn)樗X(jué)得我就改一個(gè)查詢(xún)方法跟別人有什么關(guān)系。但Java接口的編譯期強(qiáng)約束讓所有引用它的類(lèi)都暴露了。你以為是局部修改編譯器告訴你這是全量修改。這種問(wèn)題在動(dòng)態(tài)語(yǔ)言里不一定會(huì)暴露但在強(qiáng)類(lèi)型語(yǔ)言里會(huì)被放大。所以你會(huì)發(fā)現(xiàn)接口隔離原則在Java生態(tài)里討論得特別多因?yàn)檎Z(yǔ)言特性決定了接口一旦變更所有依賴(lài)方都要感知。你沒(méi)法裝作沒(méi)看見(jiàn)。更深層的問(wèn)題是這種大接口會(huì)讓團(tuán)隊(duì)失去安全修改的勇氣。后來(lái)我們統(tǒng)計(jì)了一下導(dǎo)致那次重構(gòu)的原因很簡(jiǎn)單詳情頁(yè)的數(shù)據(jù)量漲了不分頁(yè)不行。可就是這樣一個(gè)合理的需求因?yàn)榻涌谠O(shè)計(jì)不合理演變成了跨團(tuán)隊(duì)協(xié)同問(wèn)題。我用一句話(huà)總結(jié)當(dāng)時(shí)的局面接口越大改接口的顧慮就越多顧慮越多大家就越傾向于不打理接口結(jié)果接口越來(lái)越大。這是個(gè)惡性循環(huán)。2. 接口隔離原則到底在隔離什么先糾正三個(gè)常見(jiàn)誤解接口隔離原則的原文是Clients should not be forced to depend on methods they do not use.直譯過(guò)來(lái)就是客戶(hù)端不應(yīng)被迫依賴(lài)它們不使用的方法。這句話(huà)關(guān)鍵在客戶(hù)端三個(gè)字。它不是站在實(shí)現(xiàn)類(lèi)的角度說(shuō)你實(shí)現(xiàn)了很多方法所以你要拆而是站在調(diào)用方的角度說(shuō)你只用到其中兩個(gè)方法我就只讓你看到這兩個(gè)方法。隔離的不是方法而是依賴(lài)關(guān)系。2.1 誤解一接口隔離就是把大接口拆成小接口很多文章只講了一半。拆成小接口只是手段真正的目的是讓不同客戶(hù)端之間的依賴(lài)互不可見(jiàn)。如果只是把二十個(gè)方法拆成五個(gè)接口但所有客戶(hù)端依然注入具體的實(shí)現(xiàn)類(lèi)那隔離效果等于零因?yàn)榭蛻?hù)端還是能看到實(shí)現(xiàn)類(lèi)的全部方法。正確的做法是讓客戶(hù)端面向自己需要的接口編程。什么時(shí)候拆、拆多細(xì)取決于客戶(hù)端有沒(méi)有被迫依賴(lài)它不使用的方法。如果沒(méi)有這種被迫一個(gè)接口里有十個(gè)方法也不算違反ISP。舉個(gè)例子一個(gè)通訊錄工具類(lèi)內(nèi)部封裝了本地存儲(chǔ)和網(wǎng)絡(luò)同步對(duì)外暴露了addContact、deleteContact、syncContacts三個(gè)方法。假設(shè)只有一個(gè)頁(yè)面使用它而且三個(gè)方法都會(huì)用到那它雖然是三個(gè)功能也不違反ISP。反過(guò)來(lái)如果有一個(gè)模塊只做網(wǎng)絡(luò)同步卻被強(qiáng)制看到了本地?cái)?shù)據(jù)庫(kù)的增刪改那就算只有一個(gè)方法也是違反ISP。2.2 誤解二接口隔離就是單一職責(zé)原則這是我在面試?yán)镒畛Ｂ?tīng)到的混淆。單一職責(zé)原則SRP針對(duì)的是類(lèi)和模塊說(shuō)的是一個(gè)類(lèi)應(yīng)該只有一個(gè)引起它變化的原因解決的是內(nèi)聚性問(wèn)題。接口隔離原則針對(duì)的是客戶(hù)端與契約之間的關(guān)系解決的是耦合性問(wèn)題。兩者有關(guān)系但不完全是一回事。一個(gè)類(lèi)可能已經(jīng)符合SRP內(nèi)部只處理訂單金額計(jì)算但它暴露的接口可能非常寬——比如把金額計(jì)算、日志、緩存全部塞在一個(gè)接口方法里反過(guò)來(lái)一個(gè)類(lèi)可能同時(shí)干了訂單校驗(yàn)和庫(kù)存扣減兩件事不太符合SRP但它對(duì)客戶(hù)端暴露的是兩個(gè)小接口客戶(hù)端按需依賴(lài)這在ISP層面是達(dá)標(biāo)的。更準(zhǔn)確地說(shuō)SRP關(guān)注的是為什么這個(gè)類(lèi)會(huì)變ISP關(guān)注的是客戶(hù)端看到了什么。2.3 誤解三接口隔離只針對(duì)Java的interface關(guān)鍵字接口隔離里面的接口指的是任何形式的調(diào)用契約不只是Java里的interface。一個(gè)開(kāi)放給前端調(diào)用的REST API路徑集合是一種接口一個(gè)Spring的Service類(lèi)對(duì)外公開(kāi)的public方法是一種接口一個(gè)消息隊(duì)列里的Topic及消息結(jié)構(gòu)也可以理解為一種接口。接口隔離的核心思想是你對(duì)外暴露的能力應(yīng)該是按使用場(chǎng)景分組而不是按內(nèi)部實(shí)現(xiàn)分組。這一點(diǎn)在微服務(wù)架構(gòu)里尤其明顯。很多人做微服務(wù)拆分時(shí)按數(shù)據(jù)庫(kù)表來(lái)切服務(wù)訂單庫(kù)就拆出訂單服務(wù)用戶(hù)庫(kù)里就拆出用戶(hù)服務(wù)。結(jié)果訂單服務(wù)暴露出來(lái)的接口五花八門(mén)既有C端查詢(xún)又有后臺(tái)審核還有定時(shí)任務(wù)用到的批量掃描。這就是把接口隔離這個(gè)理念忘到了腦后——服務(wù)邊界是有了但契約粒度仍然混亂。3. 用訂單系統(tǒng)做一次完整拆分從胖接口到按調(diào)用方劃分的獨(dú)立契約光講理論沒(méi)意思我把前面提到的訂單系統(tǒng)完整拆一遍。你把這個(gè)過(guò)程跑通比看十篇定義都管用。3.1 原始設(shè)計(jì)到底問(wèn)題出在哪假設(shè)訂單系統(tǒng)的使用方主要有四類(lèi)C端交易鏈路下單、支付、退款、查訂單運(yùn)營(yíng)后臺(tái)審核異常訂單、導(dǎo)出報(bào)表數(shù)據(jù)同步任務(wù)批量拉取訂單定時(shí)同步到數(shù)據(jù)倉(cāng)庫(kù)客服工作臺(tái)查詢(xún)訂單狀態(tài)、修改備注原始設(shè)計(jì)把所有這些都放進(jìn)了OrderService?，F(xiàn)在我要做接口隔離不是直接把OrderService按訂單、支付、審核這種業(yè)務(wù)切片來(lái)拆而是先問(wèn)一個(gè)問(wèn)題哪幾組方法的調(diào)用方集合高度重疊而且變化頻率接近答案很明顯。C端用戶(hù)永遠(yuǎn)不會(huì)調(diào)auditOrder運(yùn)營(yíng)后臺(tái)不應(yīng)該觸發(fā)payOrder數(shù)據(jù)同步任務(wù)只需要批量查詢(xún)而完全不需要任何寫(xiě)操作。所以按照調(diào)用方來(lái)分至少可以拆成四組。3.2 拆分按調(diào)用方依賴(lài)的最小集合切分我是這樣拆的public interface OrderWriteService { void createOrder(Order order); void cancelOrder(Long orderId); } public interface OrderPaymentService { void payOrder(Long orderId, PaymentMethod method); void refundOrder(Long orderId); } public interface OrderQueryService { OrderDetailVO getOrderDetail(Long orderId); ListOrderItem queryOrderItems(Long orderId, int page, int size); void exportOrders(ExportRequest request); } public interface OrderAdminService { void auditOrder(Long orderId, AuditDecision decision); void markFraudOrder(Long orderId); }然后具體的訂單服務(wù)實(shí)現(xiàn)類(lèi)依然可以一個(gè)類(lèi)頂四個(gè)接口Service public class OrderServiceImpl implements OrderWriteService, OrderPaymentService, OrderQueryService, OrderAdminService { // 每個(gè)方法的具體實(shí)現(xiàn)不變 }注意這個(gè)細(xì)節(jié)實(shí)現(xiàn)類(lèi)的數(shù)量沒(méi)有發(fā)生變化變的是客戶(hù)端能看到的視角。同樣一個(gè)業(yè)務(wù)對(duì)象在C端控制器里注入的是OrderWriteService和OrderPaymentService在運(yùn)營(yíng)后臺(tái)控制器里注入的是OrderAdminService在數(shù)據(jù)導(dǎo)出模塊里注入的是OrderQueryService。RestController RequestMapping(/api/orders) public class OrderController { private final OrderWriteService orderWriteService; private final OrderPaymentService orderPaymentService; public OrderController(OrderWriteService orderWriteService, OrderPaymentService orderPaymentService) { this.orderWriteService orderWriteService; this.orderPaymentService orderPaymentService; } // 這里只能調(diào)用下單、取消、支付、退款看不到審核和導(dǎo)出方法 }將來(lái)如果有人改了queryOrderItems的分頁(yè)邏輯C端控制器完全無(wú)感因?yàn)樗囊蕾?lài)?yán)锔緵](méi)有OrderQueryService。這就是隔離帶來(lái)的直接效果。3.3 拆分后測(cè)試和Mock發(fā)生了什么變化這個(gè)收益很多人沒(méi)意識(shí)到但實(shí)際價(jià)值非常大。在拆分之前單元測(cè)試?yán)镆猰ock一個(gè)OrderService大概長(zhǎng)這樣OrderService orderService mock(OrderService.class); when(orderService.payOrder(anyLong(), any())).thenReturn(paymentResult);看起來(lái)也沒(méi)啥但你要知道OrderService有二十多個(gè)方法每新增一個(gè)方法所有測(cè)試樁類(lèi)都要跟著適配。尤其在用Mockito做mock()的時(shí)候雖然Mockito不強(qiáng)制實(shí)現(xiàn)所有方法但如果代碼里用了Spring的MockBean并且測(cè)試上下文會(huì)去創(chuàng)建實(shí)現(xiàn)類(lèi)新方法一旦依賴(lài)了未初始化的組件測(cè)試啟動(dòng)就會(huì)爆。拆分之后mock對(duì)象變得非常小OrderPaymentService paymentService mock(OrderPaymentService.class); when(paymentService.payOrder(anyLong(), any())).thenReturn(paymentResult);測(cè)試需要構(gòu)造的前置條件更少理解成本更低新人接手時(shí)能更快搞清楚這個(gè)測(cè)試到底在驗(yàn)證什么。接口越小測(cè)試樁越小測(cè)試樁越小寫(xiě)測(cè)試的意愿就越強(qiáng)。這是接口隔離原則帶來(lái)的一個(gè)很現(xiàn)實(shí)的紅利。4. 接口隔離真正帶來(lái)的三筆收益可控的變更、可驗(yàn)證的行為、可并行的團(tuán)隊(duì)很多人覺(jué)得接口隔離是個(gè)代碼潔癖層面的原則不遵守也不影響系統(tǒng)運(yùn)行。這是大錯(cuò)特錯(cuò)。我在實(shí)際項(xiàng)目里體會(huì)到的收益可以歸納成三筆賬。4.1 變更影響面被鎖死在接口邊界內(nèi)軟件維護(hù)成本的大頭在變更不在初始開(kāi)發(fā)。一個(gè)接口里方法越多涉及的業(yè)務(wù)領(lǐng)域越多它被改動(dòng)的概率就越大改動(dòng)時(shí)波及的范圍也越大。拿我經(jīng)歷過(guò)的一個(gè)例子來(lái)說(shuō)。有一次產(chǎn)品要求給訂單詳情頁(yè)加一個(gè)預(yù)計(jì)送達(dá)時(shí)間這本身只涉及查詢(xún)鏈路。由于我們把OrderQueryService單獨(dú)拆了出來(lái)后端只需要在OrderQueryService和對(duì)應(yīng)實(shí)現(xiàn)類(lèi)里動(dòng)刀C端控制器的依賴(lài)注入都不需要改。部署的時(shí)候我只需要確認(rèn)查詢(xún)服務(wù)兼容舊接口其他團(tuán)隊(duì)完全不用跟著發(fā)版。如果你把這一點(diǎn)放到微服務(wù)之間就更能體會(huì)了服務(wù)A給服務(wù)B提供的接口如果是一個(gè)大而全的訂單服務(wù)接口B只是在用其中兩個(gè)字段但A因?yàn)樽约旱男枨髷U(kuò)展了接口入?yún)⒒蚍祷刂礏就要被迫回歸測(cè)試甚至因?yàn)樾蛄谢兓苯訄?bào)錯(cuò)。這不是技術(shù)問(wèn)題是契約設(shè)計(jì)問(wèn)題。4.2 mock、stub變小帶來(lái)測(cè)試意愿提升第二筆收益是測(cè)試體驗(yàn)。在大型項(xiàng)目里測(cè)試代碼的維護(hù)成本有時(shí)候比業(yè)務(wù)代碼還高。胖接口會(huì)導(dǎo)致兩個(gè)典型問(wèn)題一是mock配置特別長(zhǎng)。因?yàn)榻涌诜椒ㄌ嗄銥榱俗咄ㄒ粭l測(cè)試路徑要when掉很多你不關(guān)心的方法否則某些分支會(huì)把調(diào)用打到null對(duì)象上。二是測(cè)試意圖模糊。一個(gè)測(cè)試?yán)锿瑫r(shí)出現(xiàn)了payOrder、exportOrders、auditOrder的mock讀測(cè)試代碼的人會(huì)疑惑我到底在測(cè)什么模塊按調(diào)用方拆小接口后每個(gè)測(cè)試的依賴(lài)面變得非常聚焦。我的習(xí)慣是如果一個(gè)測(cè)試需要mock超過(guò)三個(gè)方法就會(huì)懷疑被測(cè)單元的依賴(lài)設(shè)計(jì)是不是太粗了。接口隔離做得好這個(gè)數(shù)字通常不會(huì)失控。4.3 團(tuán)隊(duì)間耦合降低發(fā)布節(jié)奏不再互相拖累第三筆收益最容易被忽略但長(zhǎng)期價(jià)值最大。大接口意味著大團(tuán)隊(duì)的共享邊界。多人同時(shí)在一個(gè)接口上修改合并沖突只是表面現(xiàn)象真正的痛點(diǎn)是互相等待——A團(tuán)隊(duì)要加一個(gè)方法得跟B團(tuán)隊(duì)商量會(huì)不會(huì)影響他們的實(shí)現(xiàn)B團(tuán)隊(duì)不敢隨便重構(gòu)因?yàn)椴恢繡團(tuán)隊(duì)依賴(lài)了哪個(gè)方法。UI設(shè)計(jì)里有個(gè)詞叫認(rèn)知負(fù)荷同樣適用于接口設(shè)計(jì)。一個(gè)調(diào)用方必須理解二十個(gè)方法才能正確使用其中一個(gè)這個(gè)接口就是在給團(tuán)隊(duì)增加認(rèn)知負(fù)荷。拆分之后新成員接手某個(gè)模塊時(shí)只需要閱讀他關(guān)心的那個(gè)小接口學(xué)習(xí)成本直接砍掉一半以上。5. 別把隔離做成碎片化什么時(shí)候不該拆以及怎么判斷接口隔離原則講得太多會(huì)有人走向另一個(gè)極端一個(gè)方法一個(gè)接口到處是三五行的細(xì)碎接口調(diào)用方為了完成一個(gè)業(yè)務(wù)流程要注入五六個(gè)依賴(lài)。這不是隔離這是碎片化。5.1 接口碎片化的典型癥狀碎片化的接口長(zhǎng)什么樣我在代碼評(píng)審里見(jiàn)過(guò)這樣的設(shè)計(jì)public interface OrderCreator { void createOrder(Order order); } public interface OrderCanceller { void cancelOrder(Long orderId); } public interface OrderPayer { void payOrder(Long orderId, PaymentMethod method); } public interface OrderRefunder { void refundOrder(Long orderId); }然后每個(gè)調(diào)用方都要注入四個(gè)接口public class OrderFacade { private final OrderCreator creator; private final OrderCanceller canceller; private final OrderPayer payer; private final OrderRefunder refunder; // 構(gòu)造函數(shù)注入四個(gè)依賴(lài) }你發(fā)現(xiàn)問(wèn)題了嗎OrderFacade雖然注入了四個(gè)小接口但它依然是一個(gè)同時(shí)依賴(lài)下單、取消、支付、退款的客戶(hù)端。拆分接口并沒(méi)有消除它的寬依賴(lài)只是把一個(gè)大接口換成了四個(gè)小接口的排列組合。從依賴(lài)數(shù)量來(lái)說(shuō)甚至更差了。所以判斷接口隔離做得好不好不是看接口數(shù)量多了還是少了而是看每個(gè)客戶(hù)端的依賴(lài)是否剛好等于它需要的最小集合。如果拆分之后客戶(hù)端還是需要把多個(gè)接口組裝起來(lái)才能干活那就要考慮是不是該用一個(gè)聚合接口。5.2 判斷該不該拆的四條標(biāo)準(zhǔn)我總結(jié)了自己的四條判斷標(biāo)準(zhǔn)基本能覆蓋日常開(kāi)發(fā)里大部分情況第一有沒(méi)有實(shí)現(xiàn)類(lèi)被迫拋異常。如果存在UnsupportedOperationException或者某個(gè)方法返回Collections.emptyList()、null來(lái)應(yīng)付調(diào)用這就是違反ISP的最強(qiáng)信號(hào)。說(shuō)明接口里混入了一部分特定實(shí)現(xiàn)類(lèi)用不到的能力。第二方法的調(diào)用方是否有明顯分組。你把接口里的方法列出來(lái)給每個(gè)方法標(biāo)注它的調(diào)用方。如果出現(xiàn)好幾組調(diào)用方完全不相交的情況說(shuō)明接口應(yīng)該拆。注意這里說(shuō)的是完全不相交如果兩個(gè)接口的調(diào)用方高度重疊拆了反而增加復(fù)雜度。第三方法的變化頻率是否一致。接口里有些方法一年都不變有些方法一個(gè)月改三次這兩類(lèi)方法放在一起會(huì)讓雙方都難受。穩(wěn)定方法會(huì)因?yàn)椴环€(wěn)定方法的變動(dòng)而被重新評(píng)估不穩(wěn)定方法又會(huì)被穩(wěn)定方法的兼容性要求拖住。變化頻率不同的方法應(yīng)該進(jìn)入不同的接口。第四外部是否真的需要看到它。有的方法只是內(nèi)部實(shí)現(xiàn)細(xì)節(jié)比如狀態(tài)流轉(zhuǎn)的中間步驟、緩存刷新的輔助方法壓根不應(yīng)該出現(xiàn)在對(duì)外接口里。這種情況不是拆分接口而是直接把它們降為private或包內(nèi)方法。5.3 替代方案適配器、默認(rèn)方法、分層接口如果暫時(shí)沒(méi)有權(quán)限大改接口或者歷史包袱太重有幾個(gè)過(guò)渡方案可以用。適配器模式是拆接口的平替。當(dāng)調(diào)用方只能使用一個(gè)窄接口的方法但底層實(shí)現(xiàn)是胖接口時(shí)可以寫(xiě)一個(gè)適配器把窄需求映射到胖實(shí)現(xiàn)上。這種方式不改造底層但能讓新代碼先依賴(lài)干凈的小接口。Java接口的default方法也可以用來(lái)平滑過(guò)渡。你想在胖接口里加一個(gè)新的業(yè)務(wù)能力但不想讓現(xiàn)有實(shí)現(xiàn)類(lèi)全部實(shí)現(xiàn)可以給這個(gè)方法提供默認(rèn)實(shí)現(xiàn)甚至默認(rèn)實(shí)現(xiàn)直接拋異常等需要的實(shí)現(xiàn)類(lèi)去覆蓋。這算是一種先占位、后拆分的策略但要注意別把default方法用成常態(tài)否則接口會(huì)越來(lái)越膨脹。分層接口是我個(gè)人比較喜歡的一種做法。定義一層基礎(chǔ)接口里面只放真正通用的方法再定義面向不同場(chǎng)景的擴(kuò)展接口。比如public interface OrderBaseService { Order getOrderById(Long orderId); } public interface OrderPaymentService extends OrderBaseService { void payOrder(Long orderId, PaymentMethod method); void refundOrder(Long orderId); } public interface OrderAdminService extends OrderBaseService { void auditOrder(Long orderId, AuditDecision decision); void markFraudOrder(Long orderId); }這樣公共的讀方法只維護(hù)一份不同客戶(hù)端通過(guò)繼承各自的小接口獲得能力也是個(gè)典型的平衡方案。6. 在團(tuán)隊(duì)里落地接口隔離原則的三條實(shí)戰(zhàn)建議最后說(shuō)點(diǎn)能直接帶進(jìn)團(tuán)隊(duì)的東西。如果你認(rèn)可這個(gè)原則但不知道從哪下手這三條是我實(shí)踐下來(lái)最有效的路徑。6.1 讓接口從調(diào)用方長(zhǎng)出來(lái)而不是從實(shí)現(xiàn)類(lèi)推出來(lái)大部分違反ISP的接口是怎么產(chǎn)生的通常是這樣程序員先寫(xiě)了一個(gè)OrderServiceImpl發(fā)現(xiàn)方法挺多然后右鍵Refactor把它抽成了一個(gè)OrderService接口。這種做法是從實(shí)現(xiàn)類(lèi)推導(dǎo)接口結(jié)果必然是接口跟實(shí)現(xiàn)類(lèi)一樣胖。正確的思路應(yīng)該是反過(guò)來(lái)先有調(diào)用方的需求再有接口。你寫(xiě)C端控制器的時(shí)候發(fā)現(xiàn)自己需要一個(gè)支付訂單的能力于是定義一個(gè)OrderPaymentService接口只包含payOrder然后讓實(shí)現(xiàn)類(lèi)實(shí)現(xiàn)它。第二個(gè)調(diào)用方需要審核訂單于是定義OrderAdminService接口再讓同一個(gè)實(shí)現(xiàn)類(lèi)實(shí)現(xiàn)它。接口的粒度是由外部需求決定的不是由內(nèi)部實(shí)現(xiàn)決定的。這個(gè)順序看起來(lái)只是思考方式的差異實(shí)際效果天差地別。從需求出發(fā)的接口天然就是按調(diào)用方分組的。6.2 評(píng)審時(shí)重點(diǎn)盯三類(lèi)信號(hào)代碼評(píng)審是最容易落地接口隔離原則的地方。我每次看到新的接口或者大接口改動(dòng)會(huì)重點(diǎn)看三類(lèi)信號(hào)第一接口方法數(shù)量。不是說(shuō)超過(guò)十個(gè)就一定不行但如果一個(gè)接口方法非常多我會(huì)本能地問(wèn)一句這個(gè)接口的調(diào)用方真的都需要這些方法嗎如果回答不上來(lái)往往說(shuō)明接口已經(jīng)膨脹了。第二實(shí)現(xiàn)類(lèi)里有沒(méi)有空實(shí)現(xiàn)或異常實(shí)現(xiàn)?？吹絫hrow new UnsupportedOperationException()我會(huì)立刻想到接口隔離而不是包容它。同樣的看到某個(gè)方法直接return null;也會(huì)去追究是不是接口設(shè)計(jì)的問(wèn)題。第三依賴(lài)注入的字段數(shù)量。如果一個(gè)類(lèi)注入了超過(guò)四五個(gè)不同的Service我會(huì)懷疑它的職責(zé)是否過(guò)重同時(shí)也會(huì)看這些Service是不是被拆得太碎了導(dǎo)致本來(lái)一個(gè)接口能表達(dá)的場(chǎng)景被拆成了拼圖。這三類(lèi)信號(hào)不需要任何工具人肉就能識(shí)別門(mén)檻很低效果很好。6.3 演進(jìn)式拆分不要一次到位跟著變化拆最后一條建議是心態(tài)層面的。你不必為了遵守設(shè)計(jì)模式而一次性把所有大接口全部拆完。過(guò)度追求設(shè)計(jì)完美往往會(huì)在接口還沒(méi)穩(wěn)定的時(shí)候就把結(jié)構(gòu)搞復(fù)雜。我的做法是跟著變化拆當(dāng)某個(gè)胖接口因?yàn)樾略鲂枨蠹磳⒈桓膭?dòng)時(shí)趁這個(gè)機(jī)會(huì)把與改動(dòng)點(diǎn)無(wú)關(guān)的方法剝離出去當(dāng)某個(gè)實(shí)現(xiàn)類(lèi)開(kāi)始寫(xiě)UnsupportedOperationException時(shí)把它逼到不得不拋異常的方法拆到另一個(gè)接口里當(dāng)某個(gè)調(diào)用方為了一個(gè)方法不得不升級(jí)依賴(lài)時(shí)重建一個(gè)只屬于它的窄接口。一年下來(lái)你會(huì)發(fā)現(xiàn)系統(tǒng)的接口結(jié)構(gòu)會(huì)自動(dòng)趨向合理而且不會(huì)有那種整建制重構(gòu)的陣痛期。我見(jiàn)過(guò)太多團(tuán)隊(duì)想一步到位重構(gòu)系統(tǒng)結(jié)果重構(gòu)期間業(yè)務(wù)需求不斷涌入改造被迫中斷最后接口比以前更亂。演進(jìn)式拆分雖然慢但每一步都是在真實(shí)需求驅(qū)動(dòng)下進(jìn)行的做出來(lái)的接口更經(jīng)得起考驗(yàn)。接口隔離原則和其他SOLID原則一樣都不是考場(chǎng)上的填空題而是在每一次需求變更、每一次代碼評(píng)審、每一次接口設(shè)計(jì)里反復(fù)驗(yàn)證出來(lái)的判斷力。我自己在實(shí)際項(xiàng)目里體會(huì)最深的一點(diǎn)是它不能讓你寫(xiě)出更炫酷的代碼但能讓你在三個(gè)月后、半年后、甚至換了一波同事之后依然有底氣地改某一個(gè)接口而不擔(dān)心半夜被線(xiàn)上告警叫醒。這種安全感值得你為它多花一點(diǎn)設(shè)計(jì)時(shí)間。