Почему некоторые API (например, JCE, JSSE и т. Д.) Предоставляют свои настраиваемые свойства с помощью одноэлементных карт? - PullRequest
Новая
       39

Почему некоторые API (например, JCE, JSSE и т. Д.) Предоставляют свои настраиваемые свойства с помощью одноэлементных карт?

1 голос
/ 17 февраля 2010

Например: 

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

И это используется только тогда, когда используется CertPathValidator. Я вижу два варианта для импортера:

  • снова синглтон, но с геттером и сеттером для каждого свойства
  • объект, содержащий свойства, относящиеся к текущему контексту: CertPathValidator.setValidatorProperties(..) (у него уже есть установщик для PKIXParameters, что является хорошим началом, но не включает в себя все)

Некоторые причины могут быть:

  • установка свойств из командной строки - простой преобразователь из командной строки в значения по умолчанию в классах, предложенных выше, будет тривиальным
  • допускает дополнительные пользовательские свойства различных провайдеров - они могут иметь public Map getProviderProperties() или даже public Object .. с кастингом.

Мне любопытно, потому что эти свойства не всегда находятся в наиболее заметном месте, и вместо того, чтобы видеть их при использовании API, вам нужно просмотреть десятки результатов Google, прежде чем (если повезет) получить их. Потому что, во-первых, вы не всегда знаете, что именно ищете.

Другой фатальный недостаток, который я только что заметил, заключается в том, что он не является поточно-ориентированным. Например, если два потока хотят проверить аннулирование через ocsp, они должны установить свойство ocsp.responderURL и, возможно, переопределить настройки друг друга.

1 Ответ

2 голосов
/ 18 февраля 2010

На самом деле это большой вопрос, который заставляет вас задуматься о дизайнерских решениях, которые вы, возможно, принимали в прошлом. Спасибо, что задали вопрос, который должен был возникнуть у меня много лет назад!

Звучит так, будто это возражение - не столько единственная сторона этого (хотя об этом может происходить совершенно другая дискуссия), но и использование строковых ключей.

Я работал над API, которые использовали схему такого рода, и причины, которые вы изложили выше, были определенно движущими факторами - это сводит с ума простой анализ синтаксического анализа командной строки или файла свойств, а также позволяет стороннюю расширяемость без влияние на официальный API.

В нашей библиотеке у нас фактически был класс со связкой статических окончательных записей String для каждого из официальных параметров. Это дало нам лучшее из обоих миров - разработчик все еще мог использовать завершение кода там, где это имело смысл. Также становится возможным создавать иерархии связанных настроек с использованием внутренних классов.

Все это говорит, я думаю, что первая причина (простой анализ командной строки) на самом деле не обрезает это. Создать механизм, управляемый отражением, для вставки настроек в группу сеттеров будет довольно легко, и это предотвратит смещение преобразования String-> object в основные классы приложения.

Расширяемость немного сложнее, но я думаю, что она все еще может быть обработана с помощью системы, управляемой отражением. Идея заключалась бы в том, чтобы основной объект конфигурации (тот, в котором все сеттеры находились в нем) также имел метод registerExtensionConfiguration (xxx). Стандартные обозначения (возможно, разделенные точками) могут использоваться для погружения в результирующий ациклический граф объектов конфигурации, чтобы определить, куда следует вызывать сеттер.

Преимущество вышеупомянутого подхода состоит в том, что он помещает все операции обработки исключений при разборе файла аргументов / свойств командной строки в одно место. Нет риска неправильного форматирования аргумента в течение нескольких недель, прежде чем его ударить.

...