Continuando a série sobre Software Design Patterns, hoje irei falar com o padrão de projeto conhecido como Builder.
Builder
Objetivo – permitir a abstração de uma complexa construção de objetos através de uma interface comum. Alguns objetos podem possuir particularidades na sua construção que podem ser ocultados através da interface de um Builder.
Para a existência do Builder, existem diversas entidades participantes, como posso lista-las abaixo:
- Director – realiza o pedido de construção do objeto através da interface que o Builder oferece.
- Builder – é a interface para a criação dos objetos utilizando as classes Concrete Builders.
- Concrete Builder – define como será realizada a implementação dos Products, realizando sua implementação e definindo métodos para o retorno do resultado.
- Product – classe que é instanciada pelo Concrete Builder e depois será retornada para o Director.
Podemos fazer uma analogia do processo realizado pelo Builder ao que é feito em um restaurante de fast-food, como é demonstrado aqui.
|
| Diagrama de seqüência em uma rede de fast-food. Retirado daqui.
|
Ou seja, o cliente ao entrar no restaurante realiza o pedido ao atendente do caixa. Os pedidos são ali realizados e as ordens para preparação de cada um dos componentes do prato são repassadas para os funcionários do restaurante, sem se especificar quem irá fazer o que. “Funcionários do restaurante” é uma interface para a chamada dos Concrete Builders que estão por detrás, que irão realizar a instanciação dos objetos e implementar os métodos para retorno dos resultados. A mesma interface “Funcionários do restaurante” será o meio com o qual o cliente irá obter o produto final.
Vamos imaginar um cenário mais real, onde pretende-se fazer um conversor de registros em um departamento de pessoal. Esse conversor deverá obter os dados através de algum tipo de registro, como um documento de texto estático, e a partir de cada registro determinar se trata de um cliente ou um funcionário da empresa. Clientes e funcionários possuem alguns aspectos em comum e outros não. O diagrama UML abaixo demonstra como seria uma estrutura utilizando o Design Pattern Builder para modelar este ambiente.
|
| Diagrama UML de um Design Pattern Builder
|
Exemplo
Segue o código em C++ que testa o Desing Pattern Builder.
abstract class Builder {
public:
abstract Person createPerson();
abstract void storePerson();
}
class CustomerConcreteBuilder: public Builder {
public:
void createPerson() {
println(“Person created!”);
}
void storePerson() {
println(“Person stored!”);
}
}
class StaffConcreteBuilder: public Builder {
public:
void createPerson(char c) {
println(“Caractere Tex”);
}
void storePerson() {
println(“Paragrafo Tex”);
}
}
class Director {
public:
void fullOfPeople() {
ifstream in ( “registers.txt” );
if ( in.is_open() ) {
string line;
while ( getline ( in, line ) ) {
// process line and get the type
switch (type) {
case CUSTOMER:
builder = new CustomerConcreteBuilder();
builder.createPerson();
builder.storePerson();
break;
case STAFF:
builder = new StaffConcreteBuilder();
builder.createPerson();
builder.storePerson();
break;
}
}
}
}
public class Operator {
public:
int main() {
Director director;
director.fullOfPeople();
}
}
O exemplo acima começa sua execução na classe Operator. Esta classe faz o papel de instanciar a classe Director e fazer com que a mesma inicie o pedido de criação de objetos. A partir do momento que o método fullOfPeople é executado, o objeto da classe Director é responsável em realizar a criação dos objetos de acordo com o tipo de registro que encontra no arquivo “registers.txt”.
Caso o exemplo acima seja demasiado simples, aqui e aqui você poderá obter outros cenários de uso do padrão de projeto Builder.
Até o próximo Desing Pattern! 
Últimos Comentários