GRASP Patterns Projetando Objetos com Responsabilidades.

62
GRASP Patterns Projetando Objetos com Responsabilidades

Transcript of GRASP Patterns Projetando Objetos com Responsabilidades.

Page 1: GRASP Patterns Projetando Objetos com Responsabilidades.

GRASP Patterns

Projetando Objetos com Responsabilidades

Page 2: 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

Page 3: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 4: GRASP Patterns Projetando Objetos com Responsabilidades.

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'

Page 5: GRASP Patterns Projetando Objetos com Responsabilidades.

Os padrões GRASP

• Controller

• Creator

• Information Expert

• Indirection

• Low Coupling

• High Cohesion

• Polymorphism

• Pure Fabrication

• Protected Variations

Page 6: GRASP Patterns Projetando Objetos com Responsabilidades.

O Criador

Page 7: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 8: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: Jogo de Banco Imobiliário

Quem deve criar os objetos correspondentes às peças do tabuleiro?

Page 9: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: Jogo de Banco Imobiliário

visão estática

visão dinâmica

Page 10: GRASP Patterns Projetando Objetos com Responsabilidades.

Outro exemplo: um ponto de venda

Vantagens: LRG

Contraindicações : Criação de Objetos Complexos

Page 11: GRASP Patterns Projetando Objetos com Responsabilidades.

O Especialista

Page 12: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 13: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O Banco Imobiliário

Quem deve localizar uma posição do tabuleiro dada a sua identidade?

Page 14: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O ponto de venda

Quem deve ser responsável por conhecer o total da venda?

Page 15: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O ponto de venda

Quem deve ser responsável por conhecer o total da venda?

Page 16: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O ponto de venda

Quem deve ser responsável por conhecer os subtotais?

Page 17: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O ponto de vendaQuem deve ser responsável por conhecer o preço de cada item de venda?

Page 18: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O ponto de venda

Page 19: GRASP Patterns Projetando Objetos com Responsabilidades.

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?)

Page 20: GRASP Patterns Projetando Objetos com Responsabilidades.

Baixo Acoplamento

Page 21: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 22: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: O Banco Imobiliário

Pergunta: Por que o Tabuleiro e não um cachorro?

Page 23: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 24: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 25: GRASP Patterns Projetando Objetos com Responsabilidades.

Acoplamento entre classes

a) A ClasseA tem um atributo do tipo ClasseB

Page 26: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 27: GRASP Patterns Projetando Objetos com Responsabilidades.

Acoplamento entre classes

c) A ClasseA é uma subclasse de ClasseB

Page 28: GRASP Patterns Projetando Objetos com Responsabilidades.

Acoplamento entre classes

d) A ClasseB é uma interface e a ClasseA implementa esta interface

Page 29: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 30: GRASP Patterns Projetando Objetos com Responsabilidades.

O Controlador

Page 31: GRASP Patterns Projetando Objetos com Responsabilidades.

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?

Page 32: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 33: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 34: GRASP Patterns Projetando Objetos com Responsabilidades.

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:

Page 35: GRASP Patterns Projetando Objetos com Responsabilidades.

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?

Page 36: GRASP Patterns Projetando Objetos com Responsabilidades.

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)

Page 37: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 38: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo: Ponto de Venda

Page 39: GRASP Patterns Projetando Objetos com Responsabilidades.

Coesão Alta

Page 40: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 41: GRASP Patterns Projetando Objetos com Responsabilidades.

Coesão Alta

Page 42: GRASP Patterns Projetando Objetos com Responsabilidades.

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

Page 43: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 44: GRASP Patterns Projetando Objetos com Responsabilidades.

Polimorfismo

Page 45: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 46: GRASP Patterns Projetando Objetos com Responsabilidades.

Exemplo

Page 47: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

Como projetar para acomodar as diferentes ações baseadas no tipo da posição do tabuleiro?

Um mau projeto:

Page 48: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

O comportamento estático:

Page 49: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

O comportamento dinâmico:

Page 50: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

O comportamento dinâmico:

Page 51: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

O comportamento dinâmico:

Page 52: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

O comportamento dinâmico:

Page 53: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco Imobiliário

O comportamento dinâmico:

Page 54: GRASP Patterns Projetando Objetos com Responsabilidades.

Pure Fabrication (Pura Invenção)

Page 55: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 56: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 57: GRASP Patterns Projetando Objetos com Responsabilidades.

Pure Fabrication

Page 58: GRASP Patterns Projetando Objetos com Responsabilidades.

O Banco de Dados

Page 59: GRASP Patterns Projetando Objetos com Responsabilidades.

Indireção

Page 60: GRASP Patterns Projetando Objetos com Responsabilidades.

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.

Page 61: GRASP Patterns Projetando Objetos com Responsabilidades.

Indireção

Exemplo: Indireção através de um adaptador

Page 62: GRASP Patterns Projetando Objetos com Responsabilidades.

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 parasistemas orientados a objetos

"A maior parte dos problemas de desempenho pode ser resolvida removendo-se algumas camadas de indireção"