Olhando os comentários, vejo que tem falta de informação sobre o assunto. Vou listar algumas:
- 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.
- 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.
- 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?
Você pode ler mais sobre DP aqui https://refactoring.guru/design-patterns Nesse site ele fala do tipo de problema que se almeja resolver com determinado patern.
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!