Por que algumas APIs (como JCE, JSSE etc.) fornecem suas propriedades configuráveis ​​através de mapas de singleton?

Question

Por exemplo:

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

E isso é usado apenas quando um CertPathValidator é usado. Eu vejo duas opções para importação:

• Novamente Singleton, mas com getter e setter para cada propriedade
• Um objeto que contém as propriedades relevantes para o contexto atual:CertPathValidator.setValidatorProperties(..) (já tem um setter para PKIXParameters, o que é um bom começo, mas não inclui tudo)

Algumas razões podem ser:

• Definir as propriedades da linha de comando - um transformador simples da linha de comando para os valores padrão nas classes sugeridas acima seria trivial
• permitindo propriedades personalizadas adicionais por diferentes fornecedores - eles podem ter public Map getProviderProperties(), ou mesmo public Object .. com elenco.

Estou curioso, porque essas propriedades nem sempre estão no local mais visível e, em vez de vê -las enquanto usam a API, você precisa ir embora com dezenas de resultados do Google antes (se for sortudo) obtê -los. Porque - em primeiro lugar - você nem sempre sabe o que exatamente está procurando.

Outra desvantagem fatal que acabei de observar é que isso não é seguro para fios. Por exemplo, se dois tópicos desejam verificar uma revogação via OCSP, eles precisam definir o ocsp.responderURL propriedade .. e talvez substitua as configurações uma da outra.

Answer 1

Esta é realmente uma ótima pergunta que o força a pensar nas decisões de design que você pode ter tomado no passado. Obrigado por fazer uma pergunta que deveria ter me ocorrido anos atrás!

Parece que a objeção não é tanto o aspecto singleton disso (embora uma discussão totalmente diferente possa ocorrer sobre isso) - mas o uso de teclas de string.

Eu trabalhei em APIs que usavam esse tipo de esquema, e as razões pelas quais você contorna acima foram definitivamente os fatores determinantes - isso simplifica a análise de uma linha de comando ou um arquivo de propriedades, e permite extensibilidade de terceiros sem impacto ao API oficial.

Em nossa biblioteca, na verdade tivemos uma aula com um monte de entradas estáticas de string final para cada um dos parâmetros oficiais. Isso nos deu o melhor dos dois mundos - o desenvolvedor ainda poderia usar a conclusão do código, onde fazia sentido fazê -lo. Também se torna possível construir hierarquias de configurações relacionadas usando classes internas.

Tudo isso dito, acho que a primeira razão (análise fácil da linha de comando) não a corta. Criar um mecanismo acionado por reflexão para empurrar configurações para um monte de setters seria bastante fácil, e impediria que o cruzamento de String-> Transformação de objetos se dividisse nas principais classes de aplicação.

A extensibilidade é um pouco mais complicada, mas acho que ainda pode ser tratado usando um sistema acionado por reflexão. A idéia seria ter o objeto de configuração principal (aquele com todos os setters nele) também possui um método RegisterExtensionConfiguration (XXX). Uma notação padrão (provavelmente separada por pontos) pode ser usada para mergulhar no gráfico acíclico resultante dos objetos de configuração para determinar onde o setter deve ser chamado.

A vantagem da abordagem acima é que ela coloca todo o argumento da linha de comando/Propriedades Progile Parsing Exception Maniplel em um só lugar. Não há risco de um argumento mal formado flutuando por semanas antes de ser atingido.