拼圖問題為1000。我作為X想要JPMS模塊。 如果不是平臺開發人員，X是什么？

我的回答是X是人（減去平臺開發人員，因為那是一個條件） 。 我們都需要模塊系統具有更安全的代碼，從而產生更可靠的系統，從而帶來更好的業務績效，帶來更好的經濟效益并帶來人類幸福。 也許我得出的結論有點過頭了，但重點是，無論是否意識到，行業內的每個人都需要模塊系統。 你會得到的。 首先，我們應該從問題的先前答案開始。

Nicolai Parlog說： 每個類型不是全部公開的庫開發人員。

非常真實 作為一個庫開發人員，我想設計我的庫，以便分離API。 我希望將公共接口與實現分開。 這就是我們程序員所說的“封裝”。 封裝起來太好了。 我們喜歡這樣做！ 我們這樣做，因為它很有趣！ 我們喜歡它！

關于第二個想法，盡管我們這樣做是因為它是一種創建可靠的無錯誤軟件的工具。

它幫助使用我的代碼封裝內部狀態和實現的代碼開發人員編寫更好的代碼。 這有點像撫養孩子。 作為父母，我不允許他們做某些事情。 多吃巧克力，熬夜等等。 即使他們暫時看不到它，這也是為了他們自己的利益。 當然，后來，當他們長大并自己成為父母時，他們將理解并做同樣的事情。 對于庫開發人員和使用程序員的庫來說，沒有什么不同，除了，也許程序員永遠不會長大。

同樣，作為圖書館開發人員，我要使用JPMS，以便于使用我的代碼的開發人員。 我的庫不會僅僅因為封裝而好壞。 （附帶說明：這會更好，但不是因為其中的錯誤數量減少了。）我可以很容易地暗示我作為圖書館開發人員的需求最少。 親愛的程序員，誰在乎您是否使用我的庫來射殺您的睪丸？ 您有責任僅調用公共API，而不是一些經常修改的內部類和方法。 還是？

并不是的。 創建易于使用且難以出錯的庫也是我的責任。 這就是我們所說的可用性。 這是JPMS模塊系統出現的地方。 沒有JPMS，我可以記錄哪些軟件包是公共的，哪些是特定于實現的。 我與圖書館用戶之間的約定是，他們將不使用圖書館的私有資源，因此，出于這種良好行為，我將使圖書館的公共部分保持穩定，以便他們無需在發行版本之間更改代碼。 。 （順便說一句，有沒有人意識到這個名字，jPMS是多么的血腥？是什么？PMS，真的嗎？更不用說看到與此有關的所有抽筋了：nomen est omen。這不是幸運的洗禮。）

讓我們回到軌道上：為什么我們需要為此使用模塊系統？ 開發人員是紀律嚴明的人，他們不想傷害自己。 他們不應該，也不會使用庫的內部代碼。 從長遠來看，這對他們不利，他們深知這一點。 從長遠來看這很麻煩。 從長遠來看，我們都死了。 在開發過程中，通常會在發布日期之前的幾天，使用某個庫的某些內部API似乎很有利可圖。 以某種怪異的方式，這些內部調用正是您所需要的。 您知道不應該使用它們，并且有一個很好的，禮貌的解決方案，但這需要更多的時間來開發。 只是隨著發布日期的臨近，您沒有時間遵循這種模式。 更不用說為“我能做到”而自豪，“我對這些工具的了解程度”，而不是為羞辱篡改圖書館的私有部分而感到自豪。

這就是Java Module System出現的地方。 您將無法執行快捷方式。 您會感嘆過去Java面向全世界開放的美好時光，無論類加載器上有什么（更不用說FORTRAN編程，對還是對？），但是您將遵循規則，因為它否則將無法正常工作。

您認為使用庫的內部組件并不容易受到虛榮的影響。 這是一個測試：您是否認識到我使用了“庫的內部API”這一表達？ 如果沒有，那就感到羞恥，但不要承認。 沒必要。 Java模塊系統將有助于忘記不存在的事物，例如內部API。 廢話。 API是公開的。 沒有內部API之類的東西。 生成的代碼將更好，更易于維護，不容易進行庫升級，從而降低成本。

從長遠來看，當我們全都死了時，我們的后代將創建更好的代碼，并且具有模塊級封裝將是顯而易見的事情，就像那時世界和平一樣。

因此，我需要Java模塊系統，您需要它，其他每個人都需要它來建立一個更好的世界并實現世界和平。

免責聲明：本文的作者沒有以英語為母語

翻譯自: https://www.javacodegeeks.com/2017/05/needs-java-modules.html

總結

以上是生活随笔為你收集整理的谁最终需要Java模块？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。