管理配置文件的最佳方法是什么？

Question

我和一位同事正在讨论管理配置文件的最佳实践，并希望从其他人那里获得进一步的反馈。我们的目标是让配置文件指定在发生某些事件时应采取什么操作。

我们正在辩论的两个选项是：

1. 在配置文件中，指定实现要执行的操作的类路径（例如：“ActionToTake”：“com.company.publish.SendEveryoneAnEmailClass”）。在代码中，当遇到此事件时，我们可以执行 Class.forName(config.ActionToTake).newInstance().run() 以调用指定的操作。 2. 在配置文件中，用人类可读的短语指定应采取的操作（例如：“ActionToTake”：“SendEveryoneAnEmail”）。在代码中，当遇到此事件时，我们可以解析 config.ActionToTake，并执行将其转换为操作实现的映射（例如：new SendEveryoneAnEmailClass().run()）。

我们目前是一个非常小的团队，目前只有我们的软件开发团队阅读/使用此配置文件。但未来是否会继续如此还不清楚。

对选项1的推理：任何阅读配置文件的人都将明确并立即知道将调用哪个类以及它在哪里实现。这也允许操作类从完全独立的JAR文件中实现/导入，而无需重新编译/更改我们的代码。

对选项2的推理：配置文件应该是用户意图的高级描述，不应包含实现细节，例如特定的类名和包路径。还可以重构类/包名称，而无需进行配置文件更改。

对于配置文件，您认为哪种设计哲学更好？

- RvPr

---

另外对我来说最重要的选项（1）的优势是，稍后您可以配置ActionToTake成一个甚至还没有编写过的类（或其他人可以使用他们自己的类配置它），而不需要更改调用操作上的运行代码。 这很像Spring IOC的配置文件工作方式，以及IDE（如Eclipse）在重构类和包名称时将可选地包括XML配置文件。 - jas

Answer 1

第一种选项的优势在于，正如jas所指出的，它具有将代码“链接”到未来的能力。只有在您将软件作为闭源包销售/分发或计划在生产中热交换行为时，它才是真正的优势。您已经指出了缺点-重构。

第二个选项：

• 它不能帮助您进行重构。如果您将操作从SendEmail更改为BringBeer，但保留字符串send email，则失败了。
• 可读性。 send-everyone-an-email与SendEveryoneAnEmail一样好。每个开发人员都会知道会发生什么。它不会与LaunchRockets混淆。您的代码可以基于某些文本查找类，而不一定是完全限定名称。除非明确提供，否则您的代码可以假设操作位于某个特定包中。这是结合两个选项的方法。

还要考虑另一个可能性：在代码中进行配置。如果您不想重新编译软件包，可以使用脚本语言（groovy）。它允许您创建非常易读的DSL，并且您将拥有重构。

- piotrek

---

谢谢您的回复。您能否澄清一下您所说的以下内容的含义：“它对重构没有帮助。如果您将操作从SendEmail更改为BringBeer，但是您仍然保留字符串send email，则失败了。”我想到的第二个选项的示例是，当config.ActionToTake.equals（“SendEveryoneAnEmail”）时，您拥有某种映射/ case语句，它将创建SendEveryoneAnEmailClass的实例。在这种情况下，如果您在IDE上重构类的名称，则不需要进行进一步的更改。但是在第一个选项中，您还需要手动编辑配置文件。 - RvPr

我现在明白你的观点了。你指的是我们想要改变行为本身性质的情况（比如SendEmail和BringBeer）。而我所说的重构是指像命名更改（SendEveryoneAnEmail vs SendEveryoneMail）或包路径更改这样的小改动。对于这种格式更改，如果你使用第二个选项，IDE可以非常容易地完成所有工作，无需进一步的工作。但是对于第一个选项，需要额外的工作来更改配置文件中的所有类路径，我认为这是第一个选项的缺点。 - RvPr

@RvPr 忘了提到 - 你可以添加测试，检查所有配置文件是否包含有效数据/现有类。 - piotrek