Executando verificação de segurança...
Respondendo a [Não disponível] dentro da publicação [Não disponível]
1
lehen

opa, bom BugBug?

Então, esse jeito que você escreveu é o jeito errado que eu falei de como resolver o problema.

Mas porque errado né?
Seguinte, imagina agora que eu vou dar suporte a 30 bancos de dados diferentes... você vai deixar no meio do código um switch case de 30 opções ou vai extrair isso para uma classe (não estamos falando de programação funcional nesse exemplo hein) diferente?

Se você extrair pra uma classe diferente, provavelmente você vai usar uma factory.

Lembrando que o seu exemplo nao segue o princípio Open Closed porque a cada novo jeito de salvar vai precisar mudar esse código... o que vai pioriando ele a cada vez que você muda.

Mas, sim, TUDO pode ser resolvido só com loop e if/else a questão e se voce wuer estrurar o código ou não...

Outra coisa, se os padrões de programação orientada a objeto nao fazem sentido na programação funcional... bom, é porque eles são padrões de orientação a objeto. Em programação funcional os padrões são outros. Nessa caso aí você pode fazer uma high order function e só receber a função que salva de acordo com a necessidade,
valeu!

Carregando publicação patrocinada...
-1
BugBug2

Opa, bão.

Ok, vou imaginar seu exemplo.

Então agora eu tenho esse código:

function salvarBancoPostgres() {}
// mais 30 funções de bancos...

export function salvarDado(dado, salvarOnde) {
    switch(salvarOnde) {
        case bancoPostgres: salvarBancoPostgres(dado)
        case bancoMySQL: salvarBancoMySQL(dado)
        case bancoRedis: salvarBancoRedis(dado)
        case bancoMongo: salvarBancoMongo(dado)
        case arquivo: salvarArquivo(dado)
        // mais 30 cases de bancos...
    }
}

Pra adicionar mais um banco é só criar a função dele e adicionar uma linha no switch case.

Agora pergunto: O que iria piorar? Qual é a vantagem de usar um factory?

Outra coisa, se os padrões de programação orientada a objeto nao fazem sentido na programação funcional... bom, é porque eles são padrões de orientação a objeto.

Não entendi a relação disso com o assunto mas tudo bem.

1
lehen
Autor
Autor

Antes de responder a vantagem de usar um factory, te pergunto: Se você tiver uma necessidade de salvar em 30 lugares diferentes do código, vai repetir esse switch case em 30 outros lugares? seriam 900 linhas de código. O que você faria pra nao ficar repetindo?

-1
1
lehen
Autor
Autor

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 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