1

例えば：

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

そして、これはaCertPathValidatorが使用される場合にのみ使用されます。窮地に立たせるための2つの選択肢があります。

  • 再びシングルトンですが、各プロパティにゲッターとセッターがあります
  • 現在のコンテキストに関連するプロパティを含むオブジェクト:( CertPathValidator.setValidatorProperties(..)すでにセッターがありますPKIXParameters。これは良いスタートですが、すべてが含まれているわけではありません）

いくつかの理由が考えられます：

  • コマンドラインからプロパティを設定する-コマンドラインから上記のクラスのデフォルト値への単純な変換は簡単です
  • さまざまなプロバイダーによる追加のカスタムプロパティを許可します-それらは持つことができ、キャストすることpublic Map getProviderProperties()もできます。public Object ..

これらのプロパティは常に最も目に見える場所にあるとは限らないため、興味があります。APIの使用中に表示する代わりに、（運が良ければ）取得する前に数十のGoogle検索結果を確認する必要があります。なぜなら-そもそも-あなたは自分が何を探しているのかを常に正確に知っているとは限らないからです。

私が今観察したもう1つの致命的な欠点は、これがスレッドセーフではないことです。たとえば、2つのスレッドがocspを介して失効を確認する場合は、ocsp.responderURLプロパティを設定する必要があります。おそらく、互いの設定を上書きします。

4

1 に答える 1

2

これは実際には、過去に行った可能性のある設計上の決定について考えることを余儀なくされる素晴らしい質問です。何年も前に私に起こったはずの質問をしてくれてありがとう！

異議はこれのシングルトンの側面ではなく（それについてはまったく異なる議論が発生する可能性がありますが）、文字列キーの使用であるように思われます。

私はこの種のスキームを使用するAPIに取り組んできましたが、上記で概説した理由は間違いなく推進要因でした-コマンドラインまたはプロパティファイルの解析が非常に簡単になり、サードパーティの拡張性に影響を与えることなく可能になります公式API。

私たちのライブラリには、実際には、公式パラメータごとに静的な最終文字列エントリがたくさんあるクラスがありました。これにより、両方の長所が得られました。開発者は、必要に応じてコード補完を使用できます。内部クラスを使用して、関連する設定の階層を構築することも可能になります。

とはいえ、最初の理由（コマンドラインの解析が簡単）は実際にはうまくいかないと思います。設定を一連のセッターにプッシュするための反射駆動メカニズムを作成することはかなり簡単であり、文字列->オブジェクト変換の断片がメインのアプリケーションクラスに流れ込むのを防ぎます。

拡張性は少し注意が必要ですが、それでも反射駆動システムを使用して処理できると思います。メインの構成オブジェクト（すべてのセッターが含まれているオブジェクト）にもregisterExtensionConfiguration（xxx）メソッドを含めるという考え方です。標準の表記法（おそらくドットで区切られている）を使用して、構成オブジェクトの結果の非循環グラフに飛び込み、セッターを呼び出す場所を決定できます。

上記のアプローチの利点は、すべてのコマンドライン引数/プロパティファイルの解析例外処理を1か所にまとめることです。誤った形式の引数がヒットする前に数週間浮かんでくるリスクはありません。

于 2010-02-18T04:35:22.873 に答える