O que define um bom desenvolvedor? As qualidades necessárias a um profissional que decide trabalhar com criação de software variam imensamente. Uns dirão que boa lógica é essencial, outros que o conhecimento de linguagens de programação é fundamental e outros que a interação com o usuário é o mais importante. A verdade é que, dependendo do foco do trabalho, as qualidades variam muito. E mesmo dentro do mesmo foco haverá divergência de opiniões.
Ainda que você se carregue de conhecimento de linguagens de programação, algoritmos, lógica e das mais diversas siglas (OO, UML, SOA, etc.), ainda é possível que o código saia ineficiente ou difícil de manter.
É aí, dirão, que entra a senioridade. Um analista sênior certamente passou por mais situações e viu mais projetos e aplicativos do que um analista júnior. Certamente um profissional experiente será capaz de capitalizar seus conhecimentos e produzir um bom software, já que viu, em outras circunstâncias, o que dá certo e o que dá errado, o que funciona e o que não funciona.
Alguém já pensou nisso antes
Em algum momento, alguém notou que esses analistas não só faziam um bom trabalho, mas o faziam de forma parecida. Descobriram-se semelhanças no desenho de diversos analistas e foi notado que problemas semelhantes possuíam soluções semelhantes. A partir desses trabalhos surgiram padrões de desenho de aplicativo, ou, em inglês, design patterns. Esses design patterns de certa forma “normalizaram” essas experiências.
Os design patterns resolvem muitos dos problemas com que deparamos no dia-a-dia. E novos padrões ainda podem ser descobertos. Nessa série de artigos não conseguiremos abranger todos os padrões existentes, mas veremos alguns dos mais aplicáveis e interessantes.
Se você já pegou um livro ou um artigo de design patterns há grande chance de ter se divertido tanto quanto quando ouve um giz riscando uma lousa. A ideia dessa série de artigos é fugir da péssima fama de que design patterns são entediantes e deixá-los mais próximos do dia-a-dia além de um pouco mais divertidos.
Porque usar design patterns?
Certamente essa pergunta vai surgir. “Não posso utilizar um framework de design patterns?” Design patterns não são códigos, são padrões, e por isso não podem ser compilados em um arquivo executável ou framework. São idéias abstratas e o código gerado com essas idéias é sua concretização. Tal código sempre trabalha na resolução de um problema específico, não podendo ser compilado em um framework. O foco então é aprendemos as idéias para aplicarmos a nossos problemas específicos, aqueles que somos pagos para resolver.
Você vai notar que os padrões sempre focam na facilidade da mudança e manutenção, na reutilização dos componentes criados e buscam evitar duplicidade de código. Vai notar que o código gerado com aplicação de padrões previamente testados e comprovadamente funcionais vai deixar o código mais fácil de ler e de entender, de manter, e, principalmente, de mudar.
...
