我認為每個人都會同意，編寫模塊化應用程序和模塊化通常是一件好事。

但是，從Java和Scala語言以及各種Java / Scala框架來看，對模塊化的支持是怎樣的呢？ 有很多不同的方法！ 讓我們看看其中的一些。 “保護”以下是指模塊在編譯時或運行時的分離程度。

配套

首先，我們有Java（或Scala）軟件包 。 當組織源代碼時，該概念非常有用。 但是，它不提供編譯時或運行時（受程序包保護的可見性除外，它沒有被廣泛使用）保護，因此很難說程序包對模塊化代碼有任何幫助。 此外，還有很多命名問題，因此也有約定：例如，如果我們有兩種數據讀取器實現，一種使用數據庫，另一種使用文件系統，則相關的類應該進入數據庫和文件系統子包，還是保留在同樣的頂級套餐？ 即使類名在專用軟件包中，也應在它們之前加上數據庫和文件系統嗎？

建立子項目

其次，有Maven / SBT模塊/子項目 。 它們提供了編譯時保護，這是一件非常好的事情：現在，我們可以靜態地確保我們的代碼僅引用顯式指定的依賴項中的類。 但是，隨之而來的是一個顯而易見的問題：什么時候一個功能“足夠大”以使其成為一個單獨的Maven模塊？ 可以有很多Maven模塊，每個模塊僅包含幾個類（可以是PITA，必須為每個類定義一個單獨的pom，目錄結構），還是應該更大一些？ 關于命名約定，包名稱應與模塊名稱相對應嗎？ 如果是這樣，我們顯然違反了這里的DRY ;）！

想象一下，我們決定將數據庫和文件系統數據讀取器放入單獨的程序包，maven模塊中并適當命名。 因此，在myapp-database Maven模塊的foo.bar.database包中，我們有一個DatabaseReader（外加10個幫助器類）。 現在是一個簡單的重構：將“數據庫”重命名為“ db”成為一項非常復雜的任務，最肯定的結果是在各個地方使用了各種術語。

OSGi

演進的下一步將是OSGi捆綁包 （或等效地，是JBoss Modules或Project Jigsaw中的 模塊 ）。 一個這樣的捆綁包通常是一個（或多個）Maven模塊的產品，但是它也通過適當地限定類加載器的范圍來提供運行時保護。 Maven模塊中的所有問題都是繼承的……另外還需要命名包！

嵌套類/蛋糕圖案

對代碼進行范圍界定的另一種可能性是使用嵌套類 ，甚至更進一步，并在Scala中使用Cake模式 。 除了舊的問題：使用什么軟件包以及如何命名模塊類外，我們還有幾個新問題。 首先，模塊的整個源代碼現在位于一個文件中。 這可能意味著文件很長！ 但是，這可能更多是IDE的問題：沒有人說過需要一次編輯一個文件。 編輯器只能顯示一種模塊類/方法（例如在Smalltalk IDE中）。 蛋糕圖案也不是沒有問題 。 而且，嵌套模塊呢？

DI框架

最后，我們有各種DI框架 （例如Guice，Spring或CDI），如果從適當的角度來看，我們在其中定義了可以依賴于其他模塊（由容器注入）的小模塊（類）。 將模塊接口（java接口）與模塊實現（java類）分開，并且僅注入接口也是很常見的。 但是，再次重申，部分靜態地防止注入實現的唯一方法是，我們不得不求助于創建單獨的-api和-impl Maven模塊。

實際上，如果我們采用嵌套類的方法，那么DI框架可能非常適合解決模塊間的依賴關系并為我們完成所有連接（如果我們想避免出現以下情況，這將非常有用：模塊具有新的依賴關系，并且現在必須修改每個使用站點）。

下一個？

綜上所述，我認為支持模塊化的各種方法可以使用某種統一性。 而且，不幸的是，這可能意味著完全偏離我們今天從Java / Scala所了解的：新的軟件包系統，新的構建系統，新的運行時系統。 不幸的是，新的編程語言的出現在該領域提供的內容并不多。

您是否認為應該有一個模塊系統，可在小型（單個類）和大型（類集）中使用？ 畢竟， DI容器用來解決依賴關系和實例化類的操作與啟動時Maven或OSGi運行時的操作沒有太大不同！

還是模塊固有地具有幾種類型，小型（類級別）和大型（maven模塊/ osgi捆綁包級別）？

最后，也許還有其他一些非基于JVM的語言可以更好地解決模塊化問題（仍然可用）？

參考： 模塊，模塊，模塊…來自我們的JCG合作伙伴 Adam Warski 。

• JBoss模塊示例–模塊化Web應用程序
• 真正的模塊化Web應用程序：為什么沒有開發標準？
• OSGi將Maven與Equinox結合使用
• Java最佳實踐系列
• Java教程和Android教程列表