Executando verificação de segurança...
Respondendo a "Ok, vou tentar fazer um TLDR dos outros comentá..." dentro da publicação [Não disponível]
-3
BugBug

Olhando os comentários, vejo que tem falta de informação sobre o assunto. Vou listar algumas:

  1. O livro é específico para linguagens OO, como C++ e Java. Está bem explícito no título (Padrões de Projetos: Soluções Reutilizáveis de Software Orientados a Objetos) e no restante do livro.
  2. Os autores estudaram vários projetos OO e identificaram os patterns. Isso não significa que eles 'resolvem' algo, mas sim que se repetem em alguns softwares OO.
  3. Os exemplos e "problemas" que o livro mostra são bem ruims e teóricos. Não são exatamente de problemas reais. E isso fica pior, porque todas as explicações e exemplos em blogs/vídeos são conhecimentos herdados do livro. Então a qualidade será pior ou perto do nível do livro.

O que não consigo entender é porque eu preciso saber design patterns se elas não resolvem um problema real? O que vi do livro são apenas problemas fictícios em que a própria OO causa, ou que são tão simples que nem deveriam se chamados de patterns.

E porque ninguém aqui consegue consegue me explicar quais problemas elas resolvem?
Algoritmos de ordenação, por exemplo, resolvem um problema real. Têm nome e uma implementação. Não preciso explicar quicksort, o dev consegue pesquisar no Google e entender o algoritmo.

E qual é a dificuldade de falar 'usa uma função como parâmetro' ao invés de strategy?

Ou, qual é a dificuldade de falar 'switch case' ao invés de factory method?

Carregando publicação patrocinada...
2
-2
BugBug
  • Autor
    Autor

Os exemplos e "problemas" que o livro mostra são bem ruims e teóricos. Não são exatamente de problemas reais. E isso fica pior, porque todas as explicações e exemplos em blogs/vídeos são conhecimentos herdados do livro. Então a qualidade será pior ou perto do nível do livro.

1
lehen

Usar um switch case viola o princípio Open/Closed dos princípios SOLID (pesquisa isso no google).

Sua observação faz sentido. Se nao resolve problema real, pra que aprender???

Um exemplo real:
Você está fazendo uma aplicação e usuário pode escolher salvar os dados em banco de dados ou salvar em arquivo no computador dele. O jeito certo de fazer é (em OOP): Criar uma interface que define como você vai salvar os dados; criar 2 implementações dela, uma para o banco de dados e outra para os arquivos; criar uma factory que instância a classe concreta de acordo com a escolhe do usuário.

O jeito errado de fazer: Usar um switch case =|.

Ou outra: se você usar um switch case pra selectionar a classe correta pra interface... bom, isso é a factory meu amigo haha.

Pronto, tá aí o seu exemplo prático!
Boa sorte nos estudos de design patterns!

Conteúdo excluído
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!

-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

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
kht

Se vc ler com calma este meu comentário, vai entender que no fundo vc implementou o strategy (usou um comportamento diferente em runtime, de acordo com determinados parâmetros).

Precisava dar um nome pra isso? Não sei, mas o fato é que hoje esses nomes existem, e muita vezes acabamos usando design patterns sem perceber.

No fim cai no que eu já disse (e volto a repetir): como as implementações orientadas a objeto se tornaram bem populares, muita gente acha que é o único jeito de usar DP. E pior, acham que se vc usa qualquer outra coisa (como um simples if ou switch), então não está usando design pattern. E essa é uma percepção errônea, mas ainda bem comum, infelizmente.

A verdade é que usamos esses patterns mais do que a gente imagina, só que muitas vezes não ficamos pensando "nossa, agora usei o pattern X". Porque os patterns nada mais são do que soluções catalogadas para problemas comuns. E muitas delas são coisas tão "óbvias" e "triviais", e usamos tão naturalmente, que nem paramos pra pensar se é ou não um pattern.

Esse é outro desserviço dos livros famosos sobre DP: fez as pessoas acharem que eles são coisas super-ultra-elaboradas, que só é possível usá-los com código complexo, dezenas de classes e interfaces, etc. No meu comentário já citado tem links sobre artigos que implementam alguns patterns em C, mostrando que não é obrigatório usar classes.

E nesse mesmo comentário também explica que conforme a complexidade aumenta, as soluções com if e switch podem causar alguns problemas que são resolvidos de outras formas. E uma dessas formas é aquela descrita no livro do GoF. O problema é que muita gente leu e achou que é o único jeito (ou o "jeito certo™"). Não é, pra casos simples um if ou switch já resolve, e isso não quer dizer que vc não está usando DP só porque não fez do jeito complexo.

Pode-se até debater se precisava dar nome pra cada coisinha que fazemos, ou se os nomes são adequados, etc. Mas eles existem, e usamos o tempo todo, mesmo quando achamos que não.