Clean Architecture 無暇程式碼
整潔的軟體架構與設計
CH8. OCP 開放封閉原則
一個軟體產品應該對擴展是開放的, 對修改是封閉的
這章節的 OCP , 有個必須清楚的觀念是依賴方向, 延伸 SRP 的原則, 延伸一個模組只對一個利害關係人負責。
在模組中, 會有資料流, 資料怎麼進入, 到資料怎麼交付顯示到 user 面前, 可以再把模組細切成元件, 這邊的元件像是跟資料溝通的 interactor 元件, 跟 interactor 溝通的 controller 元件, 還有 presenter, view 元件等等…
元件彼此之間因為資料流傳送的關係, 會有依賴方向
- interactor 跟資料庫模組 (e.g. jdbc) 讀取資料
- controller 跟 interactor 讀取業務資料
- presenter 跟 controller 讀取顯示用的資料
- view 跟 presenter 讀取資料顯示給 user
假設上述的流程, 是 CRUD 裡面的 Read 讀取報表, 實際業務來說, 最常需求異動的應該是 view 或是 presenter 的層級, 因此在架構領域裡 view 與 presenter 算是較低階 (容易變更) 的層級; interactor 則是較高階 (核心業務) 不應該常變更的層級.
但這應該是理想情況, 系統必須發展一陣子, 軟體工程師才能變成領域專家看出核心業務, 但這是題外話了.
為了保護 interactor 免遭受業務變更的修改, 或是遞移依賴*（Transitive Dependency）通常會使用物件導向設計裡面的 interface 特性來處理這個問題, 使用 (Caller) interface 的人, 只會知道 interface 的行為, 不會知道 interface 裡面處理的細節; 因此在解耦的處理上, 通常會透過 interface 把元件的依賴轉換為對 interface 的依賴.
- 遞移依賴（Transitive Dependency）這個名詞書上並沒有特別解釋, 我讀的是中文版, 也不太確定這個名詞是不是這樣翻譯（可能用 間接依賴, 比較好理解 ?）, 用 Maven 的套件依賴來解釋的話, 假設套件 A → B → C 的依賴關係是這樣, 那可以說 A 遞移依賴 (遞移依賴) C.
Ref: https://stackoverflow.com/questions/41725810/what-is-a-transitive-maven-dependency
