Invenção Pura
- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.
- Característica principal de projetos OO: utilizam os conceitos do domínio do problema para compor a implementação em software.
- Em algumas situações, a atribuição de responsabilidades somente às classes do domínio leva a problemas em termos de coesão e acoplamento.
- Problema: A quem atribuir responsabilidades quando 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 a reutilização (uma invenção da imaginação)
Exemplo:
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 IntermediárioArmazenamentoPersistente.
Esta classe é uma Invenção Pura.
Beneficios:
-Melhora acoplamento e coesão: a classe venda permanece bem projetada.
-Cria-se objetos mais genéricos e reutilizáveis: a própria classe inventada. É importante ter isso em mente
-Invenção pura são objetos tipicamente centrados na funcionalidade (cuidado com abusos para não perder o espírito de bons projetos OO!).
-É considerada como parte da camada de serviços de alto nível OO em uma arquitetura.
Indireção
-Suponha que:
-A aplicação TPV precisa manipular um modem, para transmitir solicitações de autorização de crédito.
-O SO oferece uma API para fazer isso
-A classe ServiçoAutorizaçãodeCrédito é responsável por falar com o modem .Tal classe fica altamente acoplada com a API e o SO.
-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a 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ção entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados
-Problema: Como evitar o acoplamento direto? Como desacoplar objetos de maneira a 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ção entre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados
-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.
Não fale com estranhos
-Motivação: O objetivo é evitar o acoplamento indireto, ou seja, que um cliente precise ter conhecimento de objetos indiretos, ou das representações internas de objetos diretamente referenciados.
-Objetos referenciados diretamente – “familiares”
-Objetos referenciados indiretamente – “estranhos”
-Novas operações serão necessárias nos objetos diretamente referenciados para funcionarem como operações intermediárias.
-Problema: Como evitar o conhecimento da estrutura de objetos indiretamente referenciados?
-Solução: Atribuir responsabilidade a um objeto diretamente referenciado por um cliente, de forma que este colabore mantendo contato com o objeto “estranho” (indiretamente referenciado)
-Lei de Demétrio
-Dentro de um método, as mensagens devem ser enviadas somente para os seguintes objetos:
-O objeto this (ou self)
-Um parâmetro do método
-Um atributo de self
-Um elemento de uma coleção que é um atributo de self
-Um objeto criado dentro do método
Nenhum comentário:
Postar um comentário