Padrões Grasp - slides

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

GRASP Patterns
Projetando Objetos com Responsabilidades
GRASP
General Responsibility Assignment Software Patterns
Os padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto
GRASP
Qual é a conexão entre Responsabilidades, GRASP e diagramas UML?
A ocasião para considerar a atribuição de responsabilidades às classes é durante a elaboração dos diagramas de seqüência 
O que são padrões?
Importante: Padrões têm nomes
A expressão 'um novo padrão' é um paradoxo
O livro da 'Gang of Four'
Os padrões GRASP
Controller
Creator 
Information Expert 
Indirection 
Low Coupling
High Cohesion 
Polymorphism 
Pure Fabrication
Protected Variations 
O Criador
O Criador (Creator)
Problema: Quem deve ser responsável por criar uma nova instância de uma classe?
Solução: Atribua à classe B a responsabilidade de criar uma instância de A se pelo menos um desses for verdadeiro (quanto mais melhor):
B contém ou agrega A
B registra a existência de A
B usa A
B tem os dados necessários para a inicialização de A que serão passados ao construtor de A
Exemplo: Jogo de Banco Imobiliário
Quem deve criar os objetos correspondentes às peças do tabuleiro?
Exemplo: Jogo de Banco Imobiliário
visão estática
visão dinâmica
Outro exemplo: um ponto de venda
Vantagens: LRG
Contraindicações : Criação de Objetos Complexos 
O Especialista
O padrão Especialista (Information Expert)
Problema: Qual é o princípio geral para a atribuição de responsabilidades aos objetos?
Solução: Atribua a responsabilidade ao especialista: a classe que tem as informações necessárias para assumir a responsabilidade
Exemplo: O Banco Imobiliário
Quem deve localizar uma posição do tabuleiro dada a sua identidade?
Exemplo: O ponto de venda
Quem deve ser responsável por conhecer o total da venda?
Exemplo: O ponto de venda
Quem deve ser responsável por conhecer o total da venda?
Exemplo: O ponto de venda
Quem deve ser responsável por conhecer os subtotais?
Exemplo: O ponto de venda
Quem deve ser responsável por conhecer o preço de cada item de venda?
Exemplo: O ponto de venda
O padrão Especialista (Information Expert)
Benefícios: 
O encapsulamento da informação é mantido uma vez que os objetos usam seus próprios dados para realizar as tarefas.
Isto normalmente leva a um baixo acoplamento entre as classes.
O comportamento do sistema é distribuído entre as classes que têm as informações, encorajando a definição de classes mais "leves", mais fáceis de entender e de manter.
Contraindicações : 
Em algumas situações, a solução sugerida pelo especialista pode ser indesejada. (Quem deve persistir uma venda no banco?)
Baixo Acoplamento
Baixo Acoplamento
Problema: Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização?
Solução: Atribua as responsabilidades de modo que o acoplamento entre classes permaneça baixo. Use este princípio para avaliar alternativas.
Exemplo: O Banco Imobiliário
Pergunta: Por que o Tabuleiro e não um cachorro?
Baixo Acoplamento
Ponto Chave: O Especialista favorece o Baixo Acoplamento
Retornando à motivação do especialista: ele nos conduz a soluções que favorecem o baixo acoplamento. O especialista nos pede que encontremos o objeto que tem a maior parte da informação necessária para assumir a responsabilidade (por exemplo, o tabuleiro)
Se pusermos a responsabilidade em algum outro lugar qualquer (por exemplo, o cachorro) o acoplamento global será maior porque mais informações terão de ser compartilhadas entre os objetos.
Outro Exemplo: O ponto de venda
Suponha que temos de criar um objeto pagamento e associá-lo à venda. Que classe deve ser responsável por isso?
1ª alternativa
2ª alternativa
Acoplamento entre classes
a) A ClasseA tem um atributo do tipo ClasseB
Acoplamento entre classes
b) A ClasseA tem um método que, de alguma forma, referencia uma instância de ClasseB. Tipicamente, esta referência se dá através de um parâmetro ou variável local do tipo ClasseB ou por um objeto do tipo ClasseB retornado pela chamada de algum método 
Acoplamento entre classes
c) A ClasseA é uma subclasse de ClasseB 
Acoplamento entre classes
d) A ClasseB é uma interface e a ClasseA implementa esta interface 
Acoplamento entre classes
Discussão:
Classes que, por natureza, são genéricas e que têm alta probabilidade de reutilização deveriam ter acoplamento baixo
O caso extremo do baixo acoplamento é o não acoplamento: contraria o princípio da orientação a objetos: objetos conectados, trocando mensagens entre si.
O acoplamento alto não é o problema em si. O problema é o acoplamento a classes que, de alguma forma são instáveis: sua interface, sua implementação ou sua mera presença.
O Controlador
O Controlador
Problema: Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?
O princípio da separação Modelo-Vista
O princípio da separação Modelo-Vista pode ser enunciado em duas partes:
Não conecte diretamente objetos pertencentes à interface com o usuário (a vista) com objetos não pertencentes à interface com o usuário (IU). 
Não coloque lógica da aplicação (tal como o cálculo de impostos) nos métodos dos objetos da IU 
O princípio da separação Modelo-Vista
A motivação para a separação Modelo-Vista inclui:
Suportar a criação de classes de negócio coesas, com foco nos processos do domínio ao invés de na interface com o usuário.
Permitir o desenvolvimento separado das camadas de apresentação e negócio.
Minimizar o impacto na camada de negócio das alterações nos requisitos da interface com o usuário.
O princípio da separação Modelo-Vista
Permitir que novas vistas sejam facilmente conectadas aos objetos de negócio existentes, sem afetar a camada de negócios.
Permitir a existência de múltiplas vistas simultâneas para uma mesma camada de negócios (por exemplo, a visualização de dados de vendas na forma tabular ou através de um gráfico de pizzas)
A motivação para a separação Modelo-Vista inclui:
O objeto Controlador
O objeto Controlador responde a uma questão básica no projeto de sistemas OO: Como conectar a camada de apresentação à camada da lógica do negócio?
O objeto Controlador
O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.
Existem duas alternativas possíveis para o objeto controlador:
Um objeto Controlador para todo o sistema
Um objeto Controlador por Caso de Uso (ou por cenário de Caso de Uso)
O objeto Controlador
Os benefícios do padrão controlador são:
Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio
Oportunidade para controlar o estado do caso de uso
Exemplo: Ponto de Venda
Coesão Alta
Coesão Alta 
Problema: Como manter os objetos focados, compreensíveis, gerenciáveis e, em conseqüência, com Baixo Acoplamento?
Solução: Atribua responsabilidades de modo que a coesão da classe permaneça alta. Use esse critério para avaliar alternativas
Coesão Alta
Coesão
Uma classe com baixa coesão sofre dos seguintes problemas:
difícil de compreender
difícil de reutilizar
difícil de manter
frágil; freqüentemente tem de ser alterada
Coesão
Como um princípio básico, uma classe com alta coesão:
tem um número relativamente pequeno de métodos, 
a funcionalidade desses métodos é altamente relacionada, e 
não faz trabalho de mais.
Polimorfismo
Polimorfismo
Problema: Como tratar alternativas baseadas no tipo? Como criar componentes de software "plugáveis"?
Solução: Quando alternativas ou comportamentos relacionados variam com o tipo (classe), atribua as responsabilidades aos tipos usando operações polimórficas.
Exemplo
O Banco Imobiliário
Como projetar para acomodar as diferentes ações baseadas no tipo da posição do tabuleiro?
Um mau projeto:
O Banco Imobiliário
O comportamento estático:
O Banco Imobiliário
O comportamento dinâmico:
O Banco Imobiliário
O comportamento dinâmico:
O Banco Imobiliário
O comportamento dinâmico:
O Banco Imobiliário
O comportamento dinâmico:
O Banco Imobiliário
O comportamento
dinâmico:
Pure Fabrication (Pura Invenção)
Pure Fabrication
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 conjuto coeso de responsabilidades 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.
Ponto de Venda: Salvar uma Venda no Banco de Dados
O especialista nos diz para atribuir a responsabilidade à classe Venda, uma vez que ela conhece os dados da 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.
Pure Fabrication
O Banco de Dados
Indireção
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 eles não sejam diretamente acoplados.
Indireção
Exemplo: Indireção através de um adaptador
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 objetos
"A maior parte dos problemas de desempenho pode ser resolvida removendo-se algumas camadas de indireção"