Pourquoi certaines API (comme JCE, JSSE, etc.) fournissent leurs propriétés configurables grâce à des cartes singleton?

Question

Par exemple:

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

Et ceci est utilisé uniquement lorsqu'un CertPathValidator est utilisé. Je vois deux options pour imporement:

• à nouveau singleton, mais avec getter et setter pour chaque propriété
• un objet contenant les propriétés pertinentes au contexte actuel: CertPathValidator.setValidatorProperties(..) (il a déjà un setter pour PKIXParameters, qui est un bon début, mais il ne comprend pas tout)

Quelques raisons peuvent être:

• définir les propriétés de la ligne de commande - un simple transformateur de ligne de commande aux valeurs par défaut dans les classes proposées ci-dessus serait trivial
• permettant des propriétés personnalisées supplémentaires par différents fournisseurs -. Ils peuvent avoir public Map getProviderProperties(), ou même public Object .. avec coulée

Je suis curieux, parce que ces propriétés ne sont pas toujours dans l'endroit le plus visible, et au lieu de les voir en utilisant l'API, vous devez aller si des dizaines de résultats Google avant (si la chance) les obtenir. Parce que - en premier lieu -. Vous ne savez pas toujours ce que vous cherchez exactement

Un autre inconvénient fatal j'ai observé est juste que ce n'est pas thread-safe. Par exemple, si deux threads veulent vérifier une révocation par OCSP, ils doivent définir la propriété ocsp.responderURL .. et peut-être remplacer les paramètres de l'autre.

Answer 1

Ceci est en fait une grande question qui vous oblige à réfléchir sur les décisions de conception que vous avez fait dans le passé. Merci de poser une question qui aurait dû se produire à moi il y a des années!

On dirait que l'objection n'est pas tant l'aspect singleton de (même si une discussion tout à fait différente pourrait avoir lieu à ce sujet). - mais l'utilisation de clés de chaîne

J'ai travaillé sur des API qui ont utilisé ce genre de système, et les raisons pour lesquelles vous les grandes lignes ci-dessus étaient certainement les facteurs de conduite - il le rend simple fou pour analyser une ligne de commande ou fichier de propriétés, et permet pour l'extensibilité 3ème partie sans impact sur l'API officielle.

Dans notre bibliothèque, nous avons eu en fait une classe avec un tas d'entrées de chaîne finales statiques pour chacun des paramètres officiels. Cela nous a donné le meilleur des deux mondes - le développeur pourrait encore utiliser la complétion de code où il était logique de le faire. Il devient également possible de construire des hiérarchies de paramètres associés à l'aide de classes internes.

Cela dit, je pense que la première raison (parsing facile de ligne de commande) ne coupe pas vraiment. Création d'un mécanisme entraîné réflexion pour pousser les paramètres dans un groupe de poseurs serait assez facile, et il empêcherait la croute de String-> transformation de l'objet de la dérive dans les principales classes d'application.

Extensibilité est un peu plus compliqué, mais je pense qu'il pourrait encore être gérée à l'aide d'un système axé sur la réflexion. L'idée serait d'avoir le principal objet de configuration (l'un avec tous les setters en elle) ont également une méthode registerExtensionConfiguration (xxx). pourrait être utilisé pour plonger dans le graphe acyclique résultante des objets de configuration à une notation standard (dot probablement séparée) déterminer l'endroit où doit être appelé le dispositif de réglage.

L'avantage de l'approche ci-dessus est qu'il met tout de gérer en un seul endroit l'argument de ligne de commande / fichier de propriétés analyse syntaxique exception. Il n'y a pas un risque d'un argument mal formaté flottant autour pendant des semaines avant qu'il ne soit touché.