sábado, 21 de junho de 2008

Padrões GRASP - parte II (Invenção Pura e Indireção)

Aulas 28 e 29


Sabemos que os princípios de ouro para um bom projeto OO é o baixo acoplamento e a alta coesão, mas e se em algum caso a aplicação de um padrão violar um desses princípios?

Utilizaremos um exemplo dado no livro Utilizando UML e padrões de Craig Larman. No exemplo ele diz “Às vezes, os projetos orientados a objetos são caracterizados por implementarem como classes de software as representações dos conceitos do domínio do problema no mundo real para diminuir o hiato de representação (aqui ele usa o termo “hiato” para se referir às lacunas, espaço, o vago deixado quando se quer representar algo do mundo real no mundo virtual), por exemplo, uma classe Venda e uma classe Cliente.

Entretanto, existem muitas situações em que atribuir responsabilidades apenas às classes de software da camada do domínio leva a problemas em termos de coesão ou acoplamento inadequados ou a um baixo potencial de reutilização.

Suponha, por exemplo, que seja necessário suporte para salvar as instâncias de Venda em um banco de dados relacional. Segundo o padrão Especialista, atribuir responsabilidade à própria classe Venda seria justificável, pois venda tem os dados que precisam ser salvos. Entretanto, considere as implicações a seguir:

A tarefa exige um número relativamente grande de operações de suporte relacionadas ao banco de dados, nenhuma delas voltada ao conceito de venda, de modo que a classe Venda se torna não-coesa.
A classe Venda precisa estar acoplada à interface do banco de dados relacional, de modo que seu acoplamento aumenta.

Salvar objetos em um banco de dados relacional é uma tarefa muito geral, para a qual muitas classes precisam de suporte. Colocar essas responsabilidades na classe Venda sugere que vai haver uma reutilização inadequada ou muita duplicação em outras classes que fazem a mesma coisa.
Entenderam agora como a aplicação do padrão especialista levou a um alto acoplamento e uma baixa coesão? Mas nesse caso, o que fazer se não podemos deixar de aplicar o padrão especialista?

A resposta é o título desta postagem, o padrão Invenção Pura. Uma solução razoável para o problema acima é criar uma classe que seja responsável unicamente por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional. Esta classe é uma Invenção Pura, uma criação da imaginação, e serve para tirar o acoplamento da classe Venda com o banco de dados.

Indireção

O objetivo deste padrão é muito parecido com o que estudamos acima, o padrão Invenção pura. Craig Larman cita em seu livro “Utilizando UML e padrões” que o objetivo do padrão indireção é “atribuir responsabilidade a um objeto intermediário para ser o mediador entre outros componentes ou serviços, para que eles não sejam diretamente acoplados. O intermediário cria uma indireção entre os outros componentes.

Geralmente, o padrão indireção e o Invenção Pura andam juntos, e o problema para o qual são a solução, geralmente é o mesmo, o alto acoplamento. Ao se aplicar um dos dois, não há a necessidade de aplicar o outro, a não ser que haja um certo choque de padrões, como foi explicado no exemplo anterior.

Nenhum comentário: