【发布时间】：2011-02-06 17:43:18
【问题描述】：
在我的应用程序中，我使用了一些图标。我应该在哪里存储包含这些图标的目录的路径？
图标在不同的类中使用，因此将它们存储在这些类中没有任何意义。
我读到全局变量是邪恶的，但是使用只包含public static final 字段的类（例如Commons）来存储这个数据之王是否可以接受？在专业应用中使用什么解决方案？
【问题讨论】：
标签： java global-variables
【发布时间】：2011-02-06 17:43:18
【问题描述】：
全局常量
正如其他人所说，全局常量与全局变量没有相同的负面含义。由于不受控制的修改，全局变量使程序难以调试和维护。全局常量 (public static final) 不会产生同样的问题
尽管如此，面向对象是将代码绑定到其数据附近，以增强可理解性和可维护性。您仍然必须在将全局配置值存储在全局类中与将数据靠近将使用它的代码之间找到适当的平衡。
这里可能还值得提醒的是，因为编译器可能会内联一些常量，如果你改变一个常量值，你可能需要重新编译和重新部署的不仅仅是包含这些常量的类。
外化价值观
您还询问了专业应用的功能。这些应用程序使这些类型的值（如文件路径）在外部可配置的情况并不少见。这取决于值更改的可能性（即您的应用程序将移动或您的代码将在另一个应用程序中使用的可能性）以及使用新值重新编译和重新部署代码的方便或容易程度。如果您确实选择使某些值在外部可配置，您仍可能希望在代码中为这些项目编码默认值。
以下是一些将这些价值观外化的方法以及一些帮助您入门的链接。这当然不是一份详尽的清单：
- System properties 所以你可以在命令行中指定它们
- 属性文件 [参见 StackOverflow Q - How to use java property files?]
- 资源包 [参见 StackOverflow Q - How to load a resource bundle from a file resource?]
【讨论】：
全局变量是邪恶的（因为它们几乎不可能弄清楚谁修改了什么），但常量并不邪恶。 public static final String 字段很好，因为它们不能被修改。
【讨论】：
-
如果“常量”需要可配置，您可以有一个使用 Preferences 数据库的静态初始化块。
-
这将使在运行时修改（重新加载）首选项变得困难。这也会导致无法使用不同的偏好进行单元测试。
我建议将它们（图标）与你的类文件一起包含在一个 jar 中，比如一个名为资源的文件夹，只有图标加载器需要知道你的 jar 中的资源文件夹名称。
【讨论】：
-
我不确定我理解你所说的“图标加载器”是什么意思。它是一个提供静态方法来获取图标的类吗？
您指的是常量，而不是全局变量，所以不要担心它们是邪恶的——它们不是，因为它们不会改变。
- 如果它们被一个类使用 - 将它们放在该类中
- 如果它们被一个包中的多个类使用 - 将它们放在一个特殊的类中
- 如果它们被多个类使用并且它们在逻辑上属于某个地方，请将它们放在那里。
请记住，如果这些“常量”实际上是可配置的，您最好将 Configuration 对象传递给需要它的方法。好吧，您可能在某处有静态，但从可测试性的角度来看，注入/传递它们是必须的。
【讨论】：
全局变量与全局常量不同。全局变量不好的原因是它们可以在代码中的任何地方更改，并且很难追踪由于全局变量未处于预期状态而导致的错误。全局常量将始终处于其预期状态，因为它们永远不会被无意更改。
【讨论】：
一般来说，我建议这种特殊情况是一个打包问题，不要将项目引用为文件系统上的文件，而是作为类路径中的元素，并通过类加载器加载它们。这需要在应用程序的类路径中设置它们的位置。
那么应该只有一个类知道如何检索这些图标，而所有其他代码都向该类询问它需要的图标。
【讨论】：