代码之家  ›  专栏  ›  技术社区  ›  Ma99uS

为什么有些API(如JCE、JSSE等)通过单例映射提供其可配置属性?

  •  1
  • Ma99uS  · 技术社区  · 5 年前

    例如:

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

    只有当 CertPathValidator 使用。我看到两种蓄水方式:

    • 再次是singleton,但每个属性都有getter和setter
    • 包含与当前上下文相关的属性的对象: CertPathValidator.setValidatorProperties(..) (它已经为 PKIXParameters ,这是一个很好的开始,但不包括所有内容)

    一些原因可能是:

    • 从命令行设置属性——在上面建议的类中,从命令行到默认值的简单转换是很简单的。
    • 允许不同提供程序提供其他自定义属性-它们可以 public Map getProviderProperties() ,甚至 public Object .. 铸造。

    我很好奇,因为这些属性并不总是在最显眼的地方,而不是在使用API时看到它们,你必须在得到它们之前(如果幸运的话)浏览几十个谷歌结果。因为——首先——你并不总是知道你到底在找什么。

    我刚才观察到的另一个致命缺点是,这不是线程安全的。例如,如果两个线程希望通过OCSP检查吊销,则必须设置 ocsp.responderURL 财产。可能会覆盖彼此的设置。

    1 回复  |  直到 14 年前
        1
  •  2
  •   Kevin Day    14 年前

    这实际上是一个很好的问题,它迫使您考虑过去可能做出的设计决策。谢谢你问我一个多年前应该发生的问题!

    听起来,反对的不是这个问题的单一方面(尽管可能会发生完全不同的讨论),而是使用字符串键。

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

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

    尽管如此,我认为第一个原因(容易解析命令行)并没有真正切掉它。创建一个反射驱动机制,将设置推送到一组setter中是相当容易的,而且它可以防止字符串-gt;对象转换的症结转移到主应用程序类中。

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

    上述方法的优点在于,它将所有的命令行参数/属性文件解析异常处理放在一个地方。一个格式错误的争论在它被击中前几个星期内不存在浮动的风险。