Tudo bem ter dependências dentro de uma classe que possa ser trocada?

Digamos que eu estou tendo um modelo de domínio e quero lê-lo e salvá-lo de qualquer camada de persistência - no momento, pode ser um arquivo json, mas no futuro pode ser xml ou um banco de dados (que também pode mudar de tipo )

Para gerar o modelo de domínio a partir da camada de persistência, eu tenho uma implementação de uma interface simples que, digamos, contém um getAll()e saveAll()método. Se eu quiser mudar para outro tipo de persistência, posso simplesmente mudar a implementação da interface. No entanto, dentro da implementação, usarei soluções completamente diferentes para ler e armazenar os dados, então terei que usar objetos diferentes de outras bibliotecas para lidar com os dados.

Digamos que eu use um serializador Json na primeira implementação, instanciarei a instância desse serializador diretamente na minha implementação. Isso levará à minha implementação diretamente, dependendo do serializador, nunca posso dar outro. Mas isso não seria possível de qualquer maneira, porque não há interface universal para serializadores (ou qualquer tipo de persistência). Portanto, se eu quiser usar um serializador diferente, a única coisa que posso fazer é escrever uma implementação completamente nova, em vez de apenas passar outra externamente.

Então, não há problema em codificar dependências nesse caso? Ou existe uma opção melhor?

Com referência à minha resposta a uma pergunta recente , a chave aqui é separar as interfaces da camada de persistência de qualquer implementação da camada de persistência, usando o padrão de escada.

A dependência no serializador Json se torna um detalhe de implementação do pacote de persistência Json. O restante do aplicativo não precisa saber nada sobre ele, nem sofrer o fardo dessa dependência, pois ele acessa apenas o pacote de persistência por meio das interfaces, que estão em outro pacote.

Se você adicionar um pacote de persistência de banco de dados, ele simplesmente implementará essas interfaces e, por exemplo, suas dependências ORM também serão ocultadas como um detalhe de implementação.

Você não pode remover todas as dependências do seu código; eventualmente, você precisa depender de alguma coisa , caso contrário, acabará com um objeto-deus gigante que faz tudo sozinho.

Como regra geral, você deseja que cada classe dependa de objetos que serão mais estáveis ​​que eles; e você deseja que os relacionamentos instáveis ​​usem a injeção de dependência para permitir testes mais fáceis e mais flexibilidade.

Qual a probabilidade de o serializador JSON mudar? É mais ou menos estável que o código que você está escrevendo?

Se é provável que você substitua o serializador mais de uma vez por uma implementação diferente, talvez seja possível criar um proxy ou um objeto wrapper em torno do próprio serializador. Dessa forma, você pode controlar a interface que possui com o serializador e depender apenas de uma biblioteca externa em um único local.

Dito isto, eu pessoalmente ainda não encontrei um motivo para substituir um serializador JSON (por um serializador diferente), então não me preocuparia muito em ter uma dependência direta dele. Um serializador quase sempre terá uma interface mais estável do que qualquer coisa em meus próprios aplicativos, e os métodos que eu preciso são tão simples e poucos que não há realmente uma razão para eles mudarem.

Parece que você não está preocupado especificamente com a mudança do próprio serializador - pelo que você descreveu, você está preocupado com a mudança de requisitos externos para um sistema de persistência totalmente diferente - nesse caso, sua implementação da camada de persistência será completamente reescrita de qualquer maneira, e usar injeção de dependência ou proxy não ajudará.

Desde que a interface entre a camada de persistência e os modelos de domínio permaneça a mesma e você esteja zombando dessa camada ao testar seus modelos de domínio, não vejo problema em depender de uma interface específica de uma biblioteca JSON. É barato testar essa dependência e é improvável que a própria biblioteca JSON mude.