General Responsibility Assignment Software Patterns

Transcrição

1

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 sequência

4 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 4

5

6 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

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

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

9 Outro exemplo: um ponto de venda Cuidado com a Criação de Objetos Complexos

10 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 10

11

12 O padrão Especialista (Information Expert) Problema: Precisa-se de um princípio geral para atribuir responsabilidades a objetos Durante o projeto, em que são definidas as interações entre objetos, é preciso fazer escolhas sobre a atribuição de responsabilidades a classes. Solução Atribuir uma responsabilidade ao especialista de informação: classe que possui a informação necessária para cumpri-la; Inicie declarando claramente 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. 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 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 20

21

22 Coesão Alta Problema: Como manter os objetos focados, compreensíveis, gerenciáveis e, em consequência, com Baixo Acoplamento? Classes que fazem muitas tarefas não relacionadas são mais difíceis de entender, de manter e de reusar, além de mais vulneráveis às mudanças. Solução: Atribua responsabilidades de modo que a coesão da classe permaneça alta. Use esse critério para avaliar alternativas

23 Coesão Medida de quão relacionadas ou focadas estão as responsabilidades de um elemento. Exemplo: Cao é coesa se tem apenas operações relacionadas ao Cão (morder, correr, latir, comer) a apenas ao Cão. ~ao terá que imprimir, listar cães, etc... Alta coesão promove design modular

24 Coesão Alta

25 Alta Coesão Que classe é responsável por criar um pagamento (Payment) e associá-lo a uma venda (Sale)? Register assumiu responsabilidade por uma coisa que é parte de Sale (fazer um pagamento não é responsabilidade de registrar)

26 Alta Coesão Register delega a responsabilidade a Sale, aumentando a coesão de Register

27 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; frequentemente tem de ser alterada

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

29 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 29

30

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

32 Acoplamento Medida de quanto um elemento está conectado a, ou depende de outros elementos. Uma classe com acoplamento forte depende de muitas outras classes: tais classes podem ser indesejáveis O acoplamento está associado à coesão: maior coesão, menor acoplamento e vice-versa.

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

34 Baixo Acoplamento Ponto Chave: O Especialista favorece o Baixo Acoplamento Retornando à motivação do especialista: 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.

35 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

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

37 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

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

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

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

41 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 41

42

43 O Controlador Problema: Quem deve ser o responsável por lidar com um evento de uma interface de entrada? Solução: Atribuir a responsabilidade de receber ou lidar com um evento do sistema para uma classe que representa todo o sistema (controlador de fachada front controller), um subsistema e um cenário de casos de uso (controlador de caso de uso ou sessão)

44 O Controlador Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?

45 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

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

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

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

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

50 Controlador Um sistema contendo operações de sistema associados com eventos do sistema

51 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

52 Exemplo: Ponto de Venda

53 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 53

54

55 Polimorfismo Problema: Como tratar alternativas baseadas no tipo? Como criar componentes de software "plugáveis"? Deseja-se evitar variação condicional (if-then-else): pouco extensível Deseja-se substituir um componente por outro sem afetar o cliente Solução: Quando alternativas ou comportamentos relacionados variam com o tipo (classe), atribua as responsabilidades aos tipos usando operações polimórficas.

56 Exemplo

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

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

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

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

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

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

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

64 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 64

65

66 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? Atribuir responsabilidade apenas para as classes do domínio conceitual pode levar a situações de maior acoplamento e menor coesão. Solução: Atribua um conjunto 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.

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

68 Pure Fabrication

69 O Banco de Dados

70 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 70

71

72 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 O objeto intermediário cria uma camada de indireção entre os dois componentes que não mais dependem um do outro: ambos dependem da indireção

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

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

75 INVERSÃO DE CONTROLE

76 Inversão de Controle IoC Princípio de Hollywood: Não nos ligue, nós ligaremos. Dependência de componentes. também conhecida como colaboradores de objetos. O objeto que exige dependência é conhecido como objeto dependente. Frameworks é responsável pela execução da operação. Ocorre em tempo de execução. 76

77 Inversão de Controle: Motivação Cenário 1 Classe A precisa de uma referência para a Classe B. Classe B é uma classe concreta que tem um construtor padrão. Classe A possui uma instância de B. Nenhuma outra classe pode acessar uma instância da Classe B [Mal06]. public class A{ private B b; public A(){ b=new B(); } } 77

78 Inversão de Controle: Motivação Cenário 2 Objeto a possui referência para os objetos c e b. public class A{ private B b; public A(){ C c = new C(); b = new B(c); } } 78

79 Inversão de Controle: Motivação Cenário 3 A precisa de uma referência para B, e não precisa saber como B é instanciado. B pode ser uma interface, uma classe abstrata ou concreta. Antes de instanciar a classe A, precisa de uma referência para a classe B. public class A{ private B b; public A(){ } public setb(b b){ this.b=b; } } 79

80 Tipos de Inversão de Controle Inversão de Controle (IoC) possui dois tipos [Har05]: Injeção de Dependência (Dependency Injection) Procura por Dependência (Dependency Lookup) Injeção de Dependência sempre diz respeito a IoC, mas IoC nem sempre referencia Injeção de Dependência 80

81 Tipos de Inversão de Controle Inversão de Controle Procura por Dependência Injeção de Dependência Contextualized Dependency Lookup Dependency Pull Interface Setter Construtor 81

82 Tipos de Inversão de Controle Procura por Dependência: um componente deve obter uma referência para uma dependência; dois subtipos: Dependency Pull Contextualized Dependency Lookup (CDL) Injeção de Dependência: as dependências são literalmente injetadas (incluídas) três subtipos: Interface Tipo 1 Setter Tipo 2 Constructor Tipo 3 82

83 Contêineres de Inversão de Controle Spring Avalon PicoContainer HiveMind Excalibur: Fortress Resin Copland (Ruby) Mentawai 83

84 Procura por Dependência Dependency Pull As dependências são obtidas através de um registro assim que necessário; Mecanismo para encontrar componentes que gerenciam o frameworks. Procura por Dependência com Spring public static void main(string[] args) throws Exception { // get the bean factory BeanFactory factory = getbeanfactory(); MessageRenderer mr = (MessageRenderer) factory.getbean("renderer"); mr.render(); } 84

85 Procura por Dependência Contextualized Dependency Lookup (CDL) Semelhante ao Dependency Pull; Procura é executada pelo contêiner que está gerenciando o recurso e não a partir de um registro central; CDL funciona através da implementação de uma interface. Interface do Componente para CDL com Spring public interface ManagedComponent { public void performlookup(container container); } 85

86 Procura por Dependência Contextualized Dependency Lookup (CDL) Executa o método performlookup() implementado pelo componente; O componente pode procurar sua dependência utilizando a interface Container. Obtendo dependência com o CDL public class ContextualizedDependencyLookup implements ManagedComponent { private Dependency dep; public void performlookup(container container) { this.dep = (Dependency)container.getDependency ("mydependency"); } } 86

87 Dependency Injection Problema Controle convencional: o próprio objeto cria ou localiza suas dependências: acoplamento 87

88 Injeção de Dependência por meio de Construtor Dependência do componente é disponibilizada através de seu(s) construtor(es); O argumento recebido será sua dependência. Injeção de Dependência pelo Construtor com Spring public class ConstructorInjection { private Dependency dep; public ConstructorInjection(Dependency dep) { this.dep = dep; } } 88

89 Injeção de Dependência por meio de método Setter O contêiner IoC injeta um componente de dependência através de seu método set (JavaBean); O componente setter permite um conjunto de dependências que o contêiner de inversão de controle pode gerenciar. Injeção de Dependência através do método Setter com Spring public class SetterInjection { private Dependency dep; public void setmydependency(dependency dep) { this.dep = dep; } } 89

90 Injeção de Dependência por meio de Interface [Fow06] Componente de dependência através de uma interface; A interface InjectFinder será definida por qualquer um que fornecer a interface MovieFinder (no exemplo abaixo). Injeção de Dependência através de Interface. Exemplo no arcabouço Avalon public interface InjectFinder { public void injectfinder(moviefinder finder); } public class MovieLister implements InjectFinder { public void injectfinder(moviefinder finder){ this.finder = finder; } 90

91 Injeção de Dependência por meio de Interface Exemplo: Classe de Teste no Avalon: configura os componentes e os injetores. public class Tester { private Container container; private void configurecontainer(){ container = new Container(); registercomponents(); registerinjectors(); container.start(); } } 91

92 Injeção de Dependência por meio de Interface É preciso registrar os injetores que irão injetar os componentes dependentes; Cada interface de injeção precisa de algum código para injetar o objeto dependente; No código abaixo, registram-se os objetos injetores no contêiner: private void registerinjectors(){ container.registerinjector(injectfinder.class, container.lookup( MovieFinder )); } 92

93 Injeção versus Procura O tipo de IoC é definido pelo contêiner adotado. Com Dependency Pull, é necessário: registrar dependências; obter referências das dependências; interagir com as dependências obtidas. Utilizando CDL, é preciso: que as classes implementem uma interface específica; e procure por todas dependências manualmente. Com Injeção de Dependência, as classes precisam: permitir que as dependências sejam injetadas por meio de construtores, métodos setters ou interfaces. 93

94 Inversão de Controle e Padrão Reactor Reactor: Padrão de Arquitetura [POSA 2]; Conhecido também como Dispatcher, Notifier Contexto: Aplicação orientada a eventos que processa as informações de forma síncrona e serial. Problema: aplicações devem: atender muitas requisições simultaneamente, demultiplexar e despachar as indicações de eventos às respectivas implementações de serviço. 94

95 Inversão de Controle e Padrão Reactor Define uma interface que permite que aplicações: registrem ou removam tratadores de eventos; sejam executadas no laço de eventos da aplicação. Reactor utiliza um demultiplexador síncrono de evento para aguardar pela indicação de eventos que se originam de uma ou mais fontes. Quando ocorre um evento: o demultiplexador síncrono de evento notifica o Reactor; o Reactor aciona o tratador associado, para realização do serviço solicitado. O Reactor inverte o fluxo de controle, pois é responsabilidade dele (e não da aplicação) em disparar os tratadores concretos para cada tipo de evento. 95

96 Desvantagens na Inversão de Controle Dificuldade na integração de arcabouços: quando dois ou mais frameworks chamam simultaneamente o código da aplicação, cada qual pressupondo seu próprio fluxo de controle; Dificuldade na depuração do código e compreensão do fluxo: o controle é alternado entre o código da aplicação e o código do frameworks. 96

97 Injeção de Dependências (Inversão de Controle) Um dos benefícios de usar interface Em vez de Use

98 Injeção de Dependências (Inversão de Controle) Se A depende de InterB, fica fácil testar ou media A usando uma implementação/simulação de B para testes Interfaces devem ser pequenas Um objeto pode implementar várias interfaces Facilita a evolução (interfaces grandes publicam um contrato grande que não pode ser revogado. Planeje interfaces em todos os objetos Principalmente nos que oferecem serviços, singleton, etc..

99 Exemplo: controle convencional Linha 9: dependência fortemente acoplada Difícil de testar objeto sem testar dependência 99

100 A dependência 100

101 Diminuindo o acoplamento Melhor forma de eliminar o acoplamento é usar interfaces Implementação é dependente da interface Cliente depende da interface, não mais da implementação 101

102 Solução Em vez do programador buscar ou criar sua própria certificação, ela é atribuída a ele Para isto, deve haver método para criar a associação 102

103 Inversão de Controle 103

104 Padrões GRASP Básicos Creator Information Expert High Cohesion Low Coupling Controller Avançados Polymorphism Pure Fabrication Indirection Protected Variants 104

105 Protected Variants Problema: Como projetar objetos, subsistemas e sistemas para que as variações ou instabilidades nesses elementos não tenha um impacto indesejável nos outros elementos? Solução: Identificar pontos de variação ou instabilidades potenciais Atribuir responsabilidades para criar uma interface estável em volta desses pontos. Encapsulamento, interfaces, polimorfismo, indireção e padrões: máquinas virtuais e brokers são motivados por este princípio Evite enviar mensagens a objetos muito distantes

106 Aspectos Adicionais

107 Aspectos: separação de interesses A separação de interesses é objetivo essencial do processo de decomposição da solução de um problema Decomposição deve continuar até que cada unidade da solução possa ser compreendida e construída Cada unidade deve lidar com apenas um interesse Separação de interesses eficiente promove o código de melhor qualidade Maior modularidade Facilita atribuição de responsabilidades entre módulos Promove o reuso Facilita a evolução do software Viabiliza a análise do problema dentro de domínios específicos 107

108 Tipos de interesse Usando linguagem OO, pode-se representar de forma eficiente e modular as classes e procedimentos Outros interesses são implementados como partes de classes e partes ou composição de procedimentos 108

109 Scattering e tangling 109

110 Inclusão de nova funcionalidade Também sujeita a scattering e tangling Funcionalidade espalhada por várias classes (funcionalidade consiste de métodos contidos em várias classes) Funcionalidades misturadas com outros recursos (não é representado por uma entidade separada) 110

111 Como reduzir tangling e scattering Criar subclasse que implemente recursos, sobreponha métodos, etc. Problema: classes cliente têm que ser alteradas para que saibam como criar a nova subclasse: VeiculoCarga v = // new VeiculoCarga(); new VeiculoCarga2(); Design patterns como factory method resolveriam o problema VeiculoCarga v = VeiculoCarga.create(); mas sua interface precisaria ser planejada antes. 111