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

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

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

粒度影響內聚和耦合

這是關于內聚和解耦的關鍵誤解。

內聚和解耦完全與模塊的粒度有關。

從這里開始，我不會說類、軟件或系統(tǒng)，當我提到內聚和耦合時，我會說模塊。

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

讓我給你舉個例子。讓我們以上面提到的鏈表類為例。如果我們將模塊定義為代碼中的任何類，那么它是相當解耦的。但是，如果我們將模塊定義為系統(tǒng)中的任何類或基元類型，我們的鏈表實現(xiàn)會突然依賴于許多其他東西。現(xiàn)在我們在類中聲明的變量依賴于數(shù)組、字符串類或整數(shù)實現(xiàn)。

當我們深入到模塊的上述層次時，我們最終會得到更多表示更緊密耦合的依賴關系。

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

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

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

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

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

它是這個簡單問題的一個實現(xiàn)，使用了3個程序集和16+個類。如果我們認為一個模塊是一個類，那么它就沒有很強的內聚性，因為一個或兩個方法中應該包含的內容的職責分布在16個程序集中。如果我們認為一個模塊是一個程序集，那么它仍然沒有很強的內聚性。

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

本節(jié)有兩個重要的要點：

1. 我們在查看軟件時如何定義模塊會影響內聚和耦合。

2. 我們用來構建軟件的粒度會影響內聚和耦合（這一點隱藏在enterprise FizzBuzz示例中。在本例中，代碼作者將責任定義為非常小的內容）。

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

當內聚力和耦合力成反比時

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

如果我們試圖過分地推進松散耦合區(qū)，我們會發(fā)現(xiàn)，我們最終會使我們對責任的定義變得非常非常小，在這一點上，我們失去了凝聚力的質量。

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

考慮一下當我們創(chuàng)建一個接口來“減少耦合”以便創(chuàng)建單元測試時會發(fā)生什么，我們最終會降低內聚性，因為我們的類所引用的類（一個跳躍）現(xiàn)在是一個由類（兩個跳躍）實現(xiàn)的接口

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

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

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

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

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

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

凝聚力更重要

似乎我是在說內聚比解耦更重要，實際上我是。

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

我傾向于把軟件的理解和簡單性放在最重要的事情之上，因為它們對維護和調試最有幫助。

當我們試圖增加解耦時，考慮內聚力是非常重要的。它還可以幫助我們非常清楚地衡量何時使解耦最大化。在任何解耦都會損害內聚力的情況下，我們就這樣做了。

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

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

當我們考慮使用任何類型的框架或模式來解耦我們的軟件時，我們必須意識到我們在內聚性和可理解性方面正在失去什么。

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

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

別誤會，有時內部消息總線是應用程序的一個很好的解決方案，但在許多情況下，它對您的傷害大于幫助。

都是大小合適的樂高積木

Scott Hanselman經(jīng)常喜歡談論“合適大小的樂高積木”，我完全同意他的觀點。弄清楚如何在保持內聚性的同時適當?shù)亟怦顟贸绦蚓褪桥宄K的理想大小。

有時，答案甚至可能是將應用程序拆分為多個應用程序。