這篇文章是我關(guān)于內(nèi)聚和耦合的文章的延續(xù)，它是一系列回到基礎(chǔ)文章的一部分，這些文章研究和質(zhì)疑了軟件開發(fā)的一些核心原則和實(shí)踐。

在上一篇文章中，我討論了什么是內(nèi)聚和耦合，以及它們各自的一些好處。

現(xiàn)在我想看看內(nèi)聚和解耦在軟件系統(tǒng)上的實(shí)際應(yīng)用。

粒度影響內(nèi)聚和耦合

這是關(guān)于內(nèi)聚和解耦的關(guān)鍵誤解。

內(nèi)聚和解耦完全與模塊的粒度有關(guān)。

從這里開始，我不會(huì)說類、軟件或系統(tǒng)，當(dāng)我提到內(nèi)聚和耦合時(shí)，我會(huì)說模塊。

看，問題是我們需要能夠定義什么是模塊，以便確定某個(gè)東西是松散耦合的還是高度內(nèi)聚的。

讓我給你舉個(gè)例子。讓我們以上面提到的鏈表類為例。如果我們將模塊定義為代碼中的任何類，那么它是相當(dāng)解耦的。但是，如果我們將模塊定義為系統(tǒng)中的任何類或基元類型，我們的鏈表實(shí)現(xiàn)會(huì)突然依賴于許多其他東西?，F(xiàn)在我們?cè)陬愔新暶鞯淖兞恳蕾囉跀?shù)組、字符串類或整數(shù)實(shí)現(xiàn)。

當(dāng)我們深入到模塊的上述層次時(shí)，我們最終會(huì)得到更多表示更緊密耦合的依賴關(guān)系。

凝聚力呢？如果愿意，請(qǐng)考慮Enterprise FizzBuzz。這是FizzBuzz問題的一個(gè)實(shí)現(xiàn)：

• 打印從1到100的數(shù)字

• 如果數(shù)字可被3整除，請(qǐng)打印“ Fizz”

• 如果數(shù)字可以被5整除，請(qǐng)打印“ Buzz”

• 如果數(shù)字是可分割的3和5，則打印“ FizzBuzz”

它是這個(gè)簡單問題的一個(gè)實(shí)現(xiàn)，使用了3個(gè)程序集和16+個(gè)類。如果我們認(rèn)為一個(gè)模塊是一個(gè)類，那么它就沒有很強(qiáng)的內(nèi)聚性，因?yàn)橐粋€(gè)或兩個(gè)方法中應(yīng)該包含的內(nèi)容的職責(zé)分布在16個(gè)程序集中。如果我們認(rèn)為一個(gè)模塊是一個(gè)程序集，那么它仍然沒有很強(qiáng)的內(nèi)聚性。

在這個(gè)軟件變得內(nèi)聚之前，我們必須把所有的方法都放大到模塊是一個(gè)程序級(jí)別，但是在這個(gè)級(jí)別上，它與它所依賴的所有其他框架是非常耦合的。

本節(jié)有兩個(gè)重要的要點(diǎn)：

1. 我們?cè)诓榭窜浖r(shí)如何定義模塊會(huì)影響內(nèi)聚和耦合。

2. 我們用來構(gòu)建軟件的粒度會(huì)影響內(nèi)聚和耦合（這一點(diǎn)隱藏在enterprise FizzBuzz示例中。在本例中，代碼作者將責(zé)任定義為非常小的內(nèi)容）。

綜上所述，我們可以從放大和縮小的不同層次來觀察代碼，并確定其耦合性和內(nèi)聚性，我們還可以將軟件構(gòu)建為具有相同效果的不同大小的“樂高積木”。

當(dāng)內(nèi)聚力和耦合力成反比時(shí)

在這樣的背景下，我們終于可以回答這樣一個(gè)問題：是否有可能實(shí)現(xiàn)高內(nèi)聚和松耦合。答案是“在一定程度上”

如果我們?cè)噲D過分地推進(jìn)松散耦合區(qū)，我們會(huì)發(fā)現(xiàn)，我們最終會(huì)使我們對(duì)責(zé)任的定義變得非常非常小，在這一點(diǎn)上，我們失去了凝聚力的質(zhì)量。

我要再舉一次過度使用接口的例子。

考慮一下當(dāng)我們創(chuàng)建一個(gè)接口來“減少耦合”以便創(chuàng)建單元測(cè)試時(shí)會(huì)發(fā)生什么，我們最終會(huì)降低內(nèi)聚性，因?yàn)槲覀兊念愃玫念悾ㄒ粋€(gè)跳躍）現(xiàn)在是一個(gè)由類（兩個(gè)跳躍）實(shí)現(xiàn)的接口

現(xiàn)在考慮一下當(dāng)我們添加一個(gè)依賴注入模塊，甚至僅僅是一個(gè)工廠來獲得實(shí)現(xiàn)時(shí)會(huì)發(fā)生什么，我們?cè)?jīng)簡單且高度內(nèi)聚的實(shí)現(xiàn)分布在一個(gè)接口上，這個(gè)接口是由一個(gè)類實(shí)現(xiàn)的，我們必須在一個(gè)工廠中查找這個(gè)類，這個(gè)工廠包含某種映射文件來將接口映射到實(shí)施。（3-4跳）

我知道這個(gè)概念看起來很奇怪，但讓我看看能否用一個(gè)真實(shí)的例子來解釋它。

再考慮一下高內(nèi)聚性棒球。它已經(jīng)處于0的最佳耦合。它不依賴于其他任何東西。但是，如果我們想，我們可以嘗試去耦合它。如何？我們必須放大到一個(gè)點(diǎn)，我們可以認(rèn)為，外部縫合是耦合到套管，這是耦合到內(nèi)部球。

我們可以把棒球拆開，然后設(shè)計(jì)一種接口，允許外殼和基板有不同的綁定機(jī)制，以防止外殼直接接觸內(nèi)球。

如果我們這樣做的話，我們會(huì)讓球的碎片到處都是，它就不會(huì)有很強(qiáng)的凝聚力，甚至功能性。

我們可以用軟件來做到這一點(diǎn)，在這一點(diǎn)上，我們已經(jīng)獲得了松散耦合和高內(nèi)聚的最大質(zhì)量，我們可以嘗試以內(nèi)聚為代價(jià)來推動(dòng)解耦。

凝聚力更重要

似乎我是在說內(nèi)聚比解耦更重要，實(shí)際上我是。

如果您還記得緊密內(nèi)聚和松散耦合的優(yōu)點(diǎn)，您可能已經(jīng)意識(shí)到大多數(shù)優(yōu)點(diǎn)都是相同的，只是緊密內(nèi)聚給我們帶來了增加理解的好處。

我傾向于把軟件的理解和簡單性放在最重要的事情之上，因?yàn)樗鼈儗?duì)維護(hù)和調(diào)試最有幫助。

當(dāng)我們?cè)噲D增加解耦時(shí)，考慮內(nèi)聚力是非常重要的。它還可以幫助我們非常清楚地衡量何時(shí)使解耦最大化。在任何解耦都會(huì)損害內(nèi)聚力的情況下，我們就這樣做了。

那么依賴注入是不是不好呢？

不，一點(diǎn)也不。依賴注入和其他解耦方法都有它們的位置，但非常重要的是，我們不要在任何情況下盲目地將它們用于每個(gè)類。

當(dāng)我們考慮使用任何類型的框架或模式來解耦我們的軟件時(shí)，我們必須意識(shí)到我們?cè)趦?nèi)聚性和可理解性方面正在失去什么。

我將在這里再談一件事，因?yàn)槲艺J(rèn)為這不是很明顯?？紤]一下消息總線對(duì)于將不同的應(yīng)用程序集成在一起有多好。消息系統(tǒng)可以將需要相互通信的不同應(yīng)用程序解耦，使它們具有高度的內(nèi)聚性和非常松散的耦合性。

現(xiàn)在，考慮一下消息總線在應(yīng)用程序中的糟糕程度，我知道對(duì)于解耦應(yīng)用程序中的事件、命令和其他通信來說，它是一個(gè)相當(dāng)流行的解決方案，但是很多時(shí)候，解耦的代價(jià)對(duì)內(nèi)聚性和可理解性是一個(gè)非常高的打擊。

別誤會(huì)，有時(shí)內(nèi)部消息總線是應(yīng)用程序的一個(gè)很好的解決方案，但在許多情況下，它對(duì)您的傷害大于幫助。

都是大小合適的樂高積木

Scott Hanselman經(jīng)常喜歡談?wù)摗昂线m大小的樂高積木”，我完全同意他的觀點(diǎn)。弄清楚如何在保持內(nèi)聚性的同時(shí)適當(dāng)?shù)亟怦顟?yīng)用程序就是弄清楚模塊的理想大小。

有時(shí)，答案甚至可能是將應(yīng)用程序拆分為多個(gè)應(yīng)用程序。