2010-11-10 47 views
13

我最近遇到一個編碼標準,聲稱你應該使用從不使用使用public Java中的內部枚舉/類。這是我第一次遇到這個慣例,並且一直未能找到令人滿意的解釋。千萬不要使用公共嵌套枚舉?

我明白爲什麼應該避免公開內部類,但是爲什麼你不會使用公共嵌套枚舉呢?或者,爲什麼這是一個糟糕的慣例?

+0

你從哪裏讀到的?你能指出那篇文章嗎 – 2010-11-10 22:00:43

+2

當你說你「遇到」這個標準時。如何和在哪裏。毫無疑問,它會給出一些推理。 – David 2010-11-10 22:02:06

+0

不幸的是,我無法鏈接到源,因爲它是以公司內部電子郵件的形式。推理很簡短,並提到調試更簡單,遵循Java約定。 – AEW 2010-11-10 22:10:24

回答

12

免責聲明:以下不是硬性規定。這些只是我的意見和個人喜好。我個人發現它使我的代碼更易於閱讀和維護。

第一個問題。你從哪裏看到這個建議?他們提供了任何理由嗎?

以我的經驗,我通常使用私有嵌套枚舉來增強我的代碼的可讀性和可維護性。當您與另一個系統進行集成時,這尤其會發揮作用,並且您必須發送特定的字符串或數字。我發現使用枚舉可以使事情更容易閱讀和維護。在這個特定的情況下,enum傳遞的信息在範圍上受限於類(即在類之外沒有意義,也沒有其他人需要它)。

我想不出一個明確的理由,說明爲什麼公共內部枚舉是一個不好的做法。但這裏有原因,我不(正常)使用它們:

  • 如果枚舉是公開的,這基本上意味着它傳遞了在更大範圍內的信息(即是有道理的父類的範圍之外所以它可能意味着其他東西正在使用它)。如果是這種情況,那麼將其作爲獨立枚舉可能更有意義。
  • 我覺得它更容易在眼睛ThirdPartyResponseCodes.Success而不是ThirdPartyIntegrationInterface.ThirdPartyResponseCodes.Success。沒有理由不能正確命名枚舉來提供上下文,從而使其成爲獨立枚舉。
  • 我會想象不使用公共內部類的相同原因也適用於公共內部枚舉。首先,如果你有一個內部類,這可能意味着你的外部類可能從重構中受益。也許你的外部班級試圖做太多?另一方面,有封裝和限制範圍的好處,特別是如果你可以說內部類只在外部類的上下文中有意義(這應該不用說它是私有的)。如果它是一個公共的內部類,那麼這可能意味着它的範圍超出了外部類,因此需要將其拉出。
  • 如果您確實需要使用公共嵌套枚舉,那麼您應該準確記錄爲什麼您需要它(我還沒有找到理由這樣做),爲什麼最好將它作爲公共嵌套枚舉而不是公共獨立的枚舉。
+0

我是AEW的同事。關於第3點,所討論的類是基於java TimeUnit模式的單位長度類,但它也在內部保持了值(在本機單元中)。我覺得這是一個非常明顯的封裝和限制範圍的情況。 – swarfrat 2010-11-11 16:08:56

0

原因可能是它使得這些枚舉難以在它們聲明的類之外使用,因爲你必須用封閉類的名稱來限定它們。當然,對於任何公共內部階層來說也是如此。我不確定我是否同意 - 當然不是一個硬性規定。

0

如果不包含解釋,你必須詢問編寫該編碼標準的人。然而,你的這種說法是有點混亂:

我明白爲什麼大衆內部類 應避免,但什麼原因 你會不會使用公共 嵌套枚舉?

你爲什麼認爲應該避免公開內部類?爲什麼這個原因不適用於枚舉?

+0

請參閱http://onjava.com/pub/a/onjava/excerpt/HardcoreJava_chap06/index.html。內部類在包含類之外使用時具有奇怪的構造函數。這與嵌套的(即靜態的)類不同,嵌套的枚舉是如何工作的。 – AEW 2010-11-10 22:27:40

+0

這不僅僅是一個回答而是一個評論。 – 2016-12-17 07:08:59