元件如何正確使用 ? | 元件耦合性三大原則 : ADP、SDP、SAP
元件如何正確使用 ? | 元件耦合性 : 3 大原則
最少改動 x 最大收益
大綱
- 簡單的任務 ?
- 神奇的軟體
- 耦合性三大原則
- ADP , 無環依賴原則
- SDP , 穩定依賴原則
- SAP , 穩定抽象原則
- 領域驅動設計細節
- 最少改動，最大收益
簡單的任務 ?
有一個任務，要調整介面上的表格數據:
- 客戶覺得:「應該很簡單」
- PM 覺得:「半小時搞定」
打開程式
你發現有太多的其他功能，都要使用到這個數據。
這裡一改動，就代表了全部都要一起改。- 你只覺得: 血壓好像有點微微的增高。
功能模組，使用了其他功能
兩者建立了依賴關係，這種行為在軟體中也會稱為:
「耦合」理想中的目標
高內聚 低耦合- 高內聚 : 分類分得越精準越好。
- 低耦合 : 建立的關係越少越好。
要怎麼達成 ?
耦合性三大原則可以先幫你實現低耦合的目標。
神奇的軟體
「軟體」是一種很神奇的東西，看似很自由，可以隨意添加新的功能。
如果真的這麼隨意
自由的空間，反而會越來越少 (越來越難改動)依循一些原則，規範開發的方向
看似多了限制，卻反而能使得，未來的擴展空間 大大的增加。軟體的特性，也是一種「違反直覺」的力量
「違反直覺」延伸閱讀 :
Clean Architecture 無瑕的程式碼
整潔的軟體設計與架構篇
除了「物件導向的五大設計原則」以外，還有「元件的內聚性原則」與「元件的耦合性原則」。
先後順序
實際上的順序，應該是要:
內聚性先，而耦合性後因為我個人認為「耦合性」的概念，比較好懂; 原則的部分，也相對容易，應用於開發上。
這次，會先說明耦合性的部分
下一篇章，會接著繼續說明內聚性的部分
耦合性三大原則
ADP 無環依賴原則
在元件的依賴關係圖中不允許出現環
SDP 穩定依賴原則
朝著穩定方向進行依賴
SAP 穩定抽象原則
元件的抽象程度應該與元件的穩定程度一致
ADP , 無環依賴原則
Acyclic Dependencies Principle
在元件的依賴關係圖中不允許出現環從字面上來理解，就是元件在需要其他的元件工作時，之間構成的依賴關係，不可以是環狀循環。
為什麼 ?
因為依賴於其他元件，目的是為了
「減輕工作量」別的元件有做過的事情，就不要重新再做一次。
如果元件的依賴會互相參照，代表 :
- 我的元件調整後，可能會影響到要依賴的元件
- 依賴的元件被影響後，又有可能回頭影響到我的元件
就好像構成了 一個短路循環 ，直到系統「過載」
從「減輕工作量」這個角度來看，「循環依賴」更像是一個工作製造機
可以源源不絕的，讓你有做不完的工作。(不會失業 XD)SDP , 穩定依賴原則
Stable Dependencies Principle
朝著穩定方向進行依賴延續無環依賴原則的思路，除了依賴不能造成循環，依賴還是最好有個方向。
這個方向的路標，就是「穩定度」
穩定度 ?
也是以「工作量」的多寡來決定穩定的元件 ?
元件被很多的功能依賴，但本身沒有去依賴任何東西
- 不會有外部的元件，影響到它
- 但它卻能夠影響到，很多元件
改了它，就代表了巨大的「工作量」
所以這個元件是「穩定」的不穩定的元件 ?
如果這個元件，沒有功能依賴它，但它依賴了很多外部的元件
- 外部的元件更動，它都有可能受到影響
- 但它本身自行改動 卻不會影響到其他元件
修改它的「工作量」非常的低
所以這個元件是「不穩定」的穩定度計算公式
藉由依賴的關係數量，這裡就會有一個的公式，可以計算元件的穩定度
理想的狀況，就是由不穩定的元件，朝向穩定的元件，建立依賴關係
SAP , 穩定抽象原則
Stable Abstractions Principle
元件的抽象程度 應該與元件的穩定程度一致- 「穩定」: 在上一個原則 已經知道什麼意思
- 「抽象」: 則代表的是 只表達「概念」但並不「實作」
也就是越重要的元件，應該越只表達純粹的「概念」
為什麼 ?
穩定的核心元件，雖然穩定，但失去彈性不能擴增，並不是軟體設計想要看到的情況。
舉個例子
以餐廳來說，廚師就是穩定的核心元件
由廚師本身會煮什麼菜，來決定餐廳會有什麼樣的菜單
對於，有點規模的餐聽，這並不是一個好的情況
這邊的原則，就是將表達「概念」的「菜單」，當成是最穩定的核心元件
如此，就不會受到限制。各個連鎖店的廚師，也能根據菜單的菜譜，快速增加新的菜色。
領域驅動設計細節
依據耦合性的原則，領域驅動設計的概念，補充實作部份的三個細節:
- Domain 層
- Application 層
- Infrastructure 層
Domain 層
通常就是系統的核心，所以 Domain 的 Service 通常會宣告成 Interface 的介面
名稱結尾為 Service
然後，在同目錄的 impl/ 資料夾，創建新的類別實作(implements) 該 Service 的介面
名稱結尾為 ServiceImpl
這裡是借鑒了 「SAP 穩定抽象原則」，越穩定的元件應該越抽象。Application 層
負責的是流程作業，相比於 Domain 層變動性是比較大的，雖然說同樣有 Service 的類別，但不再創建 Interface 的介面
結尾的名稱命名 使用 AppService
這裡是借鑒了 「SDP 穩定依賴原則」，把容易變動的東西，變得更加容易改動。Infrastructure 層
提供所有的技術支援，從 DDD 的架構分層可以很明顯地看到，它是個自上而下的依賴關係
但對於與 Domain 層的關係，我認為不應該被領域層的元件所依賴有兩個部分可以具體說明:
- DAO 資料持久化
- Util 共用工具
第一個 : DAO 資料持久化的部分
DAO , Data Access Object
領域層(Domain Layer)的服務(Service) ，不應該直接 調用 DAO 來完成資料保存的任務
而是應該提升一個層級，交由應用層(Application) 來執行這項任務
避免資料庫的變動會影響到領域層(Domain Layer)的功能
第二個 : Util 工具的使用
util 工具，通常會是各種第三方的框架，封裝而來
如果，第三方的框架:
- 有重大的 bug
- 有更好的框架可以更換
調整 util 元件，就會影響到 領域層(Domain Layer) 的功能這種情況...
不如就由領域層(Domain Layer) 提供 :
- 抽象方法的類別(abstract)
- 抽象型別的介面(interface)
然後由，基礎設施層來實作功能。
不管最後是使用什麼樣的技術實作，只要能夠通過，領域層的單元測試，就可以確保系統的正確性。
違反直覺
這部分，可能一時之間無法轉換過來，不過這裡要表達的就是:
Domain 層 是穩定的核心元件，不應該去依賴其他層級的元件。
最少改動，最大收益
依據上述耦合性的三大原則，有沒有發現一件事情:
「穩定」與「不穩定」並不是一個「好」與「壞」的關係
而是這個「穩定度」與元件的「特性」是否是相符合。
最容易變動的「使用者介面層」、「應用層」，就是放在上兩層，向下依賴
- 耦合性的「無環依賴」與「穩定依賴」，基本上已經大部份的符合
- 領域層的部分，添加了三個細節，讓它看起來更加核心，也符合了「穩定抽象的原則」
完美的「設計」?
不敢說是最好的「設計」，但我知道 :
建立關係
不應該是那麼的隨心所欲朝著正確的方向不斷精進，也許哪一天也可以觸碰到傳說中:
「最少改動，最大收益」 軟體開發的天堂之境
語錄
工程師OS
只有資深工程師才有資格跟工程師說:「應該很簡單」
-- Gamma Ray Studio參考資料
- Clean Architecture 整潔的軟體設計與架構篇
- 維基百科-耦合性
- 細談元件耦合性
- 那些他們無法當面說的｜要成為好PM，先聽聽工程師的內心話
留言
張貼留言