常数和可维护性

时间:2010-11-04 03:25:26

标签: design-patterns constants

我有一个与良好编程实践相关的简单问题。具体来说,我很好奇处理分组常量的正确方法。在学校里,他们教我们把我们的常数放在文件的顶部,在这个文件中它们被宣告(通常是一个类文件,教授有一些变化)。现在,我已经在业界的几个地方看到了所有常量被拉出并卷成一个大的包含类型文件。

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

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

2 个答案:

答案 0 :(得分:3)

平等对待所有常数通常过于简单化。每个人在其背景中都有不同的含义,我对待它们的方式也各不相同。下面是一个小的上下文表格,以及我在这种情况下如何处理常量。如果您认为有更好的方法,请纠正我。

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

其他常量有自己的上下文。我喜欢将常量移出代码,因为它听起来很矛盾,常量倾向于更改

出于同样的原因,将所有常量放在一个大文件中是不好的。假设你的一个程序集只依赖于常数X.即使常数Y发生变化,也必须重新编译这个程序集,而这个变化会影响它。

答案 1 :(得分:0)

为了给出一个过于简化的答案,我认为最好将它们放在您希望找到它们的位置。意思是,对它们进行分类。这与cohesion principle有关。这样做的好处是,您可以在需要时更轻松地找到它们。您可以轻松地仅包含所需的常量,而不会使用其他未使用的命名空间来污染您的命名空间。

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