APERTO

No design orientado a objetos , GRASP significa General Responsibility Assignment Software Patterns , um acrônimo para "GRASP (design orientado a objetos General Responsibility Assignment Software Patterns)". Embora se considere que mais do que padrões em si, são uma série de “boas práticas” de aplicação recomendadas no projeto de software.

Especialista em informações

O especialista em informação GRASP é o princípio básico de atribuição de responsabilidades. Ela nos diz, por exemplo, que a responsabilidade pela criação de um objeto ou pela implementação de um método deve recair sobre a classe que conhece todas as informações necessárias para criá-lo. Desta forma obteremos um design com maior coesão e assim a informação permanece encapsulada (acoplamento diminuído).

Problema: Qual é o princípio geral para atribuir responsabilidades a objetos?

Solução: Atribua uma responsabilidade ao especialista em informações.

Benefícios: O encapsulamento é mantido, os objetos usam suas próprias informações para realizar suas tarefas. O comportamento é distribuído entre as classes que contêm as informações necessárias. Eles são mais fáceis de entender e manter.

Criador

O padrão criador nos ajuda a identificar quem deve ser responsável pela criação (ou instanciação ) de novos objetos ou classes .

A nova instância deve ser criada pela classe que:

Possui as informações necessárias para realizar a criação do objeto, ou
Use diretamente as instâncias criadas do objeto ou
Armazena ou manipula várias instâncias da classe
Contém ou adiciona a classe.

Uma das consequências do uso desse padrão é a visibilidade entre a classe criada e a classe criadora. Uma vantagem é o baixo acoplamento, o que significa facilidade de manutenção e reutilização. A instanciação é uma das atividades mais comuns em um sistema orientado a objetos. Consequentemente, é útil ter um princípio geral para atribuir responsabilidades de criação. Se bem mapeado, o design pode suportar acoplamento fraco, maior clareza, encapsulamento e reutilização.

Controlador

O padrão controlador é um padrão que serve de intermediário entre uma determinada interface e o algoritmo que a implementa, de forma que é aquele que recebe os dados do usuário e aquele que os envia para as diferentes classes de acordo com o método chamado.

Esse padrão sugere que a lógica de negócios seja separada da camada de apresentação, para aumentar a reutilização do código e ao mesmo tempo ter mais controle.

Recomenda-se dividir os eventos do sistema em tantos controladores quanto possível para aumentar a coesão e diminuir o acoplamento.

Alta coesão e baixo acoplamento

Os conceitos de coesão e acoplamento não estão intimamente relacionados, porém recomenda-se ter maior grau de coesão com menor grau de acoplamento. Dessa forma, há menos dependência e as finalidades de cada objeto no sistema são especificadas.

Alta coesão

Ela nos diz que as informações que uma classe armazena devem ser consistentes e devem estar (na medida do possível) relacionadas à classe.

Coesão Coincidente : O módulo realiza múltiplas tarefas, sem qualquer relação entre elas.
Coesão Lógica : O módulo executa múltiplas tarefas relacionadas, mas, em tempo de execução, apenas uma delas será executada.
Coesão Temporal : As tarefas realizadas por um módulo têm, como única relação, "que devem ser executadas ao mesmo tempo".
Coesão Processual : A única relação entre as tarefas de um módulo é que elas correspondem a uma sequência de etapas específicas do "produto".
Coesão de Comunicação : As tarefas correspondem a uma sequência de etapas típicas do "produto" e todas afetam os mesmos dados.
Coesão da informação : As tarefas realizadas por um módulo têm seu próprio ponto de partida, sua codificação independente e trabalham sobre os mesmos dados. Exemplo típico: OBJETOS
Coesão Funcional : Quando o módulo executa uma e apenas uma tarefa, tendo um único objetivo a cumprir, diz-se que possui Coesão Funcional.

Baixo acoplamento

É a ideia de ter as aulas o menos ligadas umas às outras possível. De tal forma que no caso de modificação em alguma delas, haja o menor impacto possível no restante das classes, promovendo o reuso e reduzindo a dependência entre as classes.

Content Coupling : Quando um módulo faz referência direta ao conteúdo de outro módulo. (Em linguagens de alto nível é muito raro)
Acoplamento comum : Quando dois módulos acessam (e afetam) o mesmo valor global.
Acoplamento de controle : quando um módulo envia um elemento de controle para outro que determina sua lógica de execução.

Polimorfismo

Sempre que você tiver que cumprir uma responsabilidade dependente do tipo, você deve fazer uso do polimorfismo , quando as alternativas ou comportamentos relacionados variam por tipo (classe), atribua a responsabilidade pelo comportamento - usando operações polimórficas - aos tipos para os quais o comportamento varia. Atribua o mesmo nome a serviços em objetos diferentes.

Manufatura pura

A fabricação pura ocorre em classes que não representam uma entidade ou objeto real no domínio do problema, mas são criadas intencionalmente para diminuir o acoplamento, aumentar a coesão e/ou aprimorar a reutilização de código. É a solução quando o designer se depara com uma classe solta e não tem outra classe para implementar alguns métodos. Ou seja, é uma classe "inventada" ou que não existe no problema, mas ao adicioná-la o sistema é melhorado estruturalmente. Como contra-indicação, devemos mencionar que ao abusar desse padrão, geralmente aparecem classes de funções ou algoritmos (que possuem apenas um método).

Indireção

O padrão de indireção nos permite diminuir o acoplamento entre duas classes, atribuindo a responsabilidade da mediação entre elas a um terceiro elemento intermediário (classe). Por exemplo, num POS (Point of Sale Terminal) utilizamos uma Interface "Adaptador" através da qual, com as classes que o realizam, podemos estabelecer os diferentes meios de pagamento.

Problema: Onde atribuir responsabilidades para evitar/reduzir o acoplamento direto entre elementos e melhorar a reutilização?
Solução: Atribua a responsabilidade a um objeto que faz a mediação entre os elementos.

Variações Protegidas

É o princípio fundamental de se proteger de mudanças, de tal forma que tudo o que prevemos em uma análise anterior que seja suscetível a modificações, envolvê-lo em uma interface, usando polimorfismo para criar várias implementações e permitir implementações futuras, para que o que permanece o menos vinculado possível ao nosso sistema, para que quando a variação ocorra, tenha o menor impacto sobre nós. Faz parte dos padrões avançados de agarrar.