GRASP: Projeto de Objetos com Responsabilidade – Parte 2

2 Pauta Criador (Creator) Criador (Creator) Fraco Acoplamento (Low Coupling) Fraco Acoplamento (Low Coupling) Alta Coesão (High Coesion) Alta Coesão (High Coesion) Controlador (Controller) Controlador (Controller) Tempo médio por slide: 3,5 minutos Previsão de conclusão da teoria: 20h15 Tempo para elaboração do projeto final: 2h (20h30 até 22h30) Obs: Nos slides já estão dispostos os exemplos práticos para tirarem vossas dúvidas. Estes exemplos serão explicados durante a exposição teórica!

3 O Padrão Criador Problema Problema Quem deve criar novas instâncias de uma classe? Solução Solução Atribuir à classe B a responsabilidade de criar instância da classe A se uma das seguintes condições se aplicar: Atribuir à classe B a responsabilidade de criar instância da classe A se uma das seguintes condições se aplicar: B agrega objetos da classe A B agrega objetos da classe A B contém objetos da classe A B contém objetos da classe A B registra instâncias da classe A B registra instâncias da classe A B possui os dados usados para inicializar A B possui os dados usados para inicializar A B é um criador (creator) de objetos da classe A B é um criador (creator) de objetos da classe A Se mais de uma opção se aplica, escolha o B que agregue ou contenha objetos da classe A Se mais de uma opção se aplica, escolha o B que agregue ou contenha objetos da classe A

4 Criador No exemplo anterior, quem deveria criar uma instância de LinhaDetalheVenda? No exemplo anterior, quem deveria criar uma instância de LinhaDetalheVenda? Pelo padrão Creator, precisamos achar alguém que agrega, contém,... instâncias de LinhaDetalheVenda Pelo padrão Creator, precisamos achar alguém que agrega, contém,... instâncias de LinhaDetalheVenda Analisemos o diagrama Analisemos o diagrama

5 Criador Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias Venda agrega instâncias de LinhaDetalheVenda e é portanto um bom candidato para criar as instâncias

6 Discussão Escolhemos um criador que estará conectado ao objeto criado, de qualquer forma, depois da criação Escolhemos um criador que estará conectado ao objeto criado, de qualquer forma, depois da criação Isso leva a fraco acoplamento Isso leva a fraco acoplamento Exemplo de criador que possui os valores de inicialização Exemplo de criador que possui os valores de inicialização Uma instância de Pagamento deve ser criada Uma instância de Pagamento deve ser criada A instância deve receber o total da venda A instância deve receber o total da venda Quem tem essa informação? Venda Quem tem essa informação? Venda Venda é um bom candidato para criar objetos da classe Pagamento Venda é um bom candidato para criar objetos da classe Pagamento

7 Conseqüências Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação Fraco acoplamento, já que o objeto criado deve normalmente ser visível ao criador, depois da criação

8 Fraco Acoplamento Solução Solução Atribuir uma responsabilidade de maneira que o acoplamento permaneça fraco. Uma classe com acoplamento alto(ou forte) depende de muitas outras. Tais classes podem ser indesejáveis; algumas tem os seguintes problemas: - As mudanças em classes relacionadas forçam mudanças locais; - São difíceis de compreender isoladamente; - São de difícil reutilização, porque isso exige a presença das classes das quais depende.

9 Fraco Acoplamento Exemplo Exemplo Considere o seguinte diagrama parcial de classes: Considere o seguinte diagrama parcial de classes: Suponha que temos que criar um Pagamento e associá-lo a uma Venda Suponha que temos que criar um Pagamento e associá-lo a uma Venda Que classe deveria ter essa responsabilidade? Que classe deveria ter essa responsabilidade? Alternativa 1: No mundo real, um TPDV "registra" um pagamento e o padrão Creator sugere que TPDV poderia criar Pagamento Alternativa 1: No mundo real, um TPDV "registra" um pagamento e o padrão Creator sugere que TPDV poderia criar Pagamento TPDV deve então passar o pagamento para a Venda TPDV deve então passar o pagamento para a Venda Veja o resultado a seguir: Veja o resultado a seguir:

10 Fraco Acoplamento

11 Fraco Acoplamento Alternativa 2: Criar o Pagamento com Venda e associá-lo à Venda Alternativa 2: Criar o Pagamento com Venda e associá-lo à Venda Veja o resultado abaixo: Veja o resultado abaixo:

12 Fraco Acoplamento Supondo que a Venda deva ter conhecimento do pagamento (depois da criação) de qualquer jeito, a alternativa 2 tem menos acoplamento (TPDV não está acoplado a Pagamento) Supondo que a Venda deva ter conhecimento do pagamento (depois da criação) de qualquer jeito, a alternativa 2 tem menos acoplamento (TPDV não está acoplado a Pagamento) Dois padrões (Criador e Fraco acoplamento) sugeriram diferentes soluções Dois padrões (Criador e Fraco acoplamento) sugeriram diferentes soluções Minimizar acoplamento ganha Minimizar acoplamento ganha

13 Fraco Acoplamento Discussão Discussão Minimizar acoplamento é um dos princípios de ouro do projeto OO Minimizar acoplamento é um dos princípios de ouro do projeto OO Acoplamento se manifesta de várias formas: Acoplamento se manifesta de várias formas: X tem um atributo que referencia uma instância de Y X tem um atributo que referencia uma instância de Y X tem um método que referencia uma instância de Y X tem um método que referencia uma instância de Y Pode ser parâmetro, variável local, objeto retornado pelo método Pode ser parâmetro, variável local, objeto retornado pelo método X é uma subclasse direta ou indireta de Y X é uma subclasse direta ou indireta de Y X implementa a interface Y X implementa a interface Y A herança é o tipo de acoplamento mais forte A herança é o tipo de acoplamento mais forte Tipos de acoplamentos (do menos ruim até o pior) Tipos de acoplamentos (do menos ruim até o pior) Acoplamento de dados Acoplamento de dados Acoplamento de controle Acoplamento de controle Acoplamento de dados globais Acoplamento de dados globais Acoplamento de dados internos Acoplamento de dados internos

14 Herança X Composição Composição e Herança Composição e Herança Composição e herança são dois mecanismos para reutilizar objetos e suas responsabilidades Composição e herança são dois mecanismos para reutilizar objetos e suas responsabilidades Alguns anos atrás (e na cabeça de alguns programadores ainda!), a herança era considerada a ferramenta básica de extensão e reuso de funcionalidade Alguns anos atrás (e na cabeça de alguns programadores ainda!), a herança era considerada a ferramenta básica de extensão e reuso de funcionalidade A composição estende uma classe pela delegação de trabalho para outro objeto a herança estende atributos e métodos de uma classe A composição estende uma classe pela delegação de trabalho para outro objeto a herança estende atributos e métodos de uma classe Hoje, considera-se que a composição é muito superior à herança na maioria dos casos Hoje, considera-se que a composição é muito superior à herança na maioria dos casos A herança deve ser utilizada em alguns (relativamente poucos) contextos A herança deve ser utilizada em alguns (relativamente poucos) contextos Vamos portanto desinflar um pouco a bola da herança... Vamos portanto desinflar um pouco a bola da herança...

15 Herança X Composição Um exemplo de composição Um exemplo de composição Use composição para estender as responsabilidades pela delegação de trabalho a outros objetos Use composição para estender as responsabilidades pela delegação de trabalho a outros objetos Um exemplo no domínio de endereços Um exemplo no domínio de endereços Uma empresa tem um endereço (digamos só um) Uma empresa tem um endereço (digamos só um) Uma empresa "tem" um endereço Uma empresa "tem" um endereço Podemos deixar o objeto empresa responsável pelo objeto endereço e temos agregação composta (composição) Podemos deixar o objeto empresa responsável pelo objeto endereço e temos agregação composta (composição)

16 Herança X Composição Benefícios da herança Benefícios da herança Captura o que é comum e o isola daquilo que é diferente Captura o que é comum e o isola daquilo que é diferente A herança é vista diretamente no código A herança é vista diretamente no código Problemas da herança Problemas da herança O encapsulamento entre classes e subclasses é fraco (o acoplamento é forte) O encapsulamento entre classes e subclasses é fraco (o acoplamento é forte) Mudar uma superclasse pode afetar todas as subclasses Mudar uma superclasse pode afetar todas as subclasses The weak base-class problem The weak base-class problem Isso viola um dos princípios básicos de projeto O-O (manter fraco acoplamento) Isso viola um dos princípios básicos de projeto O-O (manter fraco acoplamento) Às vezes um objeto precisa ser de uma classe diferente em momentos diferentes Às vezes um objeto precisa ser de uma classe diferente em momentos diferentes Com herança, a estrutura está parafusada no código e não pode sofrer alterações facilmente em tempo de execução Com herança, a estrutura está parafusada no código e não pode sofrer alterações facilmente em tempo de execução A herança é um relacionamento estático que não muda com tempo A herança é um relacionamento estático que não muda com tempo

17 Herança X Composição 5 regras para o uso de herança (Coad) 5 regras para o uso de herança (Coad) O objeto "é um tipo especial de" e não "um papel assumido por" O objeto "é um tipo especial de" e não "um papel assumido por" O objeto nunca tem que mudar para outra classe O objeto nunca tem que mudar para outra classe A subclasse estende a superclasse mas não faz override ou anulação de variáveis e/ou métodos A subclasse estende a superclasse mas não faz override ou anulação de variáveis e/ou métodos Não é uma subclasse de uma classe "utilitária" Não é uma subclasse de uma classe "utilitária" Não é uma boa idéia fazer isso porque herdar de, digamos, Dictionary deixa a classe vulnerável a mudanças futuras à classe Dictionary Não é uma boa idéia fazer isso porque herdar de, digamos, Dictionary deixa a classe vulnerável a mudanças futuras à classe Dictionary O objeto original não "é" uma Dictionary (mas pode usá-la) O objeto original não "é" uma Dictionary (mas pode usá-la) Não é uma boa idéia porque enfraquece a encapsulação Não é uma boa idéia porque enfraquece a encapsulação Clientes poderão supor que a classe é uma subclasse da classe utilitária e não funcionarão se a classe eventualmente mudar sua superclasse Clientes poderão supor que a classe é uma subclasse da classe utilitária e não funcionarão se a classe eventualmente mudar sua superclasse Exemplo: x usa y que é subclasse de vector Exemplo: x usa y que é subclasse de vector x usa y sabendo que é um Vector x usa y sabendo que é um Vector Amanhã, y acaba sendo mudada para ser subclasse de Dictionary Amanhã, y acaba sendo mudada para ser subclasse de Dictionary x se lasca! x se lasca! Para classes do domínio do problema, a subclasse expressa tipos especiais de papeis, transações ou dispositivos Para classes do domínio do problema, a subclasse expressa tipos especiais de papeis, transações ou dispositivos

18 Alta Coesão Problema Problema Como manter a complexidade (das classes) em um nível “controlável”? Como manter a complexidade (das classes) em um nível “controlável”? Solução Solução Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta Atribuir a responsabilidade de modo que a coesão (força do relacionamento entre as responsabilidades de uma classe) permaneça alta

19 Alta Coesão Exemplo Exemplo Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Quem deve ser responsável por criar um Pagamento e associá-lo à Venda? Pelo padrão Criador, seria TVenda. Mas se TVenda for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e não coeso Pelo padrão Criador, seria TVenda. Mas se TVenda for o responsável pela maioria das operações do sistema, ele vai ficar cada vez mais sobrecarregado e não coeso :TVenda:Venda :Pagto fazerPagto()1: fazerPagto() 1.1. create()

20 Alta Coesão Níveis de coesão Níveis de coesão Muito baixa Muito baixa Um classe tem muitas responsabilidades em áreas funcionais bastantes diferentes Um classe tem muitas responsabilidades em áreas funcionais bastantes diferentes Baixa Baixa Um classe é responsável por uma tarefa complexa de uma única área funcional Um classe é responsável por uma tarefa complexa de uma única área funcional Moderada Moderada Um classe tem moderadas responsabilidades em uma única área funcional e colabora com outras classes para cumprir suas tarefas Um classe tem moderadas responsabilidades em uma única área funcional e colabora com outras classes para cumprir suas tarefas Alta Alta Um classe tem responsabilidades leves apenas em algumas áreas que estão logicamente relacionadas com o conceito da classe Um classe tem responsabilidades leves apenas em algumas áreas que estão logicamente relacionadas com o conceito da classe

21 Alta Coesão Benefícios Benefícios Aumento da clareza e compreensão do projeto Aumento da clareza e compreensão do projeto Simplificação de manutenção Simplificação de manutenção Baixo acoplamento Baixo acoplamento Reuso facilitado Reuso facilitado

22 Controlador Problema Problema Quem deve ser responsável por tratar um evento do sistema? Quem deve ser responsável por tratar um evento do sistema? Solução Solução Atribuir a responsabilidade de tratar um evento do sistema para uma classe “controladora” representando: Atribuir a responsabilidade de tratar um evento do sistema para uma classe “controladora” representando: n o sistema como um todo (facade controller) n o negócio ou organização com um todo (facade controller) n uma coisa ou papel de uma pessoa do mundo real envolvida diretamente com a tarefa (role controller) n um “tratador” (handler) artificial para todos os eventos de um caso de uso (use-case controller)

23 Controlador Exemplo Exemplo Pelos padrões Baixo Acoplamento e Alta Coesão, a melhor escolha como controlador é demonstrada abaixo Pelos padrões Baixo Acoplamento e Alta Coesão, a melhor escolha como controlador é demonstrada abaixo Eventos de caso de uso (conhecido como sessão de caso de uso)

24 Elaboração do Trabalho de avaliação Lembrem-se de elaborar diagramas de seqüência apenas para os casos relevantes (que demonstrem quem cria quem, quem faz o quê...) Lembrem-se de elaborar diagramas de seqüência apenas para os casos relevantes (que demonstrem quem cria quem, quem faz o quê...) Trabalhem sempre no escopo do caso de uso Trabalhem sempre no escopo do caso de uso Pensem na reutilização de objetos em vários cenários e casos de uso distintos – o propósito é reduzir a quantidade de código para uma maior variedade de funcionalidade Pensem na reutilização de objetos em vários cenários e casos de uso distintos – o propósito é reduzir a quantidade de código para uma maior variedade de funcionalidade Pensem em objetos de software e não em tabelas de banco de dados Pensem em objetos de software e não em tabelas de banco de dados