常量和可维护性

Question

我有一个与良好的编程实践相关的简单问题。具体地说，我对处理分组常量的正确方式很好奇。在学校，他们教我们把我们的常量放在第一个声明它们的文件的顶部(通常是一个类文件，教授有一些变化)。现在，我在行业中的几个地方看到，所有常量都被提取出来并滚动到一个大的包含类型的文件中。

在第一种情况下，提取常量是有意义的，因为这是手机游戏的代码，必须快速移植到各种令人惊叹的设备上，这提供了一个集中的工作场所。但是，后来我发现这种做法的重复是一个完全不同的场景(公用事业的内部代码)，几乎没有理由解释为什么会这样(基本上，“因为他一直都是这样做的”)。

那么，最佳实践是什么呢？我知道这可能看起来很平凡，但我一直被告知，尽早养成好习惯是成功的关键。

Answer 1

平等对待所有常量通常是过于简单化的。每个词在其上下文中都有不同的含义，我对待它们的方式也相应地不同。下面是一个关于上下文与我如何在这个上下文中处理常量的小表。如果你认为有更好的方法，请纠正我。

• 配置参数:尽可能地将代码=>出到配置文件或数据库中。
• UI字符串：=>位于资源文件中(为了便于维护和枚举enums: Enums很好地包装了同一上下文中的多个常量(例如，星期几、连接状态...))。我通常将定义放在与使用相同的包中，或者如果多个程序集/组件将使用it.
• Global/static对象，则将其放在共享库中:我检查我的设计，看看是否可以应用framework).
• Test或factory模式(或者在测试方法中注册对象)。DI测试期望:我通常在测试方法中保留它们的原样，用于测试编号:我很少使用它们；可能会将它们放在语义相关的类中。

其他常量有它们自己的上下文。我喜欢将常量移出代码，因为不管听起来多么自相矛盾，常量往往会改变。

出于同样的原因，将所有常量放在一个大文件中是不好的。假设你的一个程序集只依赖于常量X。即使常量Y改变了，这个程序集也必须重新编译，而且这个改变应该是已经影响了它。

Answer 2

为了给出一个过于简单的答案，我认为最好把它们放在你期望找到它们的地方。意思是，对它们进行分类。这与cohesion principle有关。这样做的好处是，当你需要它们时，你会发现它们更容易。您可以轻松地只包含所需的常量，而不会因为其他未使用的常量而污染您的命名空间。

另一个重要的注意事项是，如果可能的话，将相关常量分组到枚举中。例如，对齐常量将进入枚举对齐。