（札記）Java應用架構設計-模塊化模式與OSGi

本書主要模塊化模式的優點、模塊化方法與模式、OSGi簡單使用等內容。分3大部分：

第一部分介紹了模塊化概念。為什么要模塊化，以及一些模塊化要考慮的東西，如模塊粒度，依賴關系，重用性靈活性等。

第二部分介紹模塊化的一些模式。採用了GoF設計模式的格式（模式名稱、模式表述、圖示、描寫敘述、多種實現、效果、例子、小結），看着有些亂，可是收獲不少。

第三部分介紹OGSi結合Java怎樣使用。以及怎樣模塊化現有系統。Java中無法直接模塊化（Java SE模塊化功能Jigsaw被推遲到了Jave SE 9），由於你能夠隨時訪問其它模塊類中的隨意public方法，想要強制性模塊化，僅僅同意訪問公布的方法，能夠使用OSGi框架。

這里模塊化的概念和組件化相似，可部署、可管理、原生可重用、可組合、無狀態的軟件單元，對外提供了簡單介紹的接口。在Java中，最適合模塊化的單元就是Jar文件。

代碼層面我們關注的太多了，熟練的開發者如今非常少爭論使用模式的優點，也不再識別哪個模式適合當前須要。由於都可以本能地使用各種設計原則和模式。從GoF的設計模式到衍生出的設計原則，如今非常多原則已經差點兒變成了本能。如“優先組合而不是繼承”、“面向抽象而不是面向實現”。

可是僅僅考慮類級別的設計，那么無論設計的多么美麗，都不會代碼預期的收益。由於現有的設計原則和面向對象開發模式不能幫助管理大型軟件系統的復雜性，由於他們解決的是不同的問題。

架構的目標是盡可能降低變化的影響和成本。模塊化通過填補高層架構組件以及底層代碼之間的空白，幫助我們實現這個目標。



通用的原則：
1、接口要更接近使用它們的類。而遠離實現它們的類。
2、異常應該接近拋出它們的類或接口，而不是接近捕獲異常的模塊

模塊化的一些模式和方法，大體的思想原則和類設計的原則相似，非常多方法都是基於“依賴抽象而非依賴實現”這個原則的。

1、悖論，粒度越小的模塊越靈活。管理起來也就越復雜，怎樣在靈活性和管理復雜度兩者間取舍。最大化重用使得可用復雜化。粒度越小的模塊重用性越高。可用性越低，也就是越不方便用。怎樣在重用性和可用性之間取舍。盡管沒有絕對的結論，可是慷慨向上有了結論。

2、穩定性，具有大量被依賴的模塊應該是非常穩定的，也就是非常少發生變化。變化帶來的影響更大。確保模塊穩定性最好的方式就是將其轉換為抽象模塊。具有大量依賴其它模塊的模塊，是不穩定的，非常easy進行變化，易於使用，可是不easy測試（由於依賴其它模塊太多）。最好的方式應該依賴抽象模塊。

3、模塊等級必須分等級。模塊必須等級化，高等級依賴低等級。低等級不能依賴高等級。低等級不能有太多依賴，等級越低的模塊應該越穩定，不穩定的模塊應該放到高等級。

4、模塊重用，類級別重用不能跨應用（比方工具類），而模塊級別重用能夠跨應用。

軟件開發初期，需求處於不斷變化之中。模塊粒度應該大。易於管理和使用。隨着識別出需求變化的重點。找出了可重用的地方。較大模塊應該拆分成較小的、更易於重用的細粒度模塊。軟件開發初期就試圖定義較小的細粒度模塊是非常困難的，由於僅僅能推測重用點在哪，一般是失敗的。

5、模塊內聚：高內聚的模塊易於理解、維護和重用。影響模塊內聚的因素有2點，一個是類變化的頻率，還有一個是類的可重用性。軟件開發初期應基於變化頻率構建模塊，由於系統不穩定，系統穩定后，應基於重用構建模塊。也就是說軟件前期非常難創建高內聚的模塊，隨着系統穩定，開發團隊應該又一次組織系統以確保模塊都是內聚的。

6、模塊依賴。高等級模塊單向依賴低等級模塊是最好的，最不好的就是循環依賴，這里提供幾個方法消除依賴。

單向依賴時，比方低層級模塊依賴高等級模塊了，解決方法：

反轉關系：穩定模塊A依賴B的部分抽象接口。依賴自己接口。B去實現這個接口，達到B依賴A的反轉。

消除關系：抽象出模塊C。A依賴C（A使用C）。B依賴C（B實現C），達到A和B不依賴關系。

兩個模塊有循環依賴關系，通常就是一個模塊。應該合並。假設不合並就要打破這樣的關系，解決的方法有：

上移：將依賴成因上移到高等級模塊，創建一個更高等級模塊。抽象出最低等級模塊依賴關系，達到單向依賴。
下移：將依賴成因下移到高等級模塊，與上移相反，創建一個更低等級模塊而已。
回調：定義一個抽象體，將其注入到模塊中，達到單向依賴甚至消除依賴個可能。

事實上通過反轉和消除。也能解決循環依賴。依據詳細使用場景選擇吧。

7、模塊應該輕量級。不依賴容器和執行環境，可單獨部署使用最好。

8、模塊管理。假設不打算重用某個模塊，那么依賴管理的動力就是可維護性，假設想要可維護性提高，就要關注可測試性（越easy測試、則越easy維護）。

最好在開始的時候盡可能簡單並隨着需求出現增強模塊，而不是開始的時候基於預測創建復雜模塊。

9、默認實現。模塊應該有一個默認實現，假設沒有不論什么實現，模塊實際上僅僅是一個規范。

（比方默認實現就是插件式開發的一種方式。）

10、依賴抽象就必須保證獲取實現類的實例時，不能new，經常用法有3類，工廠方法、動態創建（如Spring注入）、OSGi μService。

11、假設依賴抽象體的全部類都在一個模塊中，那么將這些類和抽象體放在同一個模塊中。假設依賴抽象體的全部類位於多個模塊中。那么將抽象體放到一個單獨的模塊中。

最后說說為什么要用OGSi來強制模塊化。“優雅的理念設計在實現的過程中非常快就可能變得一團糟，沒有開發者可以理解最初的高級願景要怎樣展如今代碼中。雖然你非常清楚預期的模塊關系是什么。可是不想要的依賴依舊會進入你的應用。”真實情況確實如此，任何原因，終於的結果都是一樣的。就是我們的代碼越來越差，模塊關系混亂了，代碼可以定期重構，可是模塊重構的代價比較大，OGSi有個辦法強制解決，“等級化構建會強制你思考模塊依賴...由於任何新的依賴都需要改動構建腳本。所以對於開發者，定義新的依賴必需要謹慎。

等級化構建使引入新的依賴要做很多其它的事情。”

剛參加工作時，開發過程中非常多功能假設使用前必須配置好幾處的配置文件，當時認為非常麻煩，一直沒找到非常有說服力的理由，讀完本書總算發現了：

1、配置復雜通常代表着靈活程度高。越靈活使用起來越麻煩，越靈活越復雜，非常多事都這樣，沒有完美，僅僅有當前最適合的平衡點。
2、復雜的配置，讓開發者更謹慎，假設沒有這么復雜的配置。開發者會隨便亂寫。終於造成系統極其糟亂。
3、復雜的配置，集中於一處或一類地方。也方便審查梳理。

最后，本書的模塊化設計思想讓我收獲頗多，眼下還不是特別流行，希望未來會變的很流行，未來的OSGi也將會帶來生態系統（Eclipse成功是基於OSGi生態系統）。

版權聲明：本文博客原創文章。博客，未經同意，不得轉載。