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

104

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

Acho que existem duas razões principais para isso:

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

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

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

O ponto também é que geralmente quando as pessoas enfrentam um problema e não têm muito tempo, elas tentam usar um padrão. Isso significa copiar e colar o código existente em 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 ele não está profundamente familiarizado com ele.

    
por Sergey 24.04.2011 / 16:32
fonte

10 respostas

252

Para meu dinheiro, acho que todo mundo está perdendo o ponto dos padrões de design. É raro que eu sento me perguntando qual padrão devo usar em 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 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 os scripts de transação, se todos nós sabemos o que esses dois termos significam. E assim por diante.

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

Mesmo que você não saiba do que estou falando quando disser "O padrão do observador é ideal para isso", você poderá usar o google facilmente.

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

    
por 24.04.2011 / 18:11
fonte
31

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 onde devemos apenas ter uma instância, mas que não podem ser feitas estáticas e globais".

As soluções que os padrões de design fornecem são úteis, mas são soluções que você provavelmente já pensou se enfrentasse os problemas que elas resolvem. Um certo nível de maturidade é necessário para entender os padrões de projeto - se você nunca precisou resolver o problema, não verá o valor ou o interesse na solução.

    
por 24.04.2011 / 17:53
fonte
13

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

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

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

por 06.05.2011 / 17:10
fonte
11

Acho que a afirmação de que os padrões de design dificultam a inovação é completamente falsa. Você deve saber onde já existe, então você não precisa reinventar a roda. Por serem temporários, os padrões como um todo se aplicam a 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 uma espécie de obsessão por elas. Certa vez, pedi a um cliente que me pedisse "incluir pelo menos mais dois padrões" (WTF ?!), já que, devido à falta de palavras-chave no meu código, não parecia ser suficientemente interessante.

    
por 24.04.2011 / 16:38
fonte
6

Talvez o conceito de anti-padrões seja pertinente. Eu 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, muitas vezes reservado como a prerrogativa do arquiteto de software em um projeto, mas, realisticamente, algo que pode ser elaborado por consenso na proverbial equipe "bem gelada".

Mas padrões de projeto 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 atenuar) as conseqüências das escolhas de design. Uma boa equipe poderia criar seu próprio vocabulário para tais discussões, mas não é realmente tão ruim referenciar os padrões definidos pelos autores que estiveram lá, feito isso.

    
por 24.04.2011 / 17:46
fonte
4

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 tanto situacionais, mas com algumas das forças são do mundo real e com os outros as forças são das ferramentas. As ferramentas mudam muito mais rapidamente que o mundo real.

    
por 24.04.2011 / 17:43
fonte
3

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

    
por 06.05.2011 / 16:56
fonte
1

Há benefícios em projetar padrões quando eles reduzem a quantidade de tempo que seus colegas ou clientes gastam pensando "Como isso funciona?". Mesmo que não haja sentido em impor um padrão para padronização, se houver uma maneira comum e bem compreendida de fazer algo, sempre que um codificador procurar esse padrão esperando encontrá-lo e o fizer, você terá feito o trabalho deles e o seu. mais fácil.

    
por 25.04.2011 / 10:49
fonte
1

Eu acredito que a turma de quatro pessoas classifica os padrões de design como

a common solution to a commonly occurring problem*

Então, sim, os padrões são relevantes quando ocorre o mesmo tipo de problema. 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 há um padrão de design, há um padrão de problemas.

Algumas linguagens de programação podem ter soluções nativas para alguns desses problemas. O livro "Design Patterns" em si menciona que o padrão de visitante é de pouco valor se você estiver usando o CLOS, já que o multi-dispatch é suportado nativamente pelo CLOS, o problema que o padrão Visitor está tentando resolver.

Além disso, o .NET framework tem um mecanismo de construção no evento para publicar eventos para vários ouvintes, tornando o padrão Observer menos relevante neste contexto.

A mudança de aplicativos de desktop para aplicativos da web ** também altera o tipo de problemas de programação que temos que resolver. Muitos dos padrões no livro "Design Patterns" são relevantes para aplicativos de desktop, mas não tanto para aplicativos da web. É claro que, 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 novato e enfrenta um novo tipo de problema pela primeira vez; como eu fui a primeira vez que me pediram para implementar a funcionalidade Desfazer. Se não fosse pelo 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.

Então, sim, alguns dos padrões se tornam menos relevantes com o passar do tempo e, à medida que você se torna um programador experiente, você pensa menos neles. Mas para um novato, 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 máximo 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 internos de linha de negócios.

*** depois de aprender programação funcional e estruturas de dados funcionais, então isso pode realmente ser o jeito que eu resolveria hoje.

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

    
por 02.11.2014 / 05:55
fonte