Os padrões de design são realmente essenciais hoje em dia?

Eu estava lendo "Coders at Work" e enfrentei o fato de que alguns dos profissionais entrevistados no livro não estão tão entusiasmados com os padrões de design.

Eu acho que existem 2 razões principais para isso:

1. Os padrões de design nos forçam a pensar em seus termos. Em outras palavras, é quase impossível inventar algo novo (talvez melhor).

2. Os padrões de design não duram para sempre. Idiomas e tecnologias mudam rapidamente; portanto, os padrões de design acabarão se tornando irrelevantes.

Talvez seja mais importante aprender a programar corretamente, sem padrões específicos, e não aprendê-los.

A questão também era que, geralmente, quando as pessoas enfrentam um problema e não têm muito tempo, tentam usar um padrão. Isso significa copiar e colar o código existente no seu projeto com pequenas alterações para que ele funcione. Quando é hora de mudar ou adicionar algo, um desenvolvedor não sabe por onde começar, porque não é o código dele e não está profundamente familiarizado com ele.

Pelo meu dinheiro, acho que todo mundo está perdendo o ponto dos padrões de design. É raro ficar me perguntando qual padrão devo usar em uma determinada situação. Além disso, eu estava usando a maioria desses padrões muito antes de saber que eles tinham nomes.

O poder dos padrões de design está na comunicação. É muito mais rápido para mim dizer "use uma estratégia para isso" do que descrever em detalhes o que estou sugerindo. É muito mais fácil para nós debater os benefícios dos modelos de domínio de gordura versus scripts de transação, se todos soubermos o que esses dois termos significam. E assim por diante.

E o mais poderoso de tudo: se eu nomeei uma classe FooBuilder, você sabe que estou usando o padrão Builder para gerar meu Foo.

Mesmo que você não saiba do que estou falando quando digo "O padrão do observador é ideal para isso", você poderá sair e pesquisar no Google com muita facilidade.

Nesse sentido, o poder dos padrões de design nunca desaparecerá.

Os padrões de design são um aumento no poder expressivo da linguagem comum que usamos como pessoas de software. Essa linguagem comum não é essencial, mas torna muitas soluções comuns para problemas mais fáceis e rápidas de expressar. Por exemplo, é muito mais fácil falar sobre Singletons do que falar sobre "classes em que devemos ter apenas uma instância, mas que não podem ser tornadas estáticas e globais".

As soluções fornecidas pelos padrões de design são úteis, mas são soluções nas quais você provavelmente já pensou se enfrentasse os problemas que eles resolvem. É necessário um certo nível de maturidade para entender os padrões de design - se você nunca precisou resolver o problema, não verá o valor ou o interesse na solução.

Os padrões servem a dois propósitos principais:

• Resolvendo tensões previsivelmente : os padrões são projetados para resolver um certo conjunto de tensões de uma maneira conhecida por funcionar. Kent Beck, autor de Smalltalk Best Practice Patterns , descreve os padrões como uma maneira de repetir a decisão que um especialista tomaria em circunstâncias semelhantes. Enquanto as tensões permanecerem as mesmas (e geralmente o fazem), os padrões que as resolvem permanecerão úteis.

• Multiplicador da força de comunicação : os padrões nos permitem dizer muito com um pouco. Eles aproveitam um pequeno conjunto de conceitos poderosos e bem compreendidos, aplicáveis ​​em uma ampla variedade de espaços problemáticos. A resposta do @ pdr é falsa sobre o valor comunicativo dos padrões.

Eu acho que a afirmativa de que os padrões de design impedem a inovação é completamente falsa. Você deve saber onde já existe, para não precisar reinventar a roda. Por serem temporários, os padrões como um todo se aplicam aos sistemas OOP e não estão vinculados a nenhuma plataforma ou idioma específico.

Agora, o que eu não gosto quando as pessoas falam sobre padrões é que algumas pessoas têm um tipo de obsessão por elas. Certa vez, um cliente me pediu para "incluir pelo menos mais dois padrões" (WTF ?!), pois, devido à falta de chavões no meu código, ele não parecia suficientemente empreendedor.

Talvez o conceito de anti-padrões é pertinente. Não penso em estudar padrões de design como o passo crítico para se tornar um engenheiro de software. O design de software é importante, geralmente reservado como prerrogativa do arquiteto de software em um projeto, mas realisticamente algo que pode ser calculado por consenso na equipe proverbial "bem-gelificada".

Mas padrões de design e antipadrões formam um recurso para essas discussões. É preciso apreciar as lições das coisas que funcionaram bem (ou não) e como capitalizar (ou mitigar) as conseqüências das escolhas de design. Uma boa equipe poderia criar seu próprio vocabulário para essas discussões, mas não é tão ruim fazer referência aos padrões defacto elaborados por autores que estiveram lá, fizeram isso.

Existem dois tipos de padrões de design:

1. Padrões universais , que são muito mais sobre como organizar programas complexos para que você possa entendê-los. Estes não estão indo embora, embora mais exemplos deles possam ser descobertos.
2. Padrões situacionais , que estão tão ligados às forças específicas induzidas pelas restrições (por exemplo, a linguagem de programação) que, quando essas forças mudam, elas se tornam irrelevantes.

OK, sem dúvida todos os padrões são um pouco situacionais, mas com alguns as forças são do mundo real e com outros as forças são das ferramentas. As ferramentas mudam muito mais rápido que o mundo real.

Ler sobre padrões de design é como aprender matemática em vez de reinventá-los. Ninguém o impede de fazer um grande progresso em um determinado campo, uma vez que você tenha uma sólida compreensão do que foi antes. Você acha que Rieman nunca leu Euclides?

Há benefícios nos padrões de design quando eles reduzem a quantidade de tempo que seus colegas ou clientes passam pensando "Como isso funciona?". Mesmo que não faça sentido impor um padrão em prol da padronização, se houver uma maneira comum e bem compreendida de fazer alguma coisa, sempre que um codificador procurar esse padrão esperando encontrá-lo e o faça, você fará o trabalho deles e de si Mais fácil.

Acredito que a turma de quatro classifique os padrões de design como

uma solução comum para um problema comum *

Então, sim, os padrões são relevantes quando o mesmo tipo de problema ocorre. E isso nos leva a um problema com o termo "Design Pattern". Um padrão é algo reconhecível que ocorre repetidamente. Então, na realidade, não existe um padrão de design, existe um padrão de problemas.

Algumas linguagens de programação podem ter soluções nativas para alguns desses problemas. O próprio livro "Design Patterns" menciona que o padrão de visitante é de pouco valor se você estiver usando o CLOS, pois o multi-despacho é suportado nativamente pelo CLOS, o mesmo problema que o padrão de Visitante está tentando resolver.

Além disso, a estrutura .NET possui um mecanismo de construção no evento para publicar eventos para vários ouvintes, tornando o padrão Observador menos relevante nesse contexto.

A mudança de aplicativos de desktop para aplicativos da web ** também altera o tipo de problemas de programação que precisamos resolver. Muitos dos padrões do livro "Design Patterns" são relevantes para aplicativos de desktop, mas não tanto para aplicativos da web. Obviamente, com aplicativos de página única, esses padrões podem ser relevantes novamente no lado do cliente.

Mas os padrões de design e livros como "Design Patterns" ou "Patterns of Enterprise Application Architecture" são de grande valor quando você é um programador iniciante e se depara com um novo tipo de problema pela primeira vez; como fui a primeira vez que me pediram para implementar a funcionalidade Desfazer. Se não fosse o livro "Design Patterns", minha implementação provavelmente seria algo como armazenar um instantâneo dos dados após cada operação de mudança de estado *** - uma abordagem muito propensa a erros e terrivelmente ineficiente.

Portanto, sim, alguns dos padrões se tornam menos relevantes ao longo do tempo e, à medida que você se torna um programador experiente, pensa menos sobre eles. Mas para um iniciante, eles são valiosos, desde que você se lembre de que eles são os meios para resolver um problema - e não uma busca para usar o maior número possível.

* a cotação pode não ser 100% precisa, pois é retirada da memória

** na minha experiência, está ficando muito comum as empresas escolherem mecanismos de entrega na Web para aplicativos de linha de negócios internos.

*** Depois de aprender a programação funcional e estruturas funcionais de dados, essa pode ser a maneira que eu resolveria hoje.

A adesão servil aos padrões de design pode ser prejudicial - os padrões são soluções documentadas para problemas comuns, mas não são manuais de instruções. No entanto, apenas porque eles são discutidos detalhadamente e, em alguns casos, aplicados fora dos domínios de problemas efetivos, não significa que eles não tenham valor algum. Eles são um conjunto de princípios - chame de uma estrutura - a serem usados ​​ao projetar a arquitetura de um programa, permitindo que o arquiteto dê uma impressão de como ele / ela gostaria que a solução funcionasse. Uma boa equipe de desenvolvimento os vê como uma base para a funcionalidade, e não como uma especificação funcional.