Ok, vou tentar fazer um TLDR dos outros comentários aqui num único parágrafo pra quem caíu de paraquenas no post e está com a mesma dúvida.
Sim, você precisa. O livro não passa de um simples catálogo de soluções pra problemas que programadores experientes no passado, os autores do livro, já encontraram na carreira deles, daí eles só estão dando nome aos bois pra facilitar a comunicação. Ao invés de você descrever, em detalhes, o algoritmo da solução que você está pensando pro seu colega, seria muito melhor você só dizer "acho que consigo resolver com um factory". Espera, teu colega não leu o livro? òtimo! Nem precisa! Agora ele tem um termo pra pedir pro ChatGPT detalhar, assim ninguém perde tempo explicando ou tentando entender na hora — é tudo sobre comunicação no final do dia.
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?