Muitos desenvolvedores consideram o livro Padrões de design um clássico.
Então, o que é um padrão de design?
Um padrão de design nomeia, motiva e explica sistematicamente os um projeto geral que aborda um problema de projeto recorrente em sistemas orientados a objetos. Ele descreve o problema, a solução, quando aplicar a solução e suas consequências. Também fornece dicas e exemplos de implementação. A solução é um arranjo geral de objetos e classes que resolvem o problema. A solução é personalizada e implementada para resolver o problema em um contexto específico.
Certamente vale a pena para todo programador ler Design Patterns pelo menos uma vez, nem que seja para aprender o vocabulário compartilhado de padrões comuns. Mas tenho dois problemas específicos com o livro:
- Os padrões de design são uma forma de complexidade. Como acontece com toda complexidade, prefiro que os desenvolvedores se concentrem em soluções mais simples antes de indo direto para uma receita complexa de padrões de design.
- Se o senhor se pegar escrevendo com frequência um monte de código de padrão de projeto padrão para lidar com um “problema de projeto recorrente”, isso é não boa engenharia… é um sinal de que sua linguagem está fundamentalmente quebrada.
Em sua apresentação Os “padrões de design” não são, Mark Dominus diz a solução “Design Patterns” é transformar o programador em um processador de macros sofisticado. Não quero colocar palavras na boca de Mark, mas acho que ele concorda com pelo menos uma de minhas críticas.
Mas Dominus também se aprofunda no material de origem mais do que a maioria. Ele cita o livro de Christopher Alexander A Pattern Language (Uma Linguagem Padrão)que foi a inspiração para os padrões de design.
Dominus resume o livro da seguinte forma:
Suponha que o senhor queira projetar um campus universitário. O senhor deve delegar parte do projeto aos alunos e professores, caso contrário, o prédio de física não funcionará bem para o pessoal de física. Nenhum arquiteto sabe o suficiente sobre o que o pessoal da física precisa para fazer tudo sozinho. Mas o senhor não pode delegar o projeto do cada sala para seus ocupantes, porque então o senhor terá uma pilha gigante de entulho.
Como o senhor pode distribuir a responsabilidade pelo design em todos os níveis de uma grande hierarquia e, ao mesmo tempo, manter a consistência e a harmonia do design geral? Esse é o problema de design arquitetônico que Alexander está tentando resolver, mas também é um problema fundamental do desenvolvimento de sistemas de computador.
Essa é a principal percepção que orienta os dois livros. Infelizmente, a Dominus acredita que o a versão do Gang-of-Four obstrui a mensagem de Alexander, substituindo o pensamento e o insight reais por uma mentalidade de modelo de geração de código de recortar e colar, sem sentido:
O ponto de a conversa é o seguinte: Os “padrões de design” que o senhor obtém do livro Gang-of-Four não são os mesmos que a ideia de “padrões de design” apresentada nos livros de Alexander. As pessoas dizem que são, mas não são a mesma coisa. A ideia de Alexander é muito boa e pode ser útil para os programadores. Mas pouquíssimos programadores vão se informar sobre ela, porque acham que já sabem o que é. Mas, na verdade, eles conhecem essa outra ideia que, por acaso, tem o mesmo nome.
Portanto (mais uma vez), precisamos dar uma nova olhada em Christopher Alexander. Esqueça o que eu disse sobre o maldito padrão iterador.
Sei que não é tecnicamente um livro sobre desenvolvimento de software, mas considere que o este conselho de Don Park:
Se Eclipse é uma cidade em expansão para a qual inúmeros desenvolvedores e empresas continuam a afluir, mas agora se parece com Los Angeles, com um centro minúsculo cercado por uma extensão infinita de bairros suburbanos que não se distinguem uns dos outros a não ser por seus nomes. Embora um dos principais pioneiros por trás do Eclipse seja Eric Gamma, um dos quatro autores do infame livro Design Patterns, sinto que não está sendo dada atenção suficiente aos conceitos originais que inspiraram o livro, conceitos capturados em livros de Christopher Alexander.
O senhor poderia ler Padrões de projeto como qualquer outro desenvolvedor de software antes do senhor. Mas sugiro humildemente que o senhor vá mais fundo e leia Uma linguagem de padrõestambém, porque o as ideias são mais importantes do que o código.