为什么某些 API（如 JCE、JSSE 等）通过单例映射提供可配置属性？

Question

例如：

Security.setProperty("ocsp.enable", "true");

并且仅在使用 CertPathValidator 时使用。我看到两个导入选项：

• 同样是单例，但每个属性都有 getter 和 setter，
• 一个对象包含与当前上下文相关的属性： (..) （它已经有一个 PKIXParameters 的设置器，这是一个好的开始，但它并不包含所有内容）

一些原因可能是：

• CertPathValidator.setValidatorProperties 来自命令行的属性 - 从命令行到上面建议的类中的默认值的简单转换器将是微不足道的，
• 允许不同提供者提供其他自定义属性 - 他们可以拥有 public Map getProviderProperties()，甚至public Object .. 带强制转换。

我很好奇，因为这些属性并不总是在最明显的地方，并且在使用 API 时无法看到它们，您必须在（如果幸运的话）获得它们之前查看数十个谷歌结果。因为——首先——你并不总是知道你到底在寻找什么。

我刚刚观察到的另一个致命缺点是这不是线程安全的。例如，如果两个线程想要通过 ocsp 检查撤销，它们必须设置 ocsp.responderURL 属性......并且可能覆盖彼此的设置。

Answer 1

这实际上是一个很好的问题，迫使您思考过去可能做出的设计决策。感谢您提出一个我几年前就应该想到的问题！

听起来反对意见与其说是单例方面（尽管对此可能会发生完全不同的讨论），不如说是字符串键的使用。

我曾经研究过使用这种方案的 API，并且您上面概述的原因绝对是驱动因素 - 它使解析命令行或属性文件变得非常简单，并且它允许第 3 方可扩展性而不影响官方API。

在我们的库中，我们实际上有一个类，其中每个官方参数都有一堆静态最终字符串条目。这给了我们两全其美的好处——开发人员仍然可以在有意义的地方使用代码完成。还可以使用内部类构建相关设置的层次结构。

尽管如此，我认为第一个原因（命令行的简单解析）并没有真正解决问题。创建一个反射驱动机制将设置推送到一堆设置器中将相当容易，并且它将防止字符串->对象转换的麻烦转移到主应用程序类中。

可扩展性有点棘手，但我认为它仍然可以使用反射驱动系统来处理。这个想法是让主配置对象（其中包含所有设置器的对象）也有一个 registerExtensionConfiguration(xxx) 方法。标准符号（可能是点分隔）可用于深入研究配置对象的结果非循环图，以确定应在何处调用设置器。

上述方法的优点是它将所有命令行参数/属性文件解析异常处理放在一处。不存在格式错误的论点在受到攻击之前会流传数周的风险。