1

例如：

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

这仅在使用 a 时CertPathValidator使用。我看到两个重要的选项：

  • 再次单例，但每个属性都有 getter 和 setter
  • 包含与当前上下文相关的属性的对象：（ CertPathValidator.setValidatorProperties(..)它已经有一个 setter for PKIXParameters，这是一个好的开始，但它不包括所有内容）

一些原因可能是：

  • 从命令行设置属性 - 从命令行到上面建议的类中的默认值的简单转换器将是微不足道的
  • 允许不同的提供者提供额外的自定义属性——它们可以有public Map getProviderProperties()，甚至可以public Object ..使用强制转换。

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

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

4

1 回答 1

2

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

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

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

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

尽管如此，我认为第一个原因（命令行的简单解析）并没有真正解决它。创建一个反射驱动机制来将设置推送到一组 setter 中是相当容易的，并且它可以防止 String->object 转换的麻烦转移到主要的应用程序类中。

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

上述方法的优点是它将所有命令行参数/属性文件解析异常处理放在一个地方。不存在格式错误的论点在被击中之前漂浮数周的风险。

于 2010-02-18T04:35:22.873 回答