sexta-feira, 6 de junho de 2008

Padrão Pura Invensão e Indireção - Aula 31

O post passado a respeito de polimorfismo, que tem como problema tratar alternativas baseadas no tipo, criar componente de software “plugáveis”. E foi resolvido atribuindo responsabilidades aos tipos usando operações polimóficas.
Agora vamos dar continuidade aos Padrões Grasp Pura Invenção e Indireção.



Pura Invenção

Problema:

Que objeto deve ter a responsabilidade quando você não quer violar “ Alta Coesão” e “ Baixo Acoplamento”, mas as soluções oferecidas pelo “Especialista” não são apropriadas?

Solução:

Atribua um conjunto coeso de responsabilidade a uma classe artificial que não representa um conceito no domínio da aplicação, uma classe fictícia que possibilite alta coesão, baixo acoplamento e o reuso.





O especialista nos diz para atribuir a responsabilidade à classe Venda, uma vez que ela conhece os dados de venda. Considere no entanto as seguintes implicações:
Salvar um objeto no Banco de Dados implica em uma série de operações não relacionadas ao conceito de venda.
A classe venda tem de ser associada à interface do banco de dados relacional (JDBC, por exemplo)
Várias outras classes no projeto terão de fazer a mesma coisa.



Beneficios:
-É considerada como parte da camada de serviços de alto nível OO em uma arquitetura.-Invenção pura são objetos tipicamente centrados na funcionalidade (cuidado com abusos para não perder o espírito de bons projetos OO!).
-Cria-se objetos mais genéricos e reutilizáveis: a própria classe inventada. É importante ter isso em mente
-Melhora acoplamento e coesão: a classe venda permanece bem projetada.


Indireção

Problema:

Onde colocar uma responsabilidade de modo a evitar o acoplamento direto entre duas ou mais classes? Como desacoplar objetos de modo a possibilitar o baixo acoplamento e manter alta a possibilidade de reuso?

Solução:

Atribua a responsabilidade a um objeto intermediário que faça a mediação entre componentes ou serviços de modo que ele não sejam diretamente acoplados.


A fundamental finalidade de se usar O Padrão Indireção, é que pode-se atribuir a encargo a um objeto intermediário que faz mediação entre os outros componentes ou serviços de modo que eles não estejam diretamente acoplados. O objeto intermediário cria uma camada de indireção entre os dois componentes que não dependem um do outro: agora ambos dependem da indireção.


Benefício: Acoplamento fraco – com o objetivo de desacoplar outros componentes ou serviços, introduz-se uma indireção.
Muitas invenções puras são conseqüências da indireção.

“A maior parte dos problemas em Ciência da Computação pode ser resolvida por um nível adicional de indireção” .


Velho provérbio com especial relevância para sistemas orientados a objeto.

http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt#815,62,Indireção Acessado em 08 Junho 2008, 22:23

Wikimedia Foundation, Inc, Spring Framework, Disponível em: <http://en.wikipedia.org/wiki/Spring_framework> Acessado em 08 Junho 2008, 22:16;GRASP Patterns, Disponível em:<http://equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt> Acessado em 08 Junho 2008, 22:59;ROCHA, Helder, Padrões de Design com aplicações em JAVA, Disponível em:<http://www.argonavis.com.br/cursos/java/j930/tutorial/Design_Patterns.pdf> Acessado em 08 Junho 2008, 22:33;

Nenhum comentário: