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

Question

一位同事和我正在讨论管理配置文件的最佳实践，我们想从其他人那里获得一些进一步的反馈。

我们的目标是让配置文件指定在发生特定事件时应采取的操作。

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

1. 在config-file中，指定类的类路径，该路径实现要采取的操作（例如：“ActionToTake”：“com.company.publish.SendEveryoneAnEmailClass”）。 在代码内部，当遇到此事件时，我们可以执行 Class.forName（config.ActionToTake）.newInstance（）。run（）以调用指定的操作。

   < / LI>

2. 在配置文件中，在人类可读短语中指定应采取的操作（例如：“ActionToTake”：“SendEveryoneAnEmail”）。在代码内部，遇到此事件时，我们可以解析config.ActionToTake，并执行映射，将其转换为操作实现（例如：new SendEveryoneAnEmailClass（）。run（））

我们目前是一个非常小的团队，目前唯一阅读/使用此配置文件的人是我们的软件开发团队。但目前还不清楚这是否会继续成为现实。

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

选项2背后的推理：配置文件应该是用户意图的高级描述，并且不应包含实现细节，例如特定的类名和＆amp;包路径。也可以在不必更改配置文件的情况下重构类/包名称。

关于配置文件首选哪两种设计理念？

Answer 1

正如jas所注意到的，第一个选项的优势在于能够链接＆＃39;将来的代码。只有当您将软件作为封闭源代码包销售/分发或者您计划在生产中进行热交换行为时，它才是真正的优势。你已经指出了重构 - 重构

第二个选项：

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

还要考虑另一种可能性：在代码中进行配置。如果您不想重新编译包，可以使用脚本语言（groovy）。它可以让你创建非常易读的dsl，你将进行重构。