从不使用公共嵌套枚举？

发布于 2024-10-01 20:00:09 字数 164 浏览 0 评论 0原文

我最近遇到一个编码标准，声称您不应该永远在 Java 中使用公共内部枚举/类。这是我第一次遇到这个约定，并且无法找到令人满意的解释。

我明白为什么应该避免公共内部类，但是出于什么原因你永远不会使用公共嵌套枚举？或者，为什么这是一个不好遵循的惯例？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

坏尐絯 2024-10-08 20:00:09

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

首先是一个问题。您从哪里看到这个建议？他们有提供任何理由吗？

根据我的经验，我通常使用私有嵌套枚举来增强代码的可读性和可维护性。当您执行与另一个系统的集成并且必须发送特定的字符串或数字时，这一点尤其重要。我发现使用枚举使事情更容易阅读和维护。在这种特定情况下，枚举传达的信息仅限于类的范围（即，它在类之外没有任何意义，并且其他人不应该需要它）。

我想不出一个明确的理由来说明为什么公共内部枚举是一种不好的做法。但以下是我（通常）不使用它们的原因：

如果枚举是公共的，则本质上意味着它在更大的范围内传递信息（即，在其父类的范围之外有意义，因此这可能意味着其他东西正在使用它）。如果是这种情况，那么将其设为独立的枚举可能更有意义。
我发现 ThirdPartyResponseCodes.Success 比 ThirdPartyIntegrationInterface.ThirdPartyResponseCodes.Success 更直观。您没有理由不能适当地命名枚举以提供上下文，从而使其成为独立的枚举。
我想不使用公共内部类的相同原因也适用于公共内部枚举。首先，如果您有内部类，则可能意味着您的外部类可能会从重构中受益。也许你的外层阶级试图做的事情太多了？但另一方面，封装和限制范围有好处，特别是如果您可以提出内部类仅在外部类的上下文中有意义的论点（如果它是私有的，则不用说）。如果它是一个公共内部类，那么这可能意味着它的范围超出了外部类，因此需要将其删除。
如果您确实需要使用公共嵌套枚举，那么您应该准确记录为什么需要它（我还没有找到这样做的理由）以及为什么最好将其保留为公共嵌套枚举而不是公共独立枚举。

Disclaimer: The following are not hard and fast rules. These are just my opinions and personal preferences. I personally find that it makes my code easier to read and easier to maintain.

First a question. Where did you come across this advice? Did they provide any rationale?

In my experience, I've normally used private nested enums to enhance readability and maintainability of my code. This especially comes into play when you're performing an integration with another system and you have to send in specific strings or numbers. I find that using an enum makes things easier to read and maintain. In this specific case, the information conveyed by the enum is limited in scope to the class (i.e., it makes no sense outside the class and no one else should need it).

I can't think of a definitive reason that says why public inner enums are a bad practice. But here are reasons why I don't (normally) use them:

If the enum is public, it essentially means that it conveys information in a larger scope (i.e., makes sense outside the scope of its parent class and so it probably means that other things are using it). If this is the case, then it might make more sense to make it a standalone enum.
I find it ThirdPartyResponseCodes.Success easier on the eyes rather than ThirdPartyIntegrationInterface.ThirdPartyResponseCodes.Success. There is no reason why you cannot name the enum appropriately to provide context and thus make it a standalone enum.
I would imagine that the same reasons for not using public inner classes also apply to public inner enums. First of all, if you have an inner class, it may mean that your outer class might benefit from refactoring. Perhaps your outer class is trying to do too much? On the flip side though, there is the benefit of encapsulation and limiting scope, especially if you can make the argument that the inner class only makes sense in the context of the outer class (which should go without saying if it is private). If it is a public inner class, then that probably means that its scope extends past the outer class and thus it would need to be pulled out.
If you really do need to use a public nested enum then you should document exactly why you would need it (I haven't found a reason to do so yet) and why it is better to leave it as an public nested enum and not a public standalone enum.

回复收藏 0 原文