UnBArqDsw2021-2/2021.2_G6_Jobz_docs

Realizar estudo sobre os Grasps e Gofs

Closed this issue · 1 comments

Balbinoo commented

Descrição

Essa tarefa foi iniciada desde terça (22/02)

Critérios de Aceitação:

Aqui critérios de aceitação

Tarefas:

  • Estudar grasps
  • Esudar gofs
  • Escolher graps e gofs para o nosso projeto
AntonioAldisio commented

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.

Basicos

  1. Controller:

    • 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):

  2. Creator

    • 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).
    • Objeto: O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.
      • Um objeto Controlador para todo o sistema
      • Um objeto Controlador por Caso de Uso (ou por cenário
        de Caso de Uso)

Avançados

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

    1. Indirection
    • 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

Gof ("Gangue dos Quatro")

Criacional

  1. Builder: encapsular a construção de um produto e permitir que ele seja construído em etapas (https://refactoring.guru/design-patterns/builder)

  2. Abstract Factory: permite que um cliente crie famílias de objetos sem especificar suas classes concretas(https://refactoring.guru/design-patterns/abstract-factory#:~:text=Abstract%20Factory%20is%20a%20creational,without%20specifying%20their%20concrete%20classes.)

Estruturais

  1. Decorator: envelopa um objeto para fornecer novos comportamentos(https://refactoring.guru/design-patterns/decorator)

  2. Proxy: envelopa um objeto para controlar o acesso a ele (https://refactoring.guru/design-patterns/proxy)

Comportamental

  1. Command: encapsula uma solicitação como um objeto(https://refactoring.guru/design-patterns/command)

  2. Strategy: encapsula comportamentos intercambiáveis e usa a delegação para decidir qual deles será usado (https://refactoring.guru/design-patterns/strategy)

Fonte

http://www.facom.ufu.br/~bacala/ESOF/05a-Padr%C3%B5es%20GRASP.pdf
https://refactoring.guru/design-patterns/abstract-factory#:~:text=Abstract%20Factory%20is%20a%20creational,without%20specifying%20their%20concrete%20classes.