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

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

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

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!