Executando verificação de segurança...
Em resposta a [Não disponível]
1
kevinmarquesp

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.

Carregando publicação patrocinada...
-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?

2
-2
BugBug

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!