Engenharia de Software: maio 2010

19 de mai. de 2010

Design Patterns na Prática - Parte II: Abstract Factory

Continuando a nossa série, apresento-lhes mais um padrão de projeto criacional: Abstract Factory.

Temos a seguinte situação:

Um banco possui dois tipos de contas:

Corrente
Poupança

Cada uma delas pode ser categorizada como:

Simples
Normal
Plus

Cada uma dessas características possuem as suas vantagens particulares. Como aplicar um padrão de projeto criacional nesses objetos de maneira a ter-se menos impacto ao inserir-se um tipo de conta nova ou mais características das contas?

Resposta: Abstract Factory!

Temos então 3 tipos de fábrica de contas poupança ou corrente de acordo com o tipo necessário, são elas: TipoSimples, TipoNormal e TipoPlus. Todas essas fábricas concretas são representadas pela Fábrica Abstrata TipoConta, que é quem define os métodos de criação, ou seja, qualquer que seja a nova fábrica a ser criada para contas, ela deve ser capaz de criar os novos tipos de conta de acordo com o proposto por essa abstração. Assim definimos o processo de criaçõ totalmente flexível: não precisamos mudar nenhum código existente para criarmos mais um tipo de conta!

Concluindo, apresento-lhes a ficha resumida deste padrão:

Objetivo:

Fornecer uma interface a ser utilizada para criar famílias de objetos relacionados ou dependentes sem realmente especificar suas classes concretas.

Benefícios:

Isola o cliente das classes concretas(da implementação). Facilita a troca de famílias de objetos;
Promove a consistência entre objetos.

Aplicabilidade:

O sistema precisa ser independente da maneira como seus objetos são criados, compostos e representados;
O sistema precisa ser configurado com um objeto de uma família de vários objetos;
A família de objetos relacionados é concebida para ser utilizada em conjunto e essa restrição precisa ser imposta;
Deseja-se fornecer uma biblioteca de objetos que não mostre as implementações e somente revele as interfaces.

Então é isto galera! Qualquer dúvida, é só deixar o seu comentário que tentarei ajudar o mais rápido possível! ;)

Um abraço a todos e até o próximo post!

12 de mai. de 2010

Design Patterns na Prática - Parte I: Builder

Olá pessoal! Hoje darei início a uma série de "rapidinhas" sobre a aplicação de design patterns em exemplos práticos. Darei um problema e, em seguida, a modelagem de uma solução adequada. Espero que aproveitem!

O primeiro padrão a ser tratado trata-se de um comumente utilizado em projetos de software quando se tem a intenção de criar objetos complexos dinâmicamente e de maneira flexível sem precisarmos fazer isto de explícitamente.

Basicamente, o objetivo deste padrão é separar a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes objetos. Estou falando nada mais, nada menos, do incrível padrão Builder!

Vamos então ao que interessa:

Uma aplicação envia um XML a outra contendo os seguintes campos abaixo:

<header>...</header>

<campo1>...</campo1>...<campo2>...</campon>….

</struct1>
<struct2>

<campo1>...</campo1>...<campo2>...</campon>….

            </struct2>
            ….
            <structn>

<campo1>...</campo1>...<campo2>...</campon>….

</structn>

</body>
<trailer>...</trailer>

O problema é criar uma interface para enviar alguns parâmetros e buscá-los de um banco de dados (ex: um registro de uma pessoa como nome, endereço, etc...) e a mesma traga o XML apropriado montado. Utilizamos então para isto um design pattern do tipo criacional para se construir as classes necessárias para gerar esse XML: o Builder!

Nossa classe com o papel de diretor (ManageXMLConstruct) coordenará a delegação da construção às fábricas específicas de cada classe que representa uma tag do XML de acordo com a necessidade da construção. É o Builder entrando em ação!

É isso pessoal, fico por aqui.

Para qualquer dúvida, por favor, não deixe de postar o seu comentário.

Um abraço e até o próximo post da série! ;)