Padroes_Atribuicoes_Responsabilidade

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Padrões para 
Atribuição de
Responsabilidades
INF0396 - Análise e Projeto Orientados a Objetos
APOO
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Introdução
Um sistema OO é composto de objetos que enviam mensagens a outros objetos para completar operações.
 Escolher como distribuir as responsabilidades entre objetos é crucial para um bom projeto 
Uma má distribuição leva a sistemas e componentes frágeis e difíceis de entender, manter, reutilizar e estender.
Os Padrões GRASP (General Responsibility Assignment Software Patterns) são aplicados durante a criação dos diagramas de interação para atribuição de responsabilidades a objetos.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Responsabilidade e Métodos
Segundo Booch e Rumbaugh responsabilidade é “um contrato ou obrigação de um tipo ou classe.”
As responsabilidades de um objeto pode ser de dois tipos:
conhecer
fazer
As responsabilidades de fazer de um objeto incluem:
fazer algo a ele próprio.
iniciar ações em outros objetos.
controlar e coordenar atividades em outros objetos.
As responsabilidades de conhecer de um objeto incluem:
conhecer dados privados encapsulados.
conhecer objetos relacionados.
conhecer coisas que ele pode derivar ou calcular.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplos
“uma Venda é responsável por imprimir a si própria”. (fazer) 
“uma Venda normal é responsável por saber conhecer sua data”. (conhecer).
As responsabilidades relacionadas a conhecer são freqüêntemente dedutíveis do modelo conceitual, por causa dos atributos e associações
Responsabilidade  Método
Métodos são implementados para satisfazer responsabilidades.
A implementação de uma responsabilidade pode envolver 1 ou mais classes e 1 ou mais métodos.
Exemplo: A classe Venda pode definir um ou mais métodos para impressão de uma instância de Venda e além disso colaborar com outros objetos para sua execução, por exemplo, enviar mensagens para LinhadeItemdeVenda para que eles imprimam suas informações.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Responsabilidade e Diagramas de Interação
A atribuição de responsabilidades a objetos é aplicada durante a criação de diagramas de interação.
No exemplo abaixo foi atribuída ao objeto Venda a responsabilidade de imprimir a si próprio, que é iniciada com uma mensagem de imprimir. Podemos ver também que para sua execução o objeto Venda deve coloborar com LinhadeItemdeVenda, solicitando que eles imprimam suas informações.
As escolhas realizadas para atribuição de responsabilidade são refletidas no diagrama de interação.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Padrões
Uma descrição informal:
“Cada padrão descreve um problema que ocorre frequentemente e então descreve o cerne da solução ao problema de forma a poder reusar a solução milhões de vezes em situações diferentes”.
Uma descrição formal:
“é uma descrição nomeada de um problema e sua solução, que pode ser utilizadoem novos contextos; em termos ideais, ele fornece aconselhamento sobre como utilizá-lo em circunstâncias variáveis. Dada uma categoria específica de problema, muitos padrões fornecem orientações sobre como as responsabilidades deveriam ser atribuídas a objetos.
Padrões não tem como objetivo descobrir novos princípios da engenharia de software, trata-se do oposto, eles tentam codificar o conhecimento, o idioma e os princípios existentes.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Elementos Essenciais
Nome
Descreve o problema de projeto, suas soluções e consequências em poucas palavras, é simples e sugestivo..
Permite falar com outros sobre soluções e documentar código, já que os nomes de padrões estão ficando padronizados .
Permite projetar num nível mais alto de abstração.
O Problema
Descreve quando aplicar o padrão 
Descreve o problema e o contexto 
Pode descrever problemas específicos de projeto 
Às vezes, o padrão lista condições que devem se aplicar para usar o padrão 
A Solução
Descreve os elementos constituintes do projeto, seus relacionamentos, responsabilidades e colaborações 
A solução não descreve um projeto ou implementação concretos porque um padrão é um gabarito de solução para várias situações 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Padrões GRASP
Os padrões abordados neste material são os seguintes:
Expert (Especialista).
Creator (Criador).
High Cohesion (Coesão Alta).
Low Coupling (Acoplamento Fraco).
Controller (Controlador).
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Expert - Especialista
Problema
Qual é o princípio mais fundamental para atribuir responsabilidades? 
Solução
Atribuir uma responsabilidade ao expert (especialista) de informação - a classe que possui a informação necessária para preencher a responsabilidade.
Exemplo
No estudo de caso, alguma classe precisa saber o total de uma venda 
Podemos dizer isso sobre a forma de uma responsabilidade: 
Quem deveria ser reponsável pelo conhecimento do total de uma venda? 
Pelo padrão Expert, escolhemos a classe que possui a informação necessária para determinar o total 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Considere uma parte do modelo conceitual: 
Qual é a informação necessária? 
 Precisamos conhecer (ter acesso a) todos os LinhaDetalheVenda 
 Qual é information expert? 
É a classe Venda 
 Podemos agora fazer parte do diagrama de colaboração e do diagrama de classes
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Ainda não terminamos. Qual informação é necessária para determinar o subtotal para um item (uma linha de detalhe)? 
Precisamos de LinhaDeVenda.quantidade e de EspecificaçãoDeProduto.preço 
Quem é o information expert? 
É a classe LinhaDeVenda 
Chegamos aos seguintes diagramas:
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Qual é o information expert para saber o preço de um produto? 
É EspecificaçãoDeProduto 
Chegamos aos seguintes diagramas: 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Discussão
É o padrão mais usado de todos para atribuir responsabilidades.
A informação necessária frequentemente está espalhada em vários objetos. 
Portanto, tem muitos experts parciais. 
Exemplo: determinar o total de uma venda requer a colaboração de 3 objetos, em 3 classes diferentes.
Mensagens são usadas para estabelecer as colaborações. 
O resultado final é diferente do mundo real, no mundo real, uma venda não calcula seu próprio total. 
Isso seria feito por uma pessoa (se não houvesse software) 
Mas no mundo de software, não queremos atribuir essa responsabilidade ao Caixa ou ao TPDV! 
No mundo de software, coisas inertas (ou até conceitos como uma venda) podem ter responsabilidades: Tudo está vivo! 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Consequências
A encapsulação é mantida, já que objetos usam sua própria informação para cumprir suas responsabilidades.
Leva a fraco acoplamento entre objetos e sistemas mais robustos e fáceis de manter .
Leva a alta coesão, já que os objetos fazem tudo que é relacionado à sua própria informação.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Creator - Criador
Problema
Quem deve criar novas instâncias de uma classe? 
Solução
Atribuir à classe B a responsabilidade de criar instância da classe A se uma das seguintes condições se aplicar: 
B agrega objetos
da classe A 
B contém objetos da classe A 
B registra instâncias da classe A 
B usa muito objetos da classe A 
B possui os dados usados para inicializar A 
B é um criador (creator) de objetos da classe A 
Se mais de uma opção se aplica, escolha o B que agregue ou contenha objetos da classe A 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
No estudo de caso, quem deveria criar uma instância de LinhaDetalheVenda? 
Pelo padrão Creator, precisamos achar alguém que agrega, contém, ... instâncias de LinhaDetalheVenda 
Considere o modelo conceitual parcial abaixo: 
 Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Chegamos aos seguintes diagramas: 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Análise do Padrão
Discussão
Escolhemos um criador que deve estar conectado ao objeto criado.
Isso leva a fraco acoplamento.
Exemplo de criador que possui os valores de inicialização. 
Uma instância de Pagamento deve ser criada 
A instância deve receber o total da venda 
Quem tem essa informação? Venda 
Venda é um bom candidato para criar objetos da classe Pagamento 
Consequências
Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Low Coupling – Acoplamento Fraco
Problema
Como minimizar dependências e maximizar o reuso? 
O acoplamento é uma medida de quão fortemente uma classe está conectada, possui conhecimento ou depende de outra classe. 
Com fraco acoplamento, uma classe não é dependente de muitas outras classes. 
Com uma classe possuindo forte acoplamento, temos os seguintes problemas: 
Mudanças a uma classe relacionada força mudanças locais à classe. 
A classe é mais difícil de entender isoladamente 
A classe é mais difícil de ser reusada, já que depende da presença de outras classes 
Solução
Atribuir responsabilidades de forma a minimizar o acoplamento
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Considere o seguinte diagrama parcial de classes no estudo de caso:
Suponha que temos que criar um Pagamento e associá-lo a uma Venda.
Que classe deveria ter essa responsabilidade? 
Alternativa 1: No mundo real, um TPDV "registra" um pagamento e o padrão Creator sugere que TPDV poderia criar Pagamento.
TPDV deve então passar o pagamento para a Venda 
Veja o resultado abaixo:
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Alternativa 2: Criar o Pagamento com Venda e associá-lo à Venda. Veja o resultado abaixo:
Supondo que a Venda deva ter conhecimento do pagamento (depois da criação) de qualquer jeito, a alternativa 2 tem menos acoplamento (TPDV não está acoplado a Pagamento).
Dois padrões (Creator e Low Coupling) sugeriram diferentes soluções.
Minimizar acoplamento ganha.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Análise do Padrão
Discussão
Minimizar acoplamento é um dos princípios de ouro do projeto OO 
Acoplamento de manifesta de várias formas: 
X tem um atributo que referencia uma instância de Y 
X tem um método que referencia uma instância de Y 
Pode ser parâmetro, variável local, objeto retornado pelo método 
X é uma subclasse direta ou indireta de Y 
X implementa a interface Y 
A herança é um tipo de acoplamento particularmente forte 
Não se deve minimizar acoplamento criando alguns poucos objetos monstruosos (God classes)
Consequências
Uma classefracamente acoplada não é afetada (ou pouco afetada) por mudanças em outras classes 
Simples de entender isoladamente 
Reuso mais fácil 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
High Cohesion (Coesão Alta)
Problema
Como gerenciar a complexidade? 
A coesão mede quão relacionados ou focados estão as responsabilidades da classe 
Também chamado coesão funcional (ver à frente) 
Uma classe com baixa coesão faz muitas coisas não relacionadas e leva aos seguintes problemas: 
Difícil de entender 
Difícil de reusar 
Difícil de manter 
"Delicada": constantemente sendo afetada por outras mudanças 
Uma classe com baixa coesão assumiu responsabilidades que pertencem a outras classes e deveriam ser delagadas 
Solução
Atribuir responsabilidades que mantenham alta coesão 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Mesmo exemplo usado para Low Coupling 
Na primeira alternativa, TPDV assumiu uma responsabilidade de efetuar um pagamento (método façaPagamento()) 
Até agora, não há problema 
Mas suponha que o mesmo ocorra com várias outras operações de sistema 
TPDV vai acumular um monte de métodos não muito focados 
Resultado: baixa coesão 
A segunda alternativa delega façaPagamento() para a classe Venda 
Mantém maior coesão em TPDV
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Análise do Padrão
Melhor claridade e facilidade de compreensão do projeto 
Simplificação da manutenção 
Frequentemente vai mão na mão com acoplamento fraco 
Com granularidade baixa e funcionalidade bem focada, aumenta o reuso 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Controller - Controlador
Problema
Quem deveria receber a responsabilidade de tratar eventos do sistema? 
Um evento do sistema é um evento de alto nível gerado por um ator externo 
Estão associados a operações do sistema que já vimos nos Diagramas de Sequência do Sistema 
Um controller (controlador) é um objeto de interface, não-de-usuário responsável por tratar um evento de sistema.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Controller - Controlador
Solução
Use um controlador 
Um controlador é um objeto que não é de interface GUI responsável pelo tratamento de eventos do sistema 
Um controlador define métodos para as operações do sistema 
Atribuir a responsabilidade pelo tratamento de eventos do sistema a uma classe de acordo com uma das alternativas abaixo: 
Representa o "sistema" como um todo (facade controller) 
Representa o negócio ou organização como um todo (facade controller) 
Representa algo no mundo real que é ativo (por exemplo, o papel de uma pessoa) que poderia estar envolvido na tarefa (role controller) 
Representa um handler artificial de todos os eventos do sistema para um Use Case particular, normalmente chamado "<NomeDoUseCase>Handler" (use case controller) 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Na aplicação do ponto de vendas há várias operações de sistema:
Quem deveria ser o controlador para os eventos do sistema? 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Exemplo
Pelo padrão Controller, temos as seguintes alternativas: 
Representa o "sistema": TPDV .
Representa o negócio ou organização: Loja .
Representa algo no mundo real ...: Caixa .
Representa um handler artificial ...: CompraItemHandler (controlador de Comprar Itens).
Por exemplo, se fosse TPDV, teríamos: 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Análise do Padrão
De forma geral, o mesmo controlador deve ser usado para todas as operações de um mesmo Use Case de forma a manter a informação de estado do Use Case. 
A informação de estado pode ser útil para detectar sequências erradas de eventos de sistema. 
Exemplo: façaPagamento() antes de fimDeVenda() 
Não coloque toda a inteligência no controlador. 
Delegue para outros objetos,para manter coesão.
Use um Handler artificial quando as outras alternativas exibem acoplamento
alto ou coesão baixa.
Quando está surgindo um "God class" 
Usado em sistemas mais complexos 
Observe que classes "Window", "Applet", "Application", "View", "Document" não devem ser controladores.
Tais classes podem receber o evento e delegá-lo ao controlado.
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Não se deve colocar business logic num objeto de interface com o usuário. 
 Design Correto 
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
 Design Incorreto
*
Inf0396 – Análise e Projeto Orientado a Objetos
Padrões para Atribuição de Responsabilidades
Controler - Controlador
Consequências
Maior possibilidade de reuso, já que o business logic não está nos objetos de interface 
Ajuda a verificar o sequenciamento das operações do sistema, através do estado do controlador