java靜態(tài)導(dǎo)入

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

引用了《 J2SE 5編程語言指南 》中有關(guān)靜態(tài)導(dǎo)入的部分（重點是原始內(nèi)容的一部分）：“那么，什么時候應(yīng)該使用靜態(tài)導(dǎo)入？ 非常謹慎！ ”部分的最后一段描述了何時最好使用靜態(tài)導(dǎo)入：

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

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

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

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

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

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

甚至在測試代碼中使用靜態(tài)導(dǎo)入也不是沒有問題或爭議的。 查找Mockito構(gòu)造的導(dǎo)入靜態(tài)語句的StackOverflow線程討論與使用靜態(tài)導(dǎo)入相關(guān)的一些挫敗感。 Needham也解決了這個問題 ：

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

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

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

import static ch.lambdaj.Lambda.*;

在您要使用它的類中。

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

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

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

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

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

java靜態(tài)導(dǎo)入

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。