当前位置：文江博客话题详情

全局常量是反模式吗？

发布于 2024-07-30 15:09:34 字数 237 浏览 5 评论 0原文

我一直认为仅仅为了保持常量而创建一个类是一个糟糕的设计。但最近，我尝试用谷歌搜索它，发现只有一个接口作为常量是不好的反模式 - 没有提到使用一类常量。

我认为，由于常量类实际上与全局变量没有太大区别，这就是我反对它并倾向于重构此类类的原因。它创建了一类完全没有上下文的数据。这些常量最好与实际使用它们的任何东西联系起来，为它们提供上下文和含义，并将它们封装在一个类中。

其他人怎么看？

原文

分享到QQ

分享到微博

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

发布评论

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

羁拥 2024-08-06 15:09:35

全局常量没问题。

全局（非常量）变量是魔鬼的杰作。

回复收藏 0 原文

北陌 2024-08-06 15:09:35

全局常量并不是坏习惯，只要它们......

不可变 - 对可变对象（如 Java ArrayList 或 C# List) 不是常量，而是全局状态。
...>1 类需要。如果只有一个类需要常量，请将常量直接放在类中。（警告：适当平衡 DRY 与 YAGNI。）

Bloch 在《Effective Java》中讨论了“常量接口”与“常量类”问题，并提倡“常量类”方法。您不希望接口中存在常量的原因是它会诱使客户端类“实现”该接口（以便访问常量而不用接口名称作为前缀）。不过，您不应该这样做 - 该接口实际上并不是对象功能的接口，而是类的外部类型中根深蒂固的编译时便利性。考虑一下：

interface C { public static final int OMGHAX = 0x539; }
class A implements C { ... }
class B { private A a; }

类 B 现在不必要地依赖于 C。如果 A 的实现发生更改，使其不再需要 C 中的常量，则您无法在不破坏的情况下从中删除 implements C它的外部接口 - 某人（可以说是一个非常愚蠢的人，但这样的人比比皆是）可能通过 C 引用来引用 A 对象！

通过将常量放入类中，并使该类不可实例化，您可以告知客户端常量类实际上只是充当子命名空间。在 C# 中，您将类标记为 static，在 Java 中，您希望将其设为 final 并提供一个无法访问的构造函数：

final class C { 
    private C() { throw new AssertionError("C is uninstantiable"); }
    public static final int OMGHAX = 0x539; 
}

如果您在 Java 中编程并希望常量不带前缀它们带有常量类名，您可以使用import static功能。

是的，仅仅为了有地方放置常量而被迫创建一个新类型有点多余，但这是 Java 和 C# 等语言中我们必须处理的一个问题 - 我们必须将我们的常量放在某个地方，而我们最好的选择恰好是一个不可实例化的类。

Global constants aren't bad practice, as long as they are...

... immutable - a global, final/readonly reference to a mutable object (like a Java ArrayList<T> or a C# List<T>) is not a constant, but global state.
... needed by >1 class. If only one class needs your constants, put the constants directly in the class. (Caveat: Balance DRY vs YAGNI appropriately.)

Bloch covers the "constant interface" vs. "constant class" issue in Effective Java, and advocates the "constant class" approach. The reason why you don't want the constants in an interface is that it entices client classes to "implement" that interface (in order to access the constants without prefixing them with the interface name). You shouldn't, though - the interface isn't actually an interface to the object's capabilities, but a compile-time convenience ingrained in the class' external type. Consider this:

interface C { public static final int OMGHAX = 0x539; }
class A implements C { ... }
class B { private A a; }

Class B now unnecessarily has a dependency to C. If the implementation of A changes so that it doesn't need the constants from C, you can't remove implements C from it without breaking its external interface - someone (arguably a very stupid person, but such people abound) might reference an A object through a C reference!

By putting the constants in a class, and by making that class uninstantiable, you inform clients that the constant class really just functions as a sub-namespace. In C# you mark the class as static, in Java you'd want to make it final and give an unreachable constructor:

final class C { 
    private C() { throw new AssertionError("C is uninstantiable"); }
    public static final int OMGHAX = 0x539; 
}

If you program in Java and want the constants without prefixing them with the constant class name, you can use the import static functionality.

And yes, it's slightly redundant to be forced to create a new type just to have somewhere to put your constants, but that's a wart in languages like Java and C# that we have to deal with - we have to put our constants somewhere, and our best option happens to be a non-instantiable class.

回复收藏 0 原文