Introdução aos padrões criacionais: Abstract Factory, Factory Method, Prototype e Singleton

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'); 12 //Restante do código 13 end;

Princípios de orientação a objetos

Programar orientado a objeto é tão simples quanto programar de forma estruturada, ainda mais quando se programa em Object Pascal usando Delphi como IDE. Para criar um projeto orientado a objetos, a única coisa que o programador precisa fazer é criar classes: ele não precisa implementar padrões ou seguir princípios. Usando o Delphi, fica ainda mais fácil, pois o programador estará criando um projeto orientado a objetos mesmo que não saiba o que isto significa.

Apesar de ser simples se o programador não seguir alguns princípios e padrões quando criar um projeto orientado a objetos, ele provavelmente terá muitos problemas, devido à falta de organização estrutural do código. Isto significa que a POO só é vantajosa quando usada de maneira apropriada: usando os padrões e princípios comprovados pela comunidade de desenvolvedores.

Estes padrões e princípios são técnicas que ajudam o desenvolvedor criar um projeto que aproveite o máximo das vantagens que a POO oferece, como: flexibilidade, simplicidade e baixo custo de manutenção. De fato, os padrões de projetos são técnicas que usam os princípios da OO para solucionar problemas de projetos. Por serem guiadas pelos princípios as soluções propostas pelos padrões de projetos acabam sendo flexíveis e reutilizáveis." [...] continue lendo...