Vou começar com um segredo sujo: Design Patterns são como sexo na adolescência. Todo mundo fala, ninguém sabe direito como faz, e quando tentam, geralmente é vergonhoso.

Mas vamos desmontar essa bagunça.

1. "Design Patterns São Só Para C++ e Java" – Mentira de Quem Parou no Tempo

O livro "Design Patterns: Elements of Reusable Object-Oriented Software" (GoF) de 1994 usou C++ e Smalltalk nos exemplos. Daí veio o mito: "Ah, isso só serve pra OO".

A verdade:

O padrão Observer é o que o React usa por baixo dos panos (ou você acha que useState é magia?).

O Singleton é o pesadelo de todo dev de Python que já usou módulos.

O Strategy é o coração do seu Array.sort() em JavaScript.

Design Patterns são conceitos, não implementações. Se sua linguagem é OO, funcional, ou até procedural, eles aparecem. Só não têm o mesmo nome.

2. "Design Patterns Aumentam Complexidade" – Verdade (Quando Usados Por Idiotas)

Design Patterns não são receitas de bolo. São pratos de restaurante estrelado: você precisa saber quando, como e por que serví-los.

Exemplo de burrice: Criar um Abstract Factory para uma app que tem 2 tipos de usuários.

Exemplo de genialidade: Usar um Facade para esconder a API caótica do legado da empresa.

A culpa não é do padrão. É do dev que achou que usar 15 padrões em 100 linhas de código o tornaria o novo Linus Torvalds.

3. SOLID, Clean Code e a Indústria de Influencers

SOLID e Design Patterns são como macarrão e queijo: combinam, mas não são a mesma coisa.

SOLID são princípios gerais para não transformar seu código em espaguete radioativo.

Design Patterns são táticas para resolver problemas específicos (ex: "como desacoplar criação de objetos?" → Factory).

O problema? A galera vende SOLID como religião e Design Patterns como bala de prata. Não são. São ferramentas.

Quanto ao Clean Code: o livro tem ótimos conselhos (e alguns absurdos). Aprenda a filtrar. Influencers falam tanto dele porque polêmica = views.

4. "Design Patterns São Obrigatórios" – Só Se Você Quiser Virar um NPC

Importante: Design Patterns não são inventados, são descobertos. Eles já estavam lá, no seu código bagunçado, só esperando você dar um nome. Alguns padrões são bons outro são ruins (anti pattern). Alguns são tão bons ou ruins e acotecem que tanta frequência que ficam "famosos"

Nenhum padrão "famoso" é "obrigatório". Mas alguns são extremamente úteis:

MVC/MVVM: Quase obrigatório em apps com UI complexa.

Dependency Injection: Vital em sistemas com 500 classes acopladas.

Observer: Simplesmente a melhor forma de reagir à mudanças de estado.

A regra é simples: Use padrões para resolver problemas, não para criar novos.

O Que Estudar (E Como Não Virar Um Fanboy)

Livro dos GoF (1994): Leia como leria um livro de história. Entenda os conceitos, não o código em C++.

Head First Design Patterns: Melhor explicação de por que os padrões existem.

Conclusão: Pare de Caçar Padrões e Comece a Entender Problemas

A próxima vez que você vir um if gigante ou uma classe com 20 responsabilidades, não pense "Qual padrão eu uso?". Pense:

O que está errado aqui? (Ex: Acoplamento alto? Dificuldade de teste?)

Qual princípio isso viola? (Ex: Single Responsibility? Open/Closed?)

Qual tática resolve isso? (Ex: Strategy? Decorator?)

Design Patterns são vocabulário, não regras. Servem para você explicar para outros devs: "Olha, usei um State aqui pra não ficar 100 ifs".

"Padrão de projeto é como cueca: se está funcionando e ninguém vê, tá certo. Se está incomodando, você está usando errado."

Tem que ver exatamente de quais críticas ou elogios vc está falando. Mas enfim...

Basicamente, um Design Pattern é uma descrição de uma solução reusável para um problema conhecido ("se vc tem uma situação XYZ com tais características, uma possível solução é fazer A, B e C desta forma").

O problema - como acontece com praticamente tudo na nossa área - é o abuso ou uso errado. É achar que um DP é solução universal e tentar aplicá-la pra tudo, inclusive nos casos em que ela não é a melhor solução.

Foi essa a crítica que vc viu? Pois pra mim é o principal problema. Perceba que não é o DP em si, e sim quando usam de forma errada.

---

Nenhuma tecnologia é solução universal, tudo depende do contexto. Tem casos em que é adequado, em outros casos piora as coisas, e tem casos em que tanto faz.

O que os DP fazem - pelo menos é assim que eu vejo - é no máximo sugerir que, para a maioria dos casos em que seu problema se assemelha à descrição do DP, a solução proposta se mostrou bem adequada. Mas não é uma lei sagrada que deve ser seguida cegamente pra todos os casos.

Como sempre, tem que avaliar o contexto. E pra avaliar bem precisa conhecer as opções, os prós e contras de cada uma e só aí decidir. Nenhum DP é obrigatório, vc usa se o seu caso e contexto indicar que precisa. Vc identifica o problema e aplica a respectiva solução, o ruim é quando fazem o contrário (tentar encaixar um DP de qualquer jeito, mesmo quando ele não serve).

Isso vale pra tudo, seja SOLID, clean code ou seja lá qual for a moda atual ou futura. Sempre depende.

Sobre só ser útil em C++ e Java, meu chute é que isso é um efeito colateral do famoso livro do GoF, que fez muita gente acreditar que DP só é possível em linguagens orientadas a objeto - o que não é verdade, dá pra implementar até em C, por exemplo.

Enfim, é isso. Não gosto desses "mantras" absolutos do tipo "sempre faça" ou "nunca use". Salvo raríssimas exceções, o ideal é analisar caso a caso, levando em conta as circunstâncias específicas e os prós e contras de cada solução.