GRASP Patterns Projetando Objetos com Responsabilidades

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

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