Aulas 31 e 32

Padrão Invenção Pura

Problema:

A quem atribuir responsabilidades quando qua do as classes do domínio não são adequadas e não se quer violar os princípios da Coesão Alta e do Acoplamento Fraco ? Como criar componentes de software conectáveis ?

Solução:
Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial – que não representa nada no domínio do problema. Tal classe é construída especialmente para melhorar a coesão e diminuir o acoplamento, facilitando reutilização (uma invenção da imaginação).

Exemplo: Se for necessário salvar instâncias de Venda em um banco de dados relacional, considerando o padrão Expert, esta responsabilidade pode ser atribuída à própria classe Venda.
Porém há as seguintes implicações:
-Grande número de operações voltadas ao banco de dados- diminuição da coesão-
A classe Venda tem que ser acoplada com a interface do banco de dados relacional aumento do acoplamento–
Salvar objetos é uma tarefa geral, necessária em muitas classes – duplicação de código, baixa reutilização.
-Nesse caso, a solução é criar uma nova classe que é unicamente responsável por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional.
-Chamamos esta solução de PersistentStorageBroker.
Esta classe é uma Invenção Pura.

Padrão Indireção
Problema: Quem irá evitar o acoplamento direto? Como desacoplar objetos de maneiraa apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?

Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediaçãoentre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados.

Exemplo:
O exemplo de uma Invenção Pura de desacoplar Venda dos serviços de banco de dados relacionais, também é um exemplo de Indireção. O PersistentStorageBroker atua como um intermediário entre Venda e o banco de dados.

Link: http://www.inf.ufg.br/~juliano/ensino/especializacao/ProjSw2007/ProjetoOO.pdf