design-patterns - 常量和可维护性

Question

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

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

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

Answer 1

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

• 配置参数:=> 尽可能在代码之外，配置文件或数据库。
• UI 字符串:=> 在资源文件中(便于维护和本地化)。
• 可能的枚举:枚举很好地包装了同一上下文中的多个常量(例如，星期几、连接状态...)。我通常将定义放在使用它的同一个包中，或者如果多个程序集/组件将使用它，则将其放在共享库中。
• 全局/静态对象:我检查我的设计，看看是否可以应用 singleton 或 factory 模式(或在 DI 框架中注册对象)。
• 测试期望:为了便于阅读，我通常将它们保留在测试方法中。
• “神奇”数字:我很少用到它们；可能会将它们留在语义相关的类中。

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

出于同样的原因，将所有常量放在一个大文件中是不好的。假设您的一个程序集仅依赖于常量 X。即使常量 Y 发生变化，该程序集也必须重新编译，并且这种变化应该不会影响它。