java靜態導入

曾經有一段時間，至少在禮貌的社會中，人們普遍認為使用“ 不是 ”一詞是不可接受的。 確實，在那個時候（也許直到今天），很多人確實（也確實）不認為這不是一個真實的詞。 盡管這個詞并沒有 引起爭議，并且它的用法仍然經常被認為是不恰當的，但是它似乎正在慢慢地獲得普遍的接受，并在使用頻率上占有一席之地。 一次，“了解更多的人” 有意使用它來強調，但在受歡迎程度方面似乎正在慢慢地得到普及。 在許多方面， J2SE 5引入的靜態導入似乎與使用“不是”一詞類似。

引用了《 J2SE 5編程語言指南 》中有關靜態導入的部分（重點是原始內容的一部分）：“那么，什么時候應該使用靜態導入？ 非常謹慎！ ”部分的最后一段描述了何時最好使用靜態導入：

那么什么時候應該使用靜態導入？ 非常謹慎！ 僅當您打算以其他方式聲明常量的本地副本或濫用繼承（ Constant Interface Antipattern ）時，才使用它。 換句話說，當您需要頻繁訪問一兩個類的靜態成員時，請使用它。 如果您過度使用靜態導入功能，它將使您的程序無法讀取和不可維護，并使用您導入的所有靜態成員污染其名稱空間。 代碼的讀者（包括您，在您編寫代碼后的幾個月內）不會知道靜態成員來自哪個類。 從類中導入所有靜態成員可能對可讀性特別有害； 如果只需要一個或兩個成員，則分別導入它們。 通過適當地使用，靜態導入可以消除類名重復的樣板，從而使您的程序更具可讀性。

就像“不是”一詞一樣，受過良好教育的Java開發人員似乎幾乎普遍同意應盡量少使用靜態導入。 這里的理由很明顯。 首先，官方文件是這樣說的。 其次，更重要的是，毫無疑問，過度使用靜態導入實際上可能導致可讀性差的代碼，即使它更簡潔。 實際上，過多的靜態導入可能會導致沖突 ，從而導致大量使用靜態導入的能力喪失。 盡管已經意識到并承認了靜態導入的弊端和潛在濫用，但是Java社區似乎越來越多地使用它。

在編寫簡單的示例來說明要點時（例如本博客中的帖子），我經常不用理會日志記錄框架，而是簡單地使用System.out和System.err 。 我不介意假設我的代碼中對out任何引用均指標準輸出的句柄，而對err任何引用均指標準錯誤的句柄。 我不打算在任何其他情況下使用out或err ，因此這為簡單的代碼帶來了簡潔性，而又不會降低可讀性或增加歧義。 這也很像Groovy的寫標準輸出的方法（盡管不那么簡潔）。 您可以在Java靜態導入中找到有關此方法的更多詳細信息：System.out和err ，在我的文章Static Imports和System.out中 ，以及在Cay Horstmann的文章中， 您正在使用靜態導入嗎？

在Java世界中，也許甚至更普遍地使用靜態導入以單元測試的名義出現。 幾個最流行的面向Java的單元測試框架都鼓勵使用靜態導入來實現更流暢的測試代碼。 JUnit的的斷言方法 ， 的Mockito的的Mockito方法 ，以及Hamcrest的匹配器是一些靜態導入的使用在Java單元測試世界流行的最明顯的例子。

在《 我不喜歡Java的靜態導入》一文中 ，Mark Needham描述了一種情況，我認為許多Java開發商店都在涉及靜態導入時遇到了這種情況：

在我的上一個項目中，我們最后說在測試代碼中允許導入static，因為可以從中導入static方法的地方相對較少，但是當涉及生產代碼時，則需要完全限定的路徑。

甚至在測試代碼中使用靜態導入也不是沒有問題或爭議的。 查找Mockito構造的導入靜態語句的StackOverflow線程討論與使用靜態導入相關的一些挫敗感。 Needham也解決了這個問題 ：

這種方法的優點是使代碼閱讀更流暢，但缺點是您無法立即知道方法的位置。 我希望能夠通過查看它來告訴代碼中發生了什么，以及防止這一切的任何障礙。

到目前為止，我已經研究了Java靜態導入與java.lang.System.out調用以及單元測試的結合使用。 這兩種情況都不是典型的生產代碼案例（在生產中，使用日志記錄框架進行日志記錄要比標準輸出更好，并且單元測試不是生產代碼 ，盡管它們可能隨其一起提供）。

哪個用于生產代碼的Java框架鼓勵使用靜態導入可能不太明顯。 一個例子是lambdaj 。 lambdaj功能 Wiki頁面通過建議使用靜態導入開始： 在Lambda類中，所有這些功能均作為靜態方法提供，因此，使用它們的最佳方法是添加以下導入：

import static ch.lambdaj.Lambda.*;

在您要使用它的類中。

更一般的情況下，使用的Java使用靜態導入的是發展的領域特定語言 （ DSL在S） 的Java 。 在許多方面，已經在本文中針對JUnit，Mockito，Hamcrest和Lambdaj討論過的靜態導入的使用是這種更趨向于流暢接口和DSL的普遍趨勢的具體示例。

出于充分的理由，我相信大多數Java開發人員對于過度使用和濫用靜態導入都持謹慎態度。 但是，在適當情況下更多地使用靜態導入似乎是玩弄這些靜態輸入并了解它們的正面和負面結果的結果。 JVM腳本語言和其他更簡潔（較少儀式）的語言的興起也可能影響了有關使用靜態導入的一般思考 。

流利的接口（靜態導入的正作用）的驅動器必須與使用靜態導入相關的維護和可讀性成本進行比較。 總的來說，正如我認為“不是”仍然被人們所皺眉，但也許不像以前那樣被皺眉，我也認為仍然不鼓勵靜態導入，但是作為Java社區的我們也許已經開始了看看他們可能還可以，甚至值得付出代價的積極功能。 我認為沒有人認為經常使用它們而不考慮使用它們的上下文是一個好主意。

參考： Java中越來越多地接受靜態導入嗎？ 由我們的JCG合作伙伴 Dustin Marx在“ 實際事件啟發”博客中獲得。

翻譯自: https://www.javacodegeeks.com/2012/04/are-static-imports-becoming.html

java靜態導入

總結

以上是生活随笔為你收集整理的java静态导入_Java中越来越多地接受静态导入吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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