Padrões Criacionais - Artigo ClubeDelphi 130

Os padrões GoF documentam cinco padrões criacionais: Builder, Abstract Factory, Factory Method, Prototype e Singleton. Apesar de estes padrões possuírem implementações diferentes entre si, resumidamente todos têm o objetivo de controlar como as classes do projeto serão criadas, evitando o uso descontrolado de instruções como “TMinhaClasse.Create”. A diferença entre estes padrões está nas consequências que cada um deles carrega consigo – consequências boas e/ou ruins.

O problema em espalhar o uso do construtor das classes sem controle algum é que o projeto fica preso às implementações quando deveria estar preso às interfaces. Consequentemente um projeto assim torna-se inflexível, o que aumenta o tempo gasto com manutenções. Imagine um projeto com uma interface ICarro. Esta interface possui diversas implementações diferentes, como por exemplo, TMustang, TFerrari, TAudiR8 e assim por diante. Se a criação/fabricação destas classes não for separada e controlada em um único local, em pouco tempo o projeto estará confuso e cheio desvios (instruções “if else”, por exemplo), necessários para decidir qual das implementações de ICarro deve ser usada.

Neste cenário adicionar um novo tipo de carro, será uma tarefa cansativa e talvez desastrosa, pois o programador terá que procurar e alterar todos os locais onde existe uma tomada de decisão para descobrir qual tipo de carro deve ser criado. Este tipo de ação normalmente gera erros, exatamente por ser uma tarefa cansativa. A situação citada neste exemplo pode ser facilmente contornada se a forma comum de se criar um objeto, usando “TMinhaClasse.Create” for evitada.

O problema

Dando continuidade ao exemplo dos carros, imagine um projeto para jogo de corridas. Neste projeto existem diversos tipos de carros: TMustang, TFerrari, TAudiR8 e assim por diante. Essas classes são usadas em diversos pontos do projeto. Para poder criar um tipo de carro, é sempre necessário avaliar algum parâmetro para decidir qual o carro escolhido pelo usuário. Sendo assim, sempre que um carro precisa ser criado, uma instrução parecida com a Listagem 1 deve ser escrita.

O código é extremamente simples. Talvez seja devido a esta simplicidade que este tipo de codificação não receba a devida atenção. A verdade é que apesar de simples, instruções como essa podem causar verdadeiros desastres ao projeto. Se um carro precisar ser criado em vários pontos diferentes do projeto, logo instruções como a da listagem em questão estarão espalhadas por todo o projeto e quando um novo tipo de carro for adicionado, todos estes pontos deverão ser alterados.

Esta forma de programar – espalhando a criação dos carros em vários pontos – desrespeita dois princípios importantes: Programe Para Interface e o Princípio de Responsabilidade Única. A seguir veja um pouco mais sobre estes dois princípios.

Listagem 1. Criando um tipo de carro

1      Var

2        Carro: ICarro;

3      Begin

4        if GetTipo = 1 then

5          Carro := TMustang.Create

6        else if GetTipo = 2 then

7          Carro := TFerrari.Create

8        else if GetTipo = 3 then

9          Carro := TAudiR8.Create

10       Else

11         raise Exception.Create('Tipo de carro desconhecido');

"