Projetando Objetos com Responsabilidades

Apresentação em tema: "Projetando Objetos com Responsabilidades"— Transcrição da apresentação:

1 Projetando Objetos com Responsabilidades
GRASP Patterns Projetando Objetos com Responsabilidades

2 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

3 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

4 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'

5 Os padrões GRASP Controller Creator Information Expert Indirection
Low Coupling High Cohesion Polymorphism Pure Fabrication Protected Variations

6 O Criador

7 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

8 Exemplo: Jogo de Banco Imobiliário
Quem deve criar os objetos correspondentes às peças do tabuleiro?

9 Exemplo: Jogo de Banco Imobiliário
visão estática visão dinâmica

10 Outro exemplo: um ponto de venda
Vantagens: LRG Contraindicações : Criação de Objetos Complexos

11 O Especialista

12 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

13 Exemplo: O Banco Imobiliário
Quem deve localizar uma posição do tabuleiro dada a sua identidade?

14 Exemplo: O ponto de venda
Quem deve ser responsável por conhecer o total da venda?

15 Exemplo: O ponto de venda
Quem deve ser responsável por conhecer o total da venda?

16 Exemplo: O ponto de venda
Quem deve ser responsável por conhecer os subtotais?

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

18 Exemplo: O ponto de venda

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

20 Baixo Acoplamento

21 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.

22 Exemplo: O Banco Imobiliário
Pergunta: Por que o Tabuleiro e não um cachorro?

23 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.

24 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

25 Acoplamento entre classes
a) A ClasseA tem um atributo do tipo ClasseB

26 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

27 Acoplamento entre classes
c) A ClasseA é uma subclasse de ClasseB

28 Acoplamento entre classes
d) A ClasseB é uma interface e a ClasseA implementa esta interface

29 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.

30 O Controlador

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

32 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

33 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.

34 O princípio da separação Modelo-Vista
A motivação para a separação Modelo-Vista inclui: 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)

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

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

37 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

38 Exemplo: Ponto de Venda

39 Coesão Alta

40 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

41 Coesão Alta

42 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

43 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.

44 Polimorfismo

45 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.

46 Exemplo

47 O Banco Imobiliário Como projetar para acomodar as diferentes ações baseadas no tipo da posição do tabuleiro? Um mau projeto:

48 O Banco Imobiliário O comportamento estático:

49 O Banco Imobiliário O comportamento dinâmico:

50 O Banco Imobiliário O comportamento dinâmico:

51 O Banco Imobiliário O comportamento dinâmico:

52 O Banco Imobiliário O comportamento dinâmico:

53 O Banco Imobiliário O comportamento dinâmico:

54 Pure Fabrication (Pura Invenção)

55 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.

56 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.

57 Pure Fabrication

58 O Banco de Dados

59 Indireção

60 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.

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

62 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"