Padrões para Atribuições de Responsabilidades

Apresentação em tema: "Padrões para Atribuições de Responsabilidades"— Transcrição da apresentação:

1 Padrões para Atribuições de Responsabilidades
Motivação Más escolhas de atribuição de responsabilidades geram sistemas e componentes frágeis e de difícil manutenção, extensão e reutilização. Quando utilizar? Padrões são utilizados durante a criação dos diagramas de interação

2 Padrões para Atribuições de Responsabilidades
O que são Padrões? Princípios, estilos e regras de programação, codificados em um formato estruturado, descrevendo problema/solução Um Padrão é um par nomeado problema/solução, que pode ser utilizado em novos contextos, com conselhos sobre como utilizá-lo em novas situações

3 Padrões para Atribuições de Responsabilidades
O que não são Padrões? Novos princípios da Engenharia de Software. Ao contrário, padrões tentam codificar o conhecimento, idiomas e princípios existentes

4 Padrões para Atribuições de Responsabilidades
Responsabilidades e Métodos Responsabilidade: contrato ou obrigação de uma classe Métodos: utilizados para implementar Responsabilidades Tipos de Responsabilidades: Fazer: ele próprio; iniciar ações em outros objetos; controlar atividades em outros objetos Conhecer: dados privados; objetos relacionados; coisas que pode calcular e derivar. São dedutíveis do modelo Conceitual

5 Padrões para Atribuições de Responsabilidades
O que são os Padrões GRASP ? Princípios fundamentais de atribuição de responsabilidades a objetos Quais são? Information Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Protected Variations

6 Padrões para Atribuições de Responsabilidades
Information Expert – Especialista Solução: atribui a responsabilidade ao especialista da informação Conclusão a satisfação de uma responsabilidade requer informações espalhadas por diferentes classes. desta forma existem vários especialistas parciais que colaboram com a tarefa Favorece ao acoplamento fraco uma vez que os objetos usam suas próprias informações para executarem as tarefas As classes ficam “leves” gerando alta coesão

7 Padrões para Atribuições de Responsabilidades
Creator – Criador Solução: atribua à classe B a responsabilidade de criar instâncias da classe A se: B agrega objetos de A B contém objetos de A B registra instâncias de objetos A B tem os dados de inicialização que serão passados para o objeto A, quando de sua criação ( B é um especialista com a relação a criação de A) Conclusão O objetivo do padrão é encontrar um Criador que necessita ser conectado ao objeto criado O criador pode ser encontrado procurando a classe que tem os dados de inicialização que serão passados durante a criação

8 Padrões para Atribuições de Responsabilidades
Low Coupling (Acoplamento Fraco) Solução: atribuir a responsabilidade de maneira que o acoplamento permaneça fraco. Conclusão Corresponde a um padrão de avaliação Não há uma medida que determine quanto um acoplamento é muito forte O importante é avaliar o grau atual de acoplamento e julgar se seu aumento trará problemas Se o acoplamento fraco é aplicado em excesso, leva a um projeto fraco, pois conduz a poucos objetos ativos, se coesão, inchados e complexos, que efetuam todo o trabalho. acoplamento fraco permite entendimento isolado, maior reutilização

9 Padrões para Atribuições de Responsabilidades
High Cohesion (Coesão Alta) Solução: atribuir uma responsabilidade de modo que a coesão permaneça alta. Alta Coesão - Uma classe com responsabilidades altamente relacionadas e que não executa um formidável volume de trabalho. Baixa Coesão - Uma classe que faz muitas coisas não relacionadas ou executa demasiado trabalho. Gera dificuldades para manter, reutilizar, compreender, e constantemente afetadas por mudanças. Conclusão Corresponde a um padrão de avaliação Como regra uma classe com coesão alta tem um número relativamente pequeno de métodos, com funcionalidades relacionadas e não executa muito trabalho.

10 Padrões para Atribuições de Responsabilidades
Controller – Controlador Solução: atribui a responsabilidade do tratamento de uma mensagem de um evento do sistema a uma classe que representa uma das escolhas: controlador fachada - representa o sistema todo ou todo o negócio ou organização. Adequado quando existem poucos eventos do sistema controlador de papel - representa algo no mundo real que é ativo ( por exemplo o papel de uma pessoa) e que pode estar envolvido na tarefa. controlador de caso de uso - representa um tratador artificial de todos os eventos de sistema de um caso de uso. Adequado quando existem muitos eventos do sistema em diferentes processos.

11 Padrões para Atribuições de Responsabilidades
Controller – Controlador Observações: Deve ser usada a mesma classe controladora para todos os eventos do sistema de um mesmo caso de uso. Classes como interfaces externas ( janelas, applet, etc.) não devem executar eventos do sistema. Apenas são responsáveis por receberem estes eventos e delegarem a um controlador Operações do sistema que refletem processos de negócio devem ser tratadas na camada de objetos de domínio. O que é um Controlador? É um objeto de interface, responsável por tratar um evento do sistema. Um controlador define um método para a operação do sistema.