Conflito com a interface PagarmeApiSDK.Standard.IConfiguration

[brunobritodev]

Ao desenvolver uma classe que utiliza o PagarmeApiSDKClient, adicionei a referência ao IConfiguration com o intuito de acessar as informações de usuário e senha presentes no appsettings.json. No entanto, para minha surpresa, percebi que, devido ao using PagarmeApiSDK;, há uma outra Interface também chamada IConfiguration do componente da PagarMe. Essa duplicidade gera um conflito com o IConfiguration presente no namespace Microsoft.Extensions.Configuration.

Não seria mais apropriado posicionar o IConfiguration em um namespace diferente? ou, talvez renomeá-lo para evitar conflitos com as classes do framework? Uma terceira opção poderia ser, caso o IConfiguration do PagarmeApiSDK não seja essencial para uso pelos clientes finais (como no meu caso), alterar seu modificador de acesso para "internal". Dessa forma, sua exposição desnecessária seria evitada.

É possível contornar a situação ao especificar o namespace completo, no entanto creio que seria mais conveniente se um componente fosse projetado para ser menos intrusivo e evitar potenciais conflitos com classes do framework.

[lucas-fsousa]

Você pode usar um Alias para algum dos namespaces, assim o conflito vai sumir.

O IConfiguration da MS vem do namespace Microsoft.Extensions.Configuration, você pode fazer o seguinte.

Coloque no inicio da sua classe o seguitne código:

using Conf = Microsoft.Extensions.Configuration.IConfiguration;

Assin, você pode usar o Conf para acessar o appsettings.json e obter todos os dados que você precisar de lá. O outro IConfiguration do SDK PAGARME você pode deixar do jeito que está, ou inverter e usar o que eu te passei acima no namespace do SDK.

Espero ter ajudado.

[brunobritodev]

Agradeço pela resposta e pela sugestão de usar um alias para contornar o conflito de nomes.

No entanto, acredito que o problema é um design que pode ser melhorado. O uso de nomes que conflitam com tipos bem conhecidos da frameworks pode levar a erros e confusões. Em projetos maiores e equipes com vários desenvolvedores, esse workaround pode não ser ideal e pode resultar em um código mais difícil de entender e manter.

Boas práticas de design prevê um bom Encapsulamento, resultando em um component menos intrusivo. Portanto, minha sugestão permanece: seria mais apropriado posicionar o IConfiguration em um namespace diferente ou renomeá-lo para evitar conflitos.

E nesse caso a interface nem é essencial para o uso básico, uma boa opção seria torná-la "internal".

Isso não só tornaria a SDK mais fácil de usar, mas também mais robusta e menos propensa a causar problemas em projetos que a integram.

Acredito que a issue já atendeu seu objetivo que é sugerir uma mudança e os pontos já foram dados. Fique a vontade para fecha-la.

[lucas-fsousa]

de fato o seu ponto é totalmente válido. Também achei meio desnecessária a exposição do IConfiguration, mas vai saber como os caras desenharam a aplicação como um todo, as vezes sequer veio a mente que existia o IConfiguration da MS. Bom, veremos o que vão fazer a respeito. Sou apenas um mero contribuinte da comunidade que também sofreu com esse problema que você expos.