《架構整潔之道》之元件聚合

軟體復用的最小粒度應等同於其發布的最小粒度。

從軟體設計與架構設計的角度來看，復用/發布原則就是指元件中的類與模組必須是彼此緊密相關的。也就是說，乙個元件不能由一組毫無關聯的類和模組組成，它們之間應該有乙個共同的主題或者大方向。

從另乙個角度來看，這個原則就沒有那麼簡單。因為根據該原則，乙個元件中包含的類與模組還應該是可以同時發布的。這意味著它們共享相同的版本號與版本跟蹤，並且包含在相同的發行文件中，這些都應該同時對該元件的作者和使用者有意義。

我們應該將那些會同時修改，並且為相同目的而修改的類放到同乙個元件中，而將不會同時修改，並且不會為了相同目的而修改的那些類放到不同的元件中。

共同閉包原則的主要作用:

提示我們要將所有可能會被一起修改的類集中在一處。也就是說，如果兩個類緊密相關，不管是源**層面還是抽象理念層面，永遠都會一起被修改，那麼它們就應該被歸屬為同乙個元件。通過遵守這個原則，我們就可以有效地降低因軟體發布、驗證及部署所帶來的工作壓力。

共同閉包原則和開閉原則也是緊密相關的。共同閉包原則討論的就是開閉原則中所指的」閉包」。開閉原則認為乙個類應該便於擴充套件，而抗拒修改。由於100%的閉包是不可能的，所以我們只能戰略性地選擇閉包範圍。在設計類的時候，我們需求根據歷史經驗和**能力，盡可能地將需要被一同變更的那些點聚合在一起。

對於共同閉包原則，我們還可以在此基礎上做進一步的延伸，即可以將某一類變更所涉及的所有類盡量聚合在一處。這樣當此類變更出現時，我們就可以最大限度地做到使該類變更只影響到有限的相關元件。

共同閉包原則實際上是單一職責原則的元件版。在單一職責原則的指導下，我們將會把變更原因不同的函式放入不同的類中。而共同閉包原則指導我們應該將變更原因不同的類放入不同的元件中。簡而言之，這兩個原則都可以用下面一句話來概括:

將由於相同原因而修改，並且需要同時修改的東西放在一起。將由於不同原因而修改，並且不同時修改的東西分開。

不要強迫乙個元件的使用者依賴他們不需要的東西。

共同復用原則是另外乙個幫助我們決策類和模組歸屬於哪乙個元件的原則。該原則建議我們將經常共同復用的類和模組放在同乙個元件中。

通常情況下，類很少會被單獨復用。更常見的情況是多個類同時作為某個可復用的抽象定義被共同復用。crp原則指導我們將這些類放在同乙個元件中，而在這樣的元件中，我們應該預見到會存在許多相互依賴的類。

共同復用原則的作用不僅是告訴我們應該將哪些類放在一起，更重要的是要告訴我們應該將哪些類分開。因為每當乙個元件引用另乙個元件時，就等於增加了一條依賴關係。雖然這個引用關係僅涉及被引用元件中的乙個類，但它所帶來的依賴關係絲毫沒有減弱。也就是說，引用元件已然依賴於被引用元件了。

由於這種依賴關係的存在，每當被引用元件發生變更時，引用它的元件一般也需要做出相應的變更。即使它們不需要進行**級的變更，一般也免不了需要被重新編譯、驗證和部署。哪怕引用元件根本不關心被引用元件中的變更，也要如此。

因此，當我們決定要依賴某個元件時，最好是實際需要依賴該元件中的每個類。換句話說，我們希望元件中的所有類是不能拆分的，即不應該出現別人只需要依賴它的某幾個類而不需要其他類的情況。否則，我們後續就會浪費不少時間與精力來做不必要的元件部署。

因此在共同復用原則中，關於哪些類不應該被放在一起的建議是其更為重要的內容。簡而言之，共同復用原則實際上是指導我們:不要緊密相連的類不應該被放在同乙個元件裡。

共同復用原則實際上是介面隔離原則的乙個普適版。介面隔離原則建議我們不要依賴帶有不需要的函式的類，而共同復用原則則是建議我們不要依賴帶有不需要的類的元件。

上述兩條建議實際上都可以用下面一句話來概括:

不要依賴不需要用到的東西。