14 元件耦合性

字數總計：0 個 | 閱讀時長：0 分鐘 |閱讀次數：次

本章介紹三個元件之間該有的原則：

相依要無環
相依要穩定
抽象介面要穩定

影響架構的作用力有三種：政治力、技術能力和揮發力

無環依賴原則(The Acyclic Dependencies Principle, ADP)

簡單說就是元件相依有向圖中，不得出現環

那這個原則是怎麼演化而來的呢？

很久很久以前，所有的工程師都編輯相同的一份程式碼，而他們都面臨一個「一覺醒來，發現自己在異世界」的問題。昨天下班前寫的程式明明是正常運作，怎麼早上來上班就壞了？！這是因為有人半夜連ＶＰＮ，修改了同一份的程式碼，意外地，把你昨天寫的東西弄壞了。為了解決這個夢魘，有識之士提出了Ｗeekly Build 週建置星期一到星期四，人們在自己的機器上開發，避免編輯到同一份原始碼；星期五的時候，大家將各自的原始碼合併，然後建置新版的程式。因此，人們有四天可以專心開發，再也沒有「起床症候群」的困擾了。當專案很小或是人數很少的時候，大家過著幸福快樂的日子。可惜好景不常，一旦專案越來越大、人越來越多，合併原始碼所需的時間便越拉越長，單單星期五一天處理不完，於是建置時間從星期五、星期四漸漸的往週中延長。於是，時間都拿去處理合併，開發時間被壓縮自然地效率越降越低。很顯然週建置還不足以解決問題。

消除依賴還

首先我們要把整個開發分解成一個個的小元件，而且每個元件必須是單人或一組可以負責做完的工作份量。當元件穩定的時候，開發團隊釋出負責的元件並附上版號，讓別人使用釋出的版本，同時間，開發團隊可持續開發也不會影響到使用該元件的程式碼。如此一來，當別人釋出新的元件的時候，你可以選擇相依舊的或是新的元件，再也不會因為別人的改動讓你的程式壞掉了！我們解決了之前週建置遇到的問題：

別人修改的程式導致你的功能壞掉
不需要統一時間合併程式碼

但這個前提是相依有向圖裡面不可以有環！否則還是會發生「起床症候群」。下圖的相依有向圖中，沒有任何的環。

從相依有向圖，我們可以很清楚地解釋出元件的時候會對誰造成影響

Case: Release main
在釋出新版的main的時候，我們完全不用擔心會影響到其他的元件
Case: Release Presenters
更新 Presenters 會影響main & view，這兩個元件的開發者可以自己決定要不要跟著升級

相反的，在開發的時候只要確保相依的套件的版本是對的，就可以保證元件的功能可以正常運作。換句話說，開發者無須考慮全部的元件，只需要專注在相依的元件上即可。

當我們要釋出應用程式或是 linbrary 的時候，由底層向上層建置即可，建置程序非常的清晰明瞭。

如果有環會造成什麼影響

如果 Entities 相依於 Authorizer，使得相依有向圖變成下圖，會發生什麼事？

對於 Database 來說，相依變多導致釋出 Database 的話，需要考慮的事情變多了
Entities, Authorizer 和 Interactors 等效上，變成了一個新的且龐大的元件
Entities, Authorizer 和 Interactors 之中的任何修改都會相互影響
不知道要怎麼建置 Entities

那我們要怎麼解決環的問題呢？使用 Dependency Inversion Principle (DIP)

在 Entities 裡面新增 interface Permission

2. 新增一個元件 `Permission`

在開發過程中，我們發現元件結構經常改變，我們要時時刻刻確保有向相依圖中沒有環。

經由上面的例子，由上而下的設計模式是不存的。因為元件架構隨著開發的進程逐漸演進，不可能在開始一個專案的時候，就決定好元件的架構。隨著開發進程，我們會開始思考要如何重複利用寫好的原件，於是我們可以用共同重復使用原則(common reuse principle, CRP) 來實作；當元件變小變多的時候，因為你不清楚別人怎麼使用你的原件，所以出現環狀相依的機率越來越大，而出現環狀相依的時候，我們會用無環依賴原則(acyclic dependencies principle, ADP) 來解決環狀相依，而解決問題的副作用就是讓元件相依架構圖不穩定、時常改變。

另一方面，元件相依圖最重要的功能將「維護性」和「可建置性」圖像化。隨著開發我們的元件架構會越變越複雜，我們可以藉由元件相依圖來管理各個模組、元件的相依關係，以避免出現「起床症候群」，要避免「起床症候群」就要

各模組、元件內的修改所造成的影響範圍要本地化(越小越好)
所以在實作的時候，需要注意這兩個原則共同封閉原則(common closure principle, CCP) 和單一職責(single responsibility principle, SRP)。還有合併會互相影響的原件。
將系統內某元件經常變動的部分和不常變動的部分分開，讓常變動的元件相依不常變動元件
這樣才不會因為常變動的部分導致不變的部分壞掉

穩定依賴原則(SDP)

朝著穩定的方向進行依賴

透過符合共同封閉元則(Common Closure Principle, CCP)，我們會建立對某些變化類型敏感的元件，這些元件被設計成可變的，我們預期它們會變化。那麼對於一個預期是可變的元件，他就不應該讓另一個難以更改的元件依賴他，否則就會造原可變的元件難以更改這就是軟體的反常的特性，就算你的模組沒有任何的修改，只要別人對你有依賴，就可以讓你的程式變得難以更改。透過遵循單一職責(single responsibility principle, SRP) 可以確保設計成可變的模組不會被更難以更改的模組所依賴。