Padrões GRASP

Olá pessoal!
Hoje nós vamos falar sobre os padrões GRASP. Engraçado né? Está no plural. Isso porque GRASP é um acrônomo para General Responsability Assignment Software Patterns ( Padrões Gerais para Atribuição de Responsabilidades). Bom, para esse post nós teremos como base esse minicurso do YouTube sobre  padrões GRASP. Vamos lá!

Uma definição feita no minicurso sobre padrões GRASP é que: é um conjunto de princípios fundamentais para modelagem de objetos e atribuição de responsabilidades escrito na forma de padrões. Um padrão do GRASP é um par: problema e solução.

Já que é um par problema solução, vamos falar primeiro o problema e depois o padrão mais adequado para a ocasião.

1) Qual princípio básico para se atribuir responsabilidade a objetos ? Ora, vamos atribuir a responsabilidade a quem tem a informação para realizá-la.
Qual o padrão que estamos utilizando ? O information expert!
Os benefícios ao usar são:

• Encapsulamento mantido 
• Comportamento é bem mais distribuído entre as classes ( um doce pra quem acertar o nome da postagem onde nós falamos sobre isso).  

Problemas:

• Há situações onde a solução sugerida pelo information expert leva a problemas de acoplamento  e coesão.

2) Quem deve ser responsável por criar uma nova instância de uma classe? 

Essa não é tão fácil. Temos alguns critérios a seguir.

A classe B deve ser responsável por criar uma instância da classe A, se:

• B agrega objetos da classe A.
• B contém objetos de A.
• B armazena instâncias de A.
• B, de forma privada, usa instâncias de A.
• B tem os dados necessários para inicializar A.

Qual padrão estamos utilizando ? Creator!

Benefícios ao usar são:

• Mantém estável o grau de acoplamento entre as classes. 

Problemas:

• Quando a criação de uma instância for muito complexa, envolver dependências tecnológicas ou subsistemas externos, é preferível delegar essa responsabilidade a um Factory ( já já falaremos sobre um outro tipo de padrão que contém o Factory)

3)Como reduzir o impacto de mudanças ? Atribuindo responsabilidade de forma a manter o acoplamento(desnecessário) baixo.
Como manter os objetos focados, fáceis de entender, gerenciáveis e ainda pouco acoplados ?

Atribuindo responsabilidade de forma a manter a coesão funcional alta.

Por que duas questões em uma ? 

Porque os padrões utilizados estão bem relacionados. Quem são eles ? Baixo acoplamento e alta coesão, respectivamente.

Benefícios ao usar:

• Potencializa reuso 
• Facilita entendimento 
• Minimiza efeitos de mudança 
• Maior manutenabilidade

Problemas:

• O baixo acoplamento utilizado ao extremo leva a design pobre. Posso criar um sistema em uma única classe que vai ter acoplamento nulo. ( olha quem está aqui de novo..)

4) Quem deve responder aos eventos do sistema ? Atribuindo responsabilidade a uma classe que represente todo um sistema ou represente os serviços de um módulo ou subsistema. É a classe raiz do sistema/módulo.

Qual é o padrão? Controller!

Benefícios ao usar: 

• Aumenta potência reuso 
• Permite a criação de interfaces plugavéis
• Define claramente pontos de entrada no sistema

Problemas:

• Falta da análise da coesão pode levar a cria controladores inchados, cheios de métodos pouco relacionados entre si.

Achamos de falar sobre os principais padrões GRASP, mas ainda tem mais quatro. Só vamos citá-los para você conhecer.

• Polymorphism
• Indirection 
• Pure Fabrication 
• Protected Variations

Depois de falarmos sobre o GRASP, existem outros conjuntos de princípios para modelagem orientado a objetos, como o SOLID e o GoF.

Não vamos nos aprofundar em nenhum dos dois, mas só para não ficar na curiosidade, vamos falar bem rapidinho sobre esses dois e as diferenças deles para o GRASP. 

O SOLID, assim como o GRASP, é um acrônomo para:

• Single Responsability: princípio da responsabilidade única. Nada de fazer a classe assobiar e chupar cana.
• Open/closed: todas as entidades devem ser abertas para extensão e fechadas para modificações.
• Liskov Substitution: qualquer objeto do tipo X ( que é subtipo de Y) deveria poder substituir um objeto do tipo Y sem alterar as propriedades básicas do sistema. 
• Interface Segregation: As interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. 
• Dependency Inversion: os módulos tem que depender de abstrações e não de classes concretas. 

Quais as diferenças ? Começando pelo tamanho, bem menor que o GRASP. Mas algo mais importante é que o SOLID abrange um pouco mais do que princípios para atribuição de responsabilidades, ele te oferece um política de boas práticas de como devem ser as características do sistema.

E o GoF ? Tem uma história legal, saca só.

Então, em 1994 quatro autores, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, publicaram um livro, o Design Patterns: Elements of Reusable Object-Oriented Software (Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos) para explicar conceitos de padrões de projeto para o desenvolvimento de software.

São divididos  em tres categorias :

• Padrões comportamentais 
• Padrões criativos 
• Padrões estruturais

Diferença ? Esse é bem mais abrangente do que os dois anteriores. São 23 padrões divididos naqueles grupos ali de cima. 

Dá para o seu software ficar maneiro com essas ideias discutidas hoje. Divirta-se brincando com alguns desses.

Obs: no minicurso de GRASP, o instrutor apresenta alguns exercícios. Sugiro que você os faca para solidificar o conhecimento. 

Até a próxima!