Patterns

Patterns

1. Descrição nomeada de um problema e uma solução reutilizado em outros contextos

2. Composto por: Nome, Problema e Solução.

3. GRASP

   • princípios fundamentais de atribuição de responsabilidade a objetos.
   • Especialista (Expert)
     • Objetivo
       • Atribuir responsabilidade ao especialista da informação.
       • Objetos usam sua própria informação para cumprir responsabilidades.
     • Consequencias
       • Encapsulamento é mantido, já que objetos usam sua própria informação para cumprir responsabilidades,
       • Fraco acoplamento entre objetos e à alta coesão já que objetos fazem tudo que é relacionado à sua própria informação.
     • Anti-Padrão
       • Quando aumenta o acoplamento e reduz a coesão.
   • Criador (Creator)
     • Problema: Quem deveria ser responsável pela criação de uma nova instância de alguma classe?
     • Solução: atribua à classe B a responsabilidade de criar uma nova instância da classe A se:
       • B tem os valores iniciais que serão passados para objetos de A
       • B agregar objetos de A
       • B contém objetos de A
       • B registra instâncias de objetos de A
       • B usa objetos de A
   • Coesão alta (High Cohesion)
     • Uma classe deve ter apenas uma única responsabilidade e realizá-la de maneira satisfatória.
     • Favorecimento do acoplamento fraco.
     • Aumento no potencial de reutilização
   • Acoplamento fraco (Low Coupling)
     • acoplamento significa o quanto uma classe depende da outra para funcionar. E quanto maior for esta dependência entre ambas, dizemos que estas classes elas estão fortemente acopladas
     • Alto acoplamento impacta fortemente na reutilização.
   • Controlador (Controller)
     • Problema: Quem deve ser responsável por tratar um evento do sistema ?
     • Solução: A responsabilidade de receber ou tratar as mensagens de eventos (operações) do sistema pode ser atribuída uma classe que:
       • Represente todo o sistema, um dispositivo ou um subsistema (chamado de controlador fachada)
       • Represente um cenário de um caso de uso dentro do qual ocorra o evento: TratadorDe,NomeDoCasoDeUso> ControladorDe<NomeDoCasoDeUso>
     • Curas para controladores inchados • Acrescentar mais controladores – misturar controladores fachada e de casos de uso • Delegar responsabilidades
   • Polimorfismo
     • Problema: como lidar com alternativas baseadas em tipos? substituir um componente por outro sem afetar o cliente
     • Solução: não usar lógica condicional para realizar alternativas diferentes baseadas em tipos.
       • Atribua responsabilidades ao comportamento utilizando operações polimórficas.
   • Pure Fabrication
     • Problema: Que objeto deve ter a responsabilidade quando quer respeitar a alta Coesão e o Baixo Acoplamento, mas as soluções do Expert não são adequadas?
     • Solução: Atribuir um conjunto altamente coesivo de responsabilidades a uma classe artificial que não representa um conceito do domínio do problema.
   • Protected Variations
     • Problema: como projetar objetos, subsistema para que as variações ou instabilidades nesse sistemas não tenha impacto indesejável nos outros elementos?
     • Solução: Identificar pontos de variações ou instabilidade potenciais.
       • Atribuir responsabilidade para criar um interface estável em volta desses pontos
       • Evitar enviar mensagens a objetos muito distantes
       • Polimorfismo, interfaces, encapsulamento, indireção e padrões. são motivadas por este princípio

4. MVC

   • Entidade
     • Representam conceitos do mundo real e armazenam dados que os identificam.
   • Controle
     • Controlam a execução de processos e o fluxo de execução de todo ou de parte de casos de uso e comandam outras classes.
   • Visão
     • Realizam o interfaceamento com entidades externas (atores)