如果這是第二次看到我的文章，歡迎文末掃碼訂閱我個(gè)人的公眾號(hào)（跨界架構(gòu)師）喲~  

創(chuàng)新互聯(lián)建站專業(yè)提供西信服務(wù)器托管服務(wù)，為用戶提供五星數(shù)據(jù)中心、電信、雙線接入解決方案，用戶可自行在線購(gòu)買西信服務(wù)器托管服務(wù)，并享受7*24小時(shí)金牌售后服務(wù)。

本文長(zhǎng)度為3012字，建議閱讀8分鐘。

堅(jiān)持原創(chuàng)，每一篇都是用心之作～

下面的這個(gè)場(chǎng)景你可能會(huì)覺(jué)得很熟悉（Z哥我又要出演了）：

Z哥：@All 兄弟姐妹們，這次我這邊有個(gè)需求需要給「商品上架」增加一道審核，會(huì)影響到大家和我交互的接口。大家抽空配合改一下，明天一起更新個(gè)版本。

 

小Y：哥，我這幾天很忙啊，昨天剛配合老王改過(guò)促銷！

 

小X：行～當(dāng)一切已成習(xí)慣。

作為被通知人，如果在你的現(xiàn)實(shí)工作中也發(fā)生了類似事件，我相信哪怕嘴上不說(shuō)，心里也會(huì)有不少想法和抱怨：“md，改的是你，我也要發(fā)布，好冤??！”。

這個(gè)問(wèn)題的根本原因就是多個(gè)項(xiàng)目之間的耦合度過(guò)于嚴(yán)重。

越大型的項(xiàng)目越容易陷入到這個(gè)昭潭中，難以自拔。

而解決問(wèn)題的方式就是進(jìn)行更合理的分層，并且持續(xù)保證分層的合理性。

一提到分層，必然離不開6個(gè)字「高內(nèi)聚」和「低耦合」。

什么是高內(nèi)聚低耦合

在z哥之前的文章中有多次提到，分布式系統(tǒng)的本質(zhì)就是「分治」和「冗余」。

其中，分治就是“分解 -> 治理 -> 歸并”的三部曲。「高內(nèi)聚」、「低耦合」的概念就來(lái)源于此。

需要注意的是，當(dāng)你在做「分解」這個(gè)操作的時(shí)候，務(wù)必要關(guān)注每一次的「分解」是否滿足一個(gè)最重要的條件：不同分支上的子問(wèn)題，不能相互依賴，需要各自獨(dú)立。

因?yàn)橐坏┌艘蕾囮P(guān)系，子問(wèn)題和父問(wèn)題之間就失去了可以被「歸并」的意義。

比如，一個(gè)「問(wèn)題Z」被分解成了兩個(gè)子問(wèn)題，「子問(wèn)題A」和「子問(wèn)題B」。但是，解問(wèn)題A依賴于問(wèn)題B的答案，解問(wèn)題B又依賴于問(wèn)題A的答案。這不就等于沒(méi)有分解嗎？

題外話：這里的“如何更合理的分解問(wèn)題”這個(gè)思路也可以用到你的生活和工作中的任何問(wèn)題上。

所以，當(dāng)你在做「分解」的時(shí)候，需要有一些很好的著力點(diǎn)去切入。

這個(gè)著力點(diǎn)就是前面提到的「耦合度」和「內(nèi)聚度」，兩者是一個(gè)此消彼長(zhǎng)的關(guān)系。

越符合高內(nèi)聚低耦合這個(gè)標(biāo)準(zhǔn)，程序的維護(hù)成本就越低。為什么呢？因?yàn)橐蕾囋叫?，各自的變更?duì)其他關(guān)聯(lián)方的影響就越小。

所以，「高內(nèi)聚」和「低耦合」是我們應(yīng)當(dāng)持續(xù)不斷追求的目標(biāo)。

題外話：耦合度，指的是軟件模塊之間相互依賴的程度。比如，每次調(diào)用方法 A 之后都需要同步調(diào)用方法 B，那么此時(shí)方法 A 和 B 間的耦合度是高的。

 

內(nèi)聚度，指的是模塊內(nèi)的元素具有的共同點(diǎn)的相似程度。比如，一個(gè)類中的多個(gè)方法有很多的共同之處，都是做支付相關(guān)的處理，那么這個(gè)類的內(nèi)聚度是高的。

怎么做好高內(nèi)聚低耦合

做好高內(nèi)聚低耦合，思路也很簡(jiǎn)單：定職責(zé)、做歸類、劃邊界。

首先，定職責(zé)就是定義每一個(gè)子系統(tǒng)、每一個(gè)模塊、甚至每一個(gè)class和每一個(gè)function的職責(zé)。

比如，在子系統(tǒng)或者模塊層面可以這樣。

又比如，在class或者function層面可以這樣。

我想這點(diǎn)大家平時(shí)都會(huì)有意識(shí)的去做。

做好了職責(zé)定義后，內(nèi)聚性就會(huì)有很大的提升，同時(shí)也提高了代碼/程序的復(fù)用程度。

至此，我們才談得上「單一職責(zé)（SRP）」這種設(shè)計(jì)原則的運(yùn)用。

其次，做歸類。梳理不同模塊之間的依賴關(guān)系。

像上面提到的案例1可以歸類為3層：

1. 基礎(chǔ)層：商品基礎(chǔ)服務(wù)、會(huì)員基礎(chǔ)服務(wù)、促銷基礎(chǔ)服務(wù)

2. 聚合層：購(gòu)物車服務(wù)、商品詳情服務(wù)、登陸服務(wù)

3. 接入層：快閃店API、綜合商城API

案例2也可以歸類為3層：

1. 數(shù)據(jù)訪問(wèn)層：訪問(wèn)會(huì)員表數(shù)據(jù)、訪問(wèn)會(huì)員積分表數(shù)據(jù)、訪問(wèn)會(huì)員等級(jí)表數(shù)據(jù)

2. 業(yè)務(wù)邏輯層：會(huì)員登陸邏輯、會(huì)員使用積分邏輯、會(huì)員升級(jí)邏輯

3. 應(yīng)用層：接收用戶輸入的賬戶密碼、接收用戶輸入的使用積分?jǐn)?shù)、接收用戶的付款信息

最后就是劃邊界。好不容易梳理清楚，為了避免輕易被再次破壞，所以需要設(shè)立好合理清晰的邊界。

否則你想的是這樣整齊。

實(shí)際會(huì)慢慢變成這樣混亂。

那么應(yīng)該怎么劃邊界呢？

class和function級(jí)別。這個(gè)層面可以通過(guò)codereview或者靜態(tài)代碼檢測(cè)工具來(lái)進(jìn)行，可以關(guān)注的點(diǎn)比如：

1. 調(diào)用某些class必須通過(guò)interface而不是implement

2. 訪問(wèn)會(huì)員表數(shù)據(jù)的class中不能存在訪問(wèn)商品數(shù)據(jù)的function

模塊級(jí)別?？梢赃x擇以下方案：

1. 給每一種類型的class分配不同project，打包到各自的dll（jar）中

2. 每次代碼push上來(lái)的時(shí)候檢測(cè)其中的依賴是否有超出規(guī)定的依賴。例如，不能逆向依賴（檢測(cè)dal是否包含bll）；不能在基礎(chǔ)層做聚合業(yè)務(wù)（檢測(cè)商品基礎(chǔ)服務(wù)是否包含其他基礎(chǔ)服務(wù)的dll（jar））。

系統(tǒng)級(jí)別。及時(shí)識(shí)別子系統(tǒng)之間的調(diào)用是否符合預(yù)期，可以通過(guò)接入一個(gè)調(diào)用鏈跟蹤系統(tǒng)（如，zipkin）來(lái)分析請(qǐng)求鏈路是否合法。

讓邊界更清晰、穩(wěn)定的最佳實(shí)踐

很多時(shí)候不同的模塊或者子系統(tǒng)會(huì)被分配到不同的小組中負(fù)責(zé)，所以z哥再分享幾個(gè)最佳實(shí)踐給你。它可以讓系統(tǒng)之間的溝通更穩(wěn)定。

首先是：模塊對(duì)外暴露的接口部分，數(shù)據(jù)類型的選擇上盡量做到寬進(jìn)嚴(yán)出。比如，使用long代替byte之類的數(shù)據(jù)類型；使用弱類型代替強(qiáng)類型等等。

舉個(gè)「寬進(jìn)嚴(yán)出」的例子：

//使用long代替byte之類的數(shù)據(jù)類型。

void Add(long param1, long param2){

    if(param1 <1000&& param2 < 1000){  //先接收進(jìn)來(lái)，到里面再做邏輯校驗(yàn)。

        //do something...

    }

    else{

        //do something...

    }

}

其次是：寫操作接口，接收參數(shù)盡可能少；讀操作接口，返回參數(shù)盡可能多。

為什么呢？因?yàn)楹芏鄷r(shí)候，寫操作的背后會(huì)存在一個(gè)潛在預(yù)期，是「準(zhǔn)確」。

準(zhǔn)確度和可信度有著很大的聯(lián)系，只有更多的邏輯處理在自己掌控范圍內(nèi)進(jìn)行才能越具備「可信度」（當(dāng)然是職責(zé)范圍內(nèi)的邏輯，而不是讓商品服務(wù)去計(jì)算促銷的邏輯）。反之，上游系統(tǒng)一個(gè)bug就會(huì)牽連到你的系統(tǒng)中。

而讀操作背后的潛在預(yù)期是：「滿足」。你得提供給我滿足我當(dāng)前需要的數(shù)據(jù)，否則我的工作無(wú)法開展。

但是呢，在不同時(shí)期，客戶端所需要的數(shù)據(jù)可能會(huì)發(fā)生變化，你無(wú)法預(yù)測(cè)。所以呢，不要吝嗇，返回參數(shù)盡可能多，用哪些，用不用是客戶端的事。

還可以做的更好的一些，就是，在可以滿足的基礎(chǔ)上支持按需獲取。客戶端需要返回哪些字段自己通過(guò)參數(shù)傳過(guò)來(lái)，如此一來(lái)還能避免浪費(fèi)資源做無(wú)用的數(shù)據(jù)傳輸。

題外話：對(duì)外露出的接口設(shè)計(jì)，可以使用http + json 這種跨平臺(tái) + 弱類型的技術(shù)組合，可具備更好的靈活性。

實(shí)際上，一個(gè)程序大多數(shù)情況下，在某些時(shí)刻是客戶端，又在某些時(shí)刻是服務(wù)端。站在一個(gè)完整程序的角度來(lái)提煉參數(shù)設(shè)計(jì)的思路就是：“吃”的要少，“產(chǎn)出”的要多。

題外話：有一些設(shè)計(jì)原則可以擴(kuò)展閱讀一下。

單一職責(zé)原則SRP(Single Responsibility Principle)

開放封閉原則OCP(Open－Close Principle)

里式替換原則LSP(the Liskov Substitution Principle LSP)

依賴倒置原則DIP(the Dependency Inversion Principle DIP)

接口分離原則ISP(the Interface Segregation Principle ISP)

總結(jié)

本文z哥帶你梳理了一下「高內(nèi)聚低耦合」的本質(zhì)（來(lái)自于哪，意義是什么），并且分享了一些該怎么做的思路。

可以看到「高內(nèi)聚」、「低耦合」其實(shí)沒(méi)有這個(gè)名字那么高端。哪怕你現(xiàn)在正在工作的項(xiàng)目是一個(gè)單體應(yīng)用，也可以在class和function的設(shè)計(jì)中體會(huì)到「高內(nèi)聚」、「低耦合」的奧妙。

來(lái)來(lái)來(lái)，接下去馬上開始在項(xiàng)目中「刻意練習(xí)」起來(lái)吧～

「易伸縮」篇的相關(guān)文章：

• 分布式系統(tǒng)關(guān)注點(diǎn)——「無(wú)狀態(tài)」詳解

作者：Zachary

出處：https://www.cnblogs.com/Zachary-Fan/p/highcohesionlowcoupling.html

如果你喜歡這篇文章，可以點(diǎn)一下左下角的「大拇指」。

這樣可以給我一點(diǎn)反饋。: )

謝謝你的舉手之勞。

?關(guān)于作者：張帆（Zachary，個(gè)人微信號(hào)：Zachary-ZF）。堅(jiān)持用心打磨每一篇高質(zhì)量原創(chuàng)。歡迎掃描下方的二維碼~。

定期發(fā)表原創(chuàng)內(nèi)容：架構(gòu)設(shè)計(jì)丨分布式系統(tǒng)丨產(chǎn)品丨運(yùn)營(yíng)丨一些思考。

 

如果你是初級(jí)程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關(guān)注我的公眾號(hào)「跨界架構(gòu)師」，回復(fù)「技術(shù)」，送你一份我長(zhǎng)期收集和整理的思維導(dǎo)圖。

如果你是運(yùn)營(yíng)，面對(duì)不斷變化的市場(chǎng)束手無(wú)策。又或者想了解主流的運(yùn)營(yíng)策略，以豐富自己的“倉(cāng)庫(kù)”。歡迎關(guān)注我的公眾號(hào)「跨界架構(gòu)師」，回復(fù)「運(yùn)營(yíng)」，送你一份我長(zhǎng)期收集和整理的思維導(dǎo)圖。