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

Question

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

我们的目标是让配置文件指定在某些事件发生时应采取的行动。

我们正在讨论的 2 个选项：

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

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

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

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

选项 2 背后的原因：配置文件应该是对用户意图的高级描述，并且不应包含诸如特定类名和包路径之类的实现细节。类/包名称的重构也可以在无需更改配置文件的情况下完成。

对于这两种设计理念中的哪一种更适合配置文件的想法？

Answer 1

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

第二个选项：

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

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