nao entendi porque negativaram essa sua resposta 😂. isso isso, você vai usar a função salvarDado, em todo os lugares né? Isso já ta bem parecido com uma factory, mas realmente não é. Olha, só usar salvarDado já funcionaria, mas eu nao usaria desse jeito porque: Essa função executa uma ação (tem um "side effect") então não tem transparência referencial. Esse artigo [aqui](https://www.baeldung.com/cs/referential-transparency#:~:text=Referential%20transparency%20is%20a%20property,get%20the%20same%20returning%20value.) fala sobre isso. Não ta escrito no artigo, mas eu acrescento que ter funções que não mudam o estato da aplicação e só soltam uma certa saída pra uma entrada (A + B -> C) deixa o código mais simples de entender e principalmente mais facil de testar. Claro que você vai ter wue fazer a ação rm algum momento, mas no geral você quer isso o mais encapsulado possível e o mais perto da classe (ou função) que iniciou a coisa toda, não em uma função que ta laaaa em baixo no fluxo da informação. Sendo assim, ao invés de usar um salvarDado eu mudaria essa função sua para ser uma factory que recebe qual banco de dados é desejado e retorna a função de salvar no banco de dados (essas do seu switch case) e invocaria a função fora do switch case. Eu to escrevendo do telefone, então não dá ora fornecer o codigo mesmo... mas se não entender eu completo. Talvez você esteja lendo e pensando que não faz a menor diferença, você só moveu o código pra fora do switch case, duh... Mas na hora de debuggar uma code base grande facilita muito quando você ir linha a linha e ver tipo: Ok, a função de salvar foi criada, isso ta certo, agora os dados vão ser manipulados, certo, agora finalmente a gebte vai salvar no banco de dados. Ao invés de: vamos salvar no banco de dados, deixar eu entrar na função aqui, ok agora os dados vai ser manipulados "in place" (ao invés de cuspir os dados novos você muda no parâmetro passado, também nao tem transparência referencial), deixa eu entrar nessa função também... Enfim, deixa tudo mais difícil. Bom tá aí uma explicação gigantesca porque eu usaria uma factory nesse tipo de cenário ao invés de um switch case que seleciona como salvar. Essas discussões já aconteceram diversas vezes, é necessário catalogar para que toda vez que uma dúvida assim apareça, os engenheiros já tenham alguma experiência passada para se basear, ao invés usar sentimento pra decidir. Pra concluir eu diria por experiência que discutir sobre um pull request com outro engenheiro fica muito melhor e mais fácil se a pessoa usa os padrões para defender um ponto de visto... quando uma das partes começa a usar opinião pessoal, a conversa fica empobrecida. Conhecer um padrão é importante até pra falar quando você não quer usa-lo. Ta aí um pequeno artigo em forma de resposta hahaha