Padrões Criacionais - Artigo Revista Clube Delphi 129

Talvez um dos livros mais importantes (pelo menos o mais famoso), sobre os padrões de projetos seja “Design patterns: elements of reusable object-oriented software” (em português, “Padrões de Projeto: Elementos de Software Orientado a Objetos Reutilizável”), publicado em 1994. Nele os autores Erich Gamma, Richard Helm, Ralph E. Johnson e John Vlissides descrevem 23 padrões de projetos divididos em três categorias: padrões criacionais, padrões estruturais e padrões comportamentais.

Estes padrões normalmente trabalham juntos, pois dificilmente você terá um problema cuja solução seja simplesmente implementar um determinado padrão. Na maioria das vezes, você precisa compreender o conceito apresentado pelo padrão. Só assim você será capaz de interpretá-lo e identificar situações para usá-lo no seu projeto.

Os 23 padrões publicados neste livro receberam o apelido de padrões GoF (Gang of Four – Gangue dos Quatros), devido aos quatro autores do livro. “Design patterns: elements of reusable object-oriented software” difundiu o conceito de padrões de projeto, que até aquela época estava sob o domínio de poucos. Por conta disto, a publicação do livro é considerada por muitos como um divisor de águas.

Os padrões GoF são os padrões mais populares, mas existem outros como, por exemplo os padrões GRASP (General Responsibility Assignment Software Patterns - Padrões de Princípios Gerais para Atribuição de Responsabilidade). Dentre os vários padrões GRASP, os mais populares são: Creator, Information Expert (ou apenas Expert) e Controller. Enquanto os padrões GoF exploram soluções bem específicas, os padrões GRASP exploram as práticas e princípios da orientação a objetos.

Do que é feito um padrão

Um padrão de projeto não passa de uma solução flexível e reutilizável para um problema de projeto. Digo “problema de projeto”, por que os padrões de projetos não são soluções para o software em si, por exemplo, um padrão de projeto não diz como um software deve estabelecer conexão com o banco de dados, mas ele diz como o projeto deve ser codificado para que a camada de conexão seja flexível o máximo possível. Enfim, um padrão de projeto soluciona um problema de projeto.

Além de abordar e solucionar um problema de forma a tornar o projeto mais flexível, um padrão ainda precisa ter um nome e uma descrição das consequências – boas e/ou ruins – da sua implementação. Todo padrão de projeto terá no mínimo estas quatro características: nome, problema, solução e conseqüências:

• Nome: resume o problema, a solução e/ou a conseqüência do uso;

• Problema (ou motivação): descreve a situação de projeto em que o padrão pode ajudar se for implementado;

• Solução (ou intenção): mostra como aplicar os padrões descrevendo quais são os participantes (classes), do padrão e qual o papel de cada um;

• Consequências: descreve qual o impacto no projeto devido ao uso deste padrão – é normal que um padrão tenha consequências boas e também ruins.

O nome diz muito a respeito de um padrão. Quando você lê “Padrão Observer”, o que mais poderia pensar além de que este padrão faz uma classe observar outra classe. O que não é possível saber apenas olhando o nome do padrão é como ele faz o que diz fazer. Para isto serve a descrição do problema em que ele se aplica.

A descrição do problema é sempre a mais abstrata possível, para que qualquer programador de qualquer linguagem seja capaz de compreendê-la. Isto quer dizer que você não vai encontrar uma descrição de problema como esta: “Se você estiver precisando criar projeto com a capacidade de trocar de aparência, use o padrão Abstract Factory.”. Não teria graça se fosse assim. Uma descrição mais real é: “Se precisar criar uma família de objetos sem depender de quem são os integrantes desta família ou de como eles são criados, use o padrão Abstract Factory.”. A diferença é que a primeira frase descreve UM PROBLEMA, enquanto que a segunda frase descreve O PROBLEMA que o padrão Abstract Factory pode ajudar a resolver.

Depois de interpretar a descrição do problema e concluir que ele pode ajudar o seu projeto, você vai precisar conhecer quais são as consequências de usá-lo. Talvez você ache que as consequências são ruins ou que uma das consequências seria “cara demais” para o projeto – se chegar a esta conclusão o melhor a fazer é procurar por outro padrão, pois diversos padrões diferentes podem solucionar um mesmo problema, cada um com suas consequências – boas e ruins – de uso.

Por fim, resta a descrição da solução, cujo objetivo é explicar como implementar o padrão de projeto. A descrição da solução é tão abstrata quanto a descrição do problema, por isso é necessário interpretar a solução ao invés de decorá-la. A solução apresenta, por meio de um diagrama de classes, quais são os participantes (as classes), da solução além de uma explicação de qual é o papel de cada participante.

As categorias

Além das características que você leu no último tópico “Do que é feito um padrão”, os padrões de projetos GoF também pertencem a uma destas três categorias: criacionais, estruturais e comportamentais:

• Criacionais: oferecem mecanismos diferentes para separar a criação de objetos;

• Estruturais: definem maneiras de criar composições complexas ou adicionar comportamentos a um objeto sem necessariamente precisar alterar o código da classe;

• Comportamentais: padrões especializados em comunicação entre os objetos – definem maneiras dos objetos se comunicarem sem precisar conhecer muito (ou nada), um do outro.

Os padrões comportamentais são voltados a comunicação entre os objetos e classes. Um projeto tende a entrar em colapso quando a comunicação e interação entre seus objetos e classes não está bem projetada. Os padrões GoF definem 11 padrões comportamentais, cujos mais populares são: Command, Observer, Strategy e Iterator.

Já com os padrões estruturais você consegue usar da herança para criar interfaces compostas. Isto significa ter a capacidade de usar a composição de objetos para criar novas funcionalidades em tempo de execução.

Os padrões criacionais, que inclui o Builder, são padrões com objetivo de diminuir a dependência do construtor das classes, isto quer dizer que, quando se implementa um padrão criacional o número de instruções como esta “TMinhaClasse.Create” tende a diminuir. Veja a seguir." [...] continue lendo...