Padrões de design sufocam a criatividade

Muitos anos atrás, eu estava conversando com um professor de Economia sobre padrões de design, como eles estavam estabelecendo uma linguagem comum para programadores e como eles estavam resolvendo problemas conhecidos de uma maneira agradável, etc.

Então ele me respondeu que essa é exatamente a abordagem oposta que ele usaria para seus alunos de economia. Ele geralmente apresentava um problema e pedia a eles que encontrassem uma solução primeiro, para que pudessem pensar primeiro e tentar encontrar maneiras de resolver o problema primeiro, e somente depois disso ele apresentou a solução "clássica".

Então, eu estava pensando se a abordagem do "padrão de design" é realmente algo que torna os programadores mais inteligentes ou mais burros, já que muitas vezes estão apenas obtendo a "solução certa para esse problema" em vez de talvez usar a criatividade e a imaginação para resolver algum problema em um maneira nova e inovadora.

O que você acha?

Seu professor de economia está absolutamente correto.

Os Padrões de Design de Software são principalmente uma maneira de os desenvolvedores de software experientes se comunicarem . Eles são uma abreviação de soluções estabelecidas para problemas conhecidos.

Mas elas devem ser usadas apenas por pessoas que entendem como resolver o problema sem o padrão ou que tenham apresentado um padrão semelhante por si mesmas. Caso contrário, eles terão o mesmo problema que o codificador de copiar / colar; eles terão código, mas não entenderão como funciona e, portanto, não poderão solucionar o problema.

Além disso, muitos dos padrões de design são padrões corporativos , padrões que devem ser usados ​​em sistemas de software corporativos grandes. Se você aprender as maravilhas do contêiner Inversion of Control, poderá usá-lo em todos os programas que escrever, mesmo que a maioria dos programas não precise (existem melhores maneiras de injetar suas dependências em programas menores, de maneira que não requer um contêiner de IoC).

Aprenda os padrões. Entenda os padrões e seu uso apropriado. Saiba como resolver o mesmo problema sem o padrão (todos os padrões de software são abstrações sobre algoritmos fundamentais). Então, você poderá usar padrões de software com confiança, quando fizer sentido.

A maneira como as pessoas do Design Patterns querem que você olhe para o Design Patterns é como um conjunto de soluções que você pode aplicar se surgirem problemas semelhantes. Eles não querem que você pense nelas como as únicas soluções possíveis, dadas por Deus a Moisés esculpidas em tábuas de pedra na montanha.

Infelizmente, algumas pessoas os consideram algo mais próximo dos escritos sagrados do que um monte de exemplos de projetos que podem ser aprendidos. Isso mata a criatividade e cria um culto à carga.

Seu professor de economia mencionou apresentar aos alunos o problema e pedir que tentassem resolvê-lo primeiro, o que é uma boa técnica educacional, mas ele tinha uma solução para demonstrá-los. Ter uma série de soluções para muitos problemas diferentes em sua cabeça é uma coisa boa, e é algo que os Padrões de Design tentam ser. Eu acho que falha de alguma maneira (Singleton incentiva abordagens ruins, um foco míope no OO imperativo etc.), mas poderia ser usado bem com inteligência e bom gosto. No entanto, é um erro pensar que toda solução de exemplo possível no software deve ser um padrão oficial de design.

Se você olhar para um problema e se perguntar "Qual é o padrão de design para isso?", Estará fazendo algo errado e será menos provável que encontre uma solução que esteja olhando para você.

Se você olhar para um problema e se perguntar "Como posso resolver isso?", Se houver uma solução não padronizada, você a verá e, se houver um padrão adequado, você também verá.

Eu também acho que seu professor de economia está correto e é uma maneira de aprender qualquer coisa em primeiro lugar; No entanto, vamos olhar assim: você manteria a roda em segredo e deixaria que todos a reinventassem, por uma questão de criatividade ? Espero que você diga Não, porque nem todas as pessoas são criadas / capazes de inventar suas rodas - e se forem, elas farão isso em algum momento, não importa se estão cientes da existência da roda ou não.

Vamos voltar aos programadores; Como sou desenvolvedor de web por dia, o MVC é uma daquelas coisas com as quais interajo diariamente. Várias vezes tentei construir minhas próprias estruturas, aprendi muito, mas todas foram basicamente malsucedidas. Eu tentei o meu melhor, mas o que aconteceria se não houvesse MVC por aí? Bem, simples, meu código fonte é péssimo - em termos de confiabilidade, manutenção e extensibilidade.

Eu acho que é o mesmo para a maioria de nós. Se ninguém falar sobre DI - como uma boa prática, quantos aplicativos corporativos devem sofrer ou falhar até que seus desenvolvedores aprendam a lição?

O segundo ponto são os padrões da indústria . Se você não ensinará MVC aos desenvolvedores da Web, estará pronto para enfrentar todas essas estruturas não-padrão que você precisa para dedicar algum tempo para aprender o modo de fazer as coisas primeiro e depois perceberá que algumas dessas estruturas podem tenha uma boa idéia, mas a maioria deles terá sérias falhas de design que podem ter sérias conseqüências para o seu projeto de software - mesmo estruturas conhecidas ainda enfrentam falhas de design de tempos em tempos.

Mas o que aconteceria se tivéssemos todas essas idéias legais e as juntássemos e esses desenvolvedores inteligentes tirassem as coisas boas de todas essas experiências e fizessem uma estrutura muito legal que funcionasse melhor para esse problema específico? Depois de criar os padrões de design . Se você é uma criatura viva, então não há outro caminho; Até os animais seguem as melhores práticas e os padrões de design no seu dia-a-dia.

Não reinvente um martelo, mas não trate todos os problemas como um prego

Os padrões de programação economizam muito tempo, pois oferecem soluções prontas para o uso, bem documentadas e testadas com casos médios que você pode esquecer facilmente. Mas você precisa aprender (e pensar) quando usá-los.

Parafraseando sua pergunta: aprender a dirigir me faria andar mais rápido ou apenas andar mais devagar?

Aprender a usar o padrão de programação não significa que você não deve procurar encontrar soluções próprias. Ainda haverá problemas suficientes para exercitar sua criatividade. Conhecer os padrões de programação apenas permitirá que você seja rápido com problemas conhecidos e se concentre naqueles que são menos triviais.

Voltando à segunda parte da sua pergunta - seu professor está certo?

Sim, ele está certo . O objetivo principal dos estudos é aprender os alunos a pensar . Eles precisam tentar encontrar suas próprias soluções para o problema e depois confrontá-los com as soluções existentes. Só assim eles podem realmente entendê-los. Se você aprender os padrões primeiro, corre o risco de que eles aprendam apenas mecanicamente a aplicá-los e a não entender o que está por trás.

Essa é a razão pela qual você ensina os alunos a programar, e os padrões são introduzidos em outros semestres.

Eu recomendaria absolutamente não ensinar programação ensinando padrões de design. Você não pode aplicá-los bem sem entender os princípios por trás deles; portanto, ensinar esses princípios é muito mais importante.

Eu costumo pensar que os padrões de design também não são realmente tão valiosos para os programadores que trabalham. Se você entende completamente os princípios envolvidos em um determinado padrão de design, em uma situação em que é uma boa solução, você naturalmente tenderá a construí-lo (ou algo semelhante) de qualquer maneira apenas como uma questão de disciplina, mesmo que você não saiba que era um padrão com um nome. Qualquer que seja o tempo que você gasta em aprender padrões, pode ser melhor gasto aprendendo a pensar em código em geral. Se suas habilidades de "resolução de problemas em geral" não são adequadas, você não pode escrever um bom código, por mais que seja bom em aplicar algum conjunto de padrões. E se suas habilidades de "resolução de problemas em geral" forem boas, você poderá resolver os problemas, mesmo que não conheça um único padrão.

Eu também acho que em um mundo ideal não haveria ser quaisquer padrões de design, porque as idéias bastante comum a ser chamado de um padrão todos seriam bem-implementado em bibliotecas e nós realmente ser reutilização de código em vez de constantemente reescrevendo -lo. Imagine se houvesse um "padrão de design de expressão regular", que exigisse a implementação de um pequeno mecanismo de expressão regular toda vez que você quisesse usá-lo. Os padrões de design são apenas bibliotecas que não podem ser escritas porque a linguagem não fornece os recursos de abstração corretos.

Essa é realmente outra razão para não se importar muito com eles; eles não são nem de longe tão universais quanto às vezes é reivindicado, mas, de fato, estão fortemente vinculados às maneiras particulares de estruturar programas que uma determinada linguagem permite / incentiva. Um livro de padrões de design escrito para Python seria completamente diferente de um escrito para Java e ainda mais diferente de um escrito para uma linguagem não imperativa como Haskell. Melhor entender em um nível mais profundo, e você poderá descobrir os padrões de design em qualquer idioma com o qual se familiarize.

Comércio e educação têm objetivos diferentes. Se eu estivesse ensinando aos alunos padrões de design, adotaria a mesma abordagem. Mas em um ambiente de produção, tempo e eficiência são tudo.

Além disso, a (macro) economia fora da sala de aula é uma coisa diferente. Você vê governos dizendo: "Uau! Agora estamos super entediados em fazer os impostos e da mesma maneira, então vamos tentar algo super maluco dessa vez"? Não, você não, porque tais experiências selvagens podem destruir a economia além do reparo. Em vez disso, eles tendem a seguir abordagens testadas e comprovadas: aumentar a taxa de juros, anunciar isenção de impostos, etc. Em outras palavras, eles contam com padrões de design.

A resposta é, claro, sim.

Os padrões de design são uma ferramenta de aprendizado maravilhosa, contanto que se dedique um tempo para descobrir como eles funcionam e por que trazem o valor que trazem.

Eles também podem ser grandes impulsionadores da produtividade, acompanhando rapidamente um processo de design, porque fornecem soluções familiares para problemas que surgem o tempo todo.

No entanto, se eles produzem um curto-circuito no projeto demais ou as pessoas se tornam dogmáticas e precisas sobre seu uso, elas têm o efeito oposto.

Os padrões de design são obviamente menos criativos. Essa é a ideia toda. A criatividade é um recurso escasso. Você não deve desperdiçá-lo com problemas que não precisam de criatividade. É muito mais fácil, rápido e mais provável que funcione, se você resolver um problema da mesma maneira que centenas de desenvolvedores antes de você. Código chato e desinteressante que faz seu trabalho é realmente bom.