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

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 背后的原因:配置文件应该是用户意图的高级描述，不应包含具体类名和包路径等实现细节。类/包名称的重构也可以在不更改配置文件的情况下完成。

关于配置文件首选这 2 种设计哲学中的哪一种？

Answer 1

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

第二个选项:

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

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