Qual a importância dos padrões de design na programação?

Sou estudante universitário e comecei a aprender sobre padrões de design e estou lutando para entender o propósito deles. Eu tentei pesquisá-los, mas todos os recursos que encontrei parecem falar sobre eles de maneira acadêmica, e não profissional.

Qual é o seu propósito e é importante aprender?

Os padrões de design são ótimos para comunicar sua intenção muito rapidamente - todos sabem o que é uma fábrica.

O que é realmente muito, muito ruim é começar a tentar ajustar seu código aos padrões, ou separar responsabilidades de acordo com os padrões, ou algo assim. Uma coisa é dizer "Este objeto é uma fábrica" ​​e outra é dizer "Este objeto deve ser exclusivamente uma fábrica".

No artigo da wikipedia sobre Design Patterns :

A utilidade de falar em padrões é ter uma terminologia comum para discutir as situações que os designers já veem repetidamente.

Por um longo tempo, tivemos um problema sério na engenharia de software: você contrata um recém-chegado para um projeto e, por mais que eles conheçam a linguagem de programação, leva meses para se atualizar sobre como as coisas são feitas em seu projeto. projeto antes que eles possam ser produtivos. Na engenharia de hardware, eles resolveram esse problema há muito tempo: eles têm uma terminologia comum chamada 'diagramas esquemáticos'. Você contrata um engenheiro de hardware, fornece a eles os esquemas do seu projeto de hardware pela manhã, deixa-os estudá-los e, à noite, antes que seja hora de terminar o dia, eles podem pegar a pistola de solda e se tornar produtivos. Temos tentado encontrar maneiras de melhorar isso; a padronização das linguagens de programação era uma maneira; bibliotecas padrão (bibliotecas de classes hoje em dia) têm sido de outra maneira; mas uma das maneiras mais importantes talvez tenha sido os padrões de design. Então, eles são importantes? Pode apostar!

Na verdade, existem duas razões substanciais diferentes para a existência de padrões.

O primeiro já foi explicado muito bem: o uso de padrões lubrifica a comunicação entre os desenvolvedores. Se você e eu entendemos que, quando digo 'Observer', estou falando de uma estrutura muito específica de código, posso descrever rapidamente como funciona um pouco de código que usa esse padrão. A alternativa é descrever completamente a solução, que consome tempo e é propensa a erros. ("Bem, eu criei essa classe virtual pura que descreve e faz interface com objetos do consumidor e, em seguida, criei uma classe que mantém uma lista de consumidores ativos, que ...")

O segundo benefício dos padrões é que eles são formas de solução prontas para formas de problemas comuns. Se você conhece seus padrões e, por exemplo, encontra um problema em que precisa encontrar uma boa maneira de obter informações de (possivelmente vários) objetos produtores para vários objetos consumidores, sem introduzir acoplamentos desnecessários entre classes, você reconhecerá "isso é um trabalho para um observador! " e você saberá imediatamente como resolver seu problema.

Esses benefícios também realmente se reforçam. Eles permitem que você resolva rapidamente certas classes comuns de problemas e, quando terminar, poderá comunicar rapidamente como solucionou o problema.

Compare isso com um mundo onde os padrões "não existem". Você encontra uma dessas classes de problemas, que geralmente não são problemas triviais de design, e gasta um bom tempo buscando uma boa solução (que, aliás, provavelmente será muito parecida com o padrão apropriado). Então, seu colega de trabalho aparece e quer saber como você o resolveu e passa uma hora discutindo como e por que.

Tudo isso está associado a uma ressalva que deve parecer bastante óbvia: não tente forçar os problemas a padrões que não se encaixam. Se o padrão não se encaixar no problema, a solução acabará sendo complicada e você perderá o benefício de redução de esforço dos padrões. Além disso, como seu trabalho não se ajustará mais ao entendimento dos colegas sobre o significado do padrão, você perderá o custo do benefício da comunicação. De fato, você provavelmente aumentará o custo da comunicação além do custo sem padrões, porque o uso indevido do padrão dará a seus colegas de trabalho uma falsa compreensão da solução, o que é pior do que nenhuma compreensão.

Os padrões são sobre a reutilização de idéias e conceitos e sobre o estabelecimento de uma plataforma comum / consistente para a comunicação dos mesmos.

Todos concordamos (!) Que, em teoria, a reutilização de código é uma coisa boa - mas acaba sendo mais difícil do que gostaríamos de fazer na prática (em alguns aspectos, isso está mudando, mas sempre será um desafio ) Mas, na realidade, muito do que queremos reutilizar é uma maneira de fazer as coisas, usar um tipo de modelo para construir uma solução para um problema específico - esses são os padrões. Então, você chega a um caso em que diz que uma boa abordagem para resolver o problema X é usar o Padrão Y e sabemos que os elementos do padrão Y são a, bec, e lá vamos nós. Como os padrões são amplamente compreendidos, você não precisa explicar em detalhes qual é o benefício das comunicações.

O que é interessante sobre padrões é que linguagens e estruturas estão evoluindo para fornecer melhor suporte a padrões comuns com o efeito líquido de que estamos obtendo cada vez mais reutilização de código (mais e melhores peças de lego!) Porque a maneira como criamos aplicativos (implementando padrões ) facilita a reutilização.

Os padrões de design são apenas tijolos conhecidos em que qualquer solução de software é construída. Eles são importantes devido aos seguintes motivos:

1. Eles são agnósticos de linguagem. Depois de saber qual padrão de design é apropriado para determinado problema / arquitetura / tarefa, você pode implementá-lo em qualquer linguagem de múltiplos paradigmas - seja C #, Java ou Python - a solução será, na maioria dos casos, a mesma, basta para adaptar a sintaxe. Isso significa que você pode transferir sua experiência de programação em um idioma para outros idiomas, desde que permaneça no mesmo domínio do problema (e talvez até entre domínios).

2. Apesar do fato de que os padrões de design têm ligação com o paradigma de programação , o que significa que os padrões de design para programação orientada a objetos (os mais famosos, também conhecidos como padrões "Gang of Four" ). Os padrões permitem que você entenda para que serve o paradigma e o ajudam a ir além da sintaxe.Por exemplo, eu já vi muitas implementações em C # e Java, onde as pessoas simplesmente programavam da maneira que fizeram no Basic ou Fortran - elas têm uma mente imperativa perfeita para resolver problemas e usam OOP apenas para renderizar essa solução - sem herança , sem polimorfismo, todos os métodos são públicos etc. Os padrões de design ajudam você a olhar por trás desses conceitos e ver como eles funcionam na vida real. O mesmo se aplica ao padrão de design em outros paradigmas, como programação funcional.

3. Os padrões são geralmente uma maneira útil de representar idéias e vieram para a Ciência da Computação a partir da arquitetura. Depois de entender a idéia por trás de um certo "padrão", você poderá reconhecê-lo facilmente em algum outro problema e resolvê-lo usando esse padrão (provavelmente ligeiramente modificado para resolver melhor o problema). Existem vários padrões diferentes: na integração de software corporativo , no teste de código-fonte etc. Apenas procure padrões nos livros de Ciência da Computação.

4. Além de adquirir boas práticas aprendendo padrões, você pode aprender facilmente como evitar erros tolos em seu código estudando antipadrões . Existem muitos livros apresentando erros comuns em diferentes domínios, na forma de antipadrões que são muito divertidos e educativos ao mesmo tempo. A propósito, eu amo os nomes desses anti-padrões!

Você pode pensar em um padrão como uma maneira comprovada de resolver um problema que você e outros desenvolvedores entendem. Por exemplo, o problema é criar uma lista classificada de dados e, em seguida, você pode optar por usar uma lista vinculada ou colocar dados em um vetor e classificação. Você provavelmente entende as duas opções porque já conhece o padrão de lista vinculada ou o padrão de vetor de carregamento e classificação. Você pode conhecer os prós e os contras de cada um e não precisa ver a implementação para entender o que está acontecendo.

Eu acho que você é iniciante em programação, não sugiro que aprenda cedo o padrão de design. O padrão de design de aprendizagem e compreensão precisa se basear na experiência de desenvolvimento de software. Você deve ter mais prática de codificar e descobrir qual estilo de código é ruim e depois aprender o padrão de design para melhorar o design.

A utilidade de um padrão de design depende de qual idioma você escolhe. Quanto mais poderosa a linguagem que você escolher, menos precisará entender e implementar padrões de design. Um padrão de design pode ser um sinal de que seu idioma é um saco, sem um recurso interno.

Joe Gregorio fez uma ótima conversa sobre a falta de padrões de design em Python

Padrões de design são soluções para problemas comuns encontrados no desenvolvimento de software. Sempre há mais de uma solução para alguns problemas, e os padrões de design ajudam você a decidir qual solução é a melhor, fornecendo um conjunto de boas soluções para esses problemas comuns.