千万不要使用公共嵌套枚举？

Question

我最近遇到一个编码标准，声称你应该使用从不使用使用public Java中的内部枚举/类。这是我第一次遇到这个惯例，并且一直未能找到令人满意的解释。

我明白为什么应该避免公开内部类，但是为什么你不会使用公共嵌套枚举呢？或者，为什么这是一个糟糕的惯例？

Answer 1

免责声明：以下不是硬性规定。这些只是我的意见和个人喜好。我个人发现它使我的代码更易于阅读和维护。

第一个问题。你从哪里看到这个建议？他们提供了任何理由吗？

以我的经验，我通常使用私有嵌套枚举来增强我的代码的可读性和可维护性。当您与另一个系统进行集成时，这尤其会发挥作用，并且您必须发送特定的字符串或数字。我发现使用枚举可以使事情更容易阅读和维护。在这个特定的情况下，enum传递的信息在范围上受限于类（即在类之外没有意义，也没有其他人需要它）。

我想不出一个明确的理由，说明为什么公共内部枚举是一个不好的做法。但这里有原因，我不（正常）使用它们：

• 如果枚举是公开的，这基本上意味着它传递了在更大范围内的信息（即是有道理的父类的范围之外所以它可能意味着其他东西正在使用它）。如果是这种情况，那么将其作为独立枚举可能更有意义。
• 我觉得它更容易在眼睛ThirdPartyResponseCodes.Success而不是ThirdPartyIntegrationInterface.ThirdPartyResponseCodes.Success。没有理由不能正确命名枚举来提供上下文，从而使其成为独立枚举。
• 我会想象不使用公共内部类的相同原因也适用于公共内部枚举。首先，如果你有一个内部类，这可能意味着你的外部类可能从重构中受益。也许你的外部班级试图做太多？另一方面，有封装和限制范围的好处，特别是如果你可以说内部类只在外部类的上下文中有意义（这应该不用说它是私有的）。如果它是一个公共的内部类，那么这可能意味着它的范围超出了外部类，因此需要将其拉出。
• 如果您确实需要使用公共嵌套枚举，那么您应该准确记录为什么您需要它（我还没有找到理由这样做），为什么最好将它作为公共嵌套枚举而不是公共独立的枚举。

Answer 2

原因可能是它使得这些枚举难以在它们声明的类之外使用，因为你必须用封闭类的名称来限定它们。当然，对于任何公共内部阶层来说也是如此。我不确定我是否同意 - 当然不是一个硬性规定。

Answer 3

如果不包含解释，你必须询问编写该编码标准的人。然而，你的这种说法是有点混乱：

我明白为什么大众内部类 应避免，但什么原因 你会不会使用公共 嵌套枚举？

你为什么认为应该避免公开内部类？为什么这个原因不适用于枚举？