Padrões de Projetos, por onde começar?

Tempo de leitura: 4 minutos

Estamos em uma série de artigos falando sobre padrão de projetos e como aplicá-los utilizando o Delphi. Como vimos na introdução ao histórico de padrões de projetos descrito no artigo anterior, o GOF (Gang of Four) catalogou 23 padrões de projetos.  Fora estes, existem outros padrões de projetos documentados por outros profissionais, associações e empresas.  Dentro dos 23 padrões de projetos do GOF temos aqueles que são mais utilizados em projetos no dia-a-dia, entre eles podemos citar:  Singleton, Factory, Abstract Factory, Composite, Prototype, Proxy. Há outros que embora não muito utilizados (falo pela minha percepção) merecem destaque pelos problemas que resolvem, por exemplo, Template Metody, Facade e Builder.

Obviamente que o objetivo dessa série de artigos não é abordar todos os padrões de projeto. Seria inviável tratar de todos os padrões existentes nem mesmo se nos referíssemos somente aos padrões GOF, até porqu

Livro do GOF - Leitura obrigatória
Livro do GOF – Leitura obrigatória

e o objetivo é dar uma introdução a vocês do que é esse histórico que eu acabei relatei no artigo anterior e como implementar alguns desses padrões no Delphi. Vamos quebrar o MITO de que padrões pertencem a esta ou aquela linguagem e principalmente lhe estimular você a criar os seus padrões, por que não?

Já ouvi alguns citando que padrão de projeto é um recurso do Java, ou característico da linguagem Java. Isso é um erro, padrões de projetos são boas práticas, são soluções reutilizáveis para serem aplicadas em todo e qualquer projeto de software que seja orientado a objeto, independente da linguagem.  Com padrões, você aplica a solução descrita pelo padrão e implementa de acordo com a linguagem que você está trabalhando. Você pode implementar padrão de projeto no seu projeto orientado a objeto feito em Delphi, feito em C#, feito em Java, feito em PHP, feito em qualquer linguagem dita orientada a objeto. Por quê? Porque os padrões de projetos usam os fundamentos da orientação a objeto (herança, abstração, polimorfismo, encapsulamento), para aplicar as soluções para os problemas a que se destinam. Padrões de projetos não é algo pronto que deve ser seguido ipsis litteris. Eles são ideias, são sugestões, sugestões que os estudiosos (no caso o GOF) nos dão para evitar problemas recorrentes em projetos de softwares.

Qualquer um pode criar um padrão de projeto, desde que consiga, de fato, comprovar que aquilo é uma solução que pode ser aplicada em qualquer projeto, e não num projeto específico em si. Eu recomento fortemente que você aprofunde seus estudos neste assunto pois mesmo que você não participe de projetos totalmente OO ou em projetos de pequeno porte que não justifique a aplicação de vários padrões de projetos, o ato de estudar o assunto abrirá sua mente, ampliará seu entendimento sobre projetos de softwares orientados a objetos. Se me permite gostaria de sugerir algumas leituras que considero obrigatórias para quem deseja aprofundar seus conhecimentos em padrão de projetos.

Livro com linguagem didática e acessível
Livro com linguagem didática e acessível

O livro padrão de projetos original do GOF em sua versão em português é o primeiro da fila, ele trata de todos os padrões dos 4 pesquisadores com exemplo de aplicação destes padrões em projetos de software, conhecimento de UML é essencial para entender os diagramas. Uma segunda sugestão é o livro da série Abra a Cabeça, Padrões de Projeto em Java, que, embora seja em Java, você pode adaptar para qualquer linguagem porque vêm os diagramas (UML). O mais interessante deste livro é a linguagem utilizada, ele trata o assunto de uma forma bastante didática e bem natural. Por exemplo, ele faz uma entrevista com a classe Singleton perguntando se ela não se sente isolada por ser a única no projeto.

Lembre-se, quando a única ferramenta que temos nas mãos é um martelo, tudo vira prego. Não vá pensar que agora todo projeto deve obrigatoriamente implementar um ou mais padrão do GOF, ou que um projeto que não os use não tem qualidade, não é bem por aí. Temos sempre que primar pela coesão de nossas classes, baixo acoplamento, seguir boas práticas e manter um padrão, nem que seja o nosso padrão.

Fico conosco e vamos ver nos próximos artigos como é a teoria na prática.

Abraços e até a próxima.