Nome: GRASP (General Responsibility Assignment Software Patterns)

Um sistema O.O. é composto por vários objetos que colaboram entre si, trocando "mensagens"� para satisfazer aos requisitos do sistema proposto, o planejamento de como dividir as responsabilidades entre os objetos é essencial para obter um sistema fácil de entender, robusto, reutilizável e extensível. GRASP (Padrões Genéricos de Software para Atribuição de Responsabilidade) ajuda a definir as responsabilidades, o seu estudo possibilita entender os princípios de um bom projeto O.O.

Responsabilidades: São as descrições do que os objetos tem de fazer, os métodos são as implementações das responsabilidades, um ponto importante é que nem sempre uma responsabilidade é satisfeita somente por um método, grandes responsabilidades são divididas para manter a coesão da Classe.


Os principais padrões GRASP:

- Especialista (Expert)
- Criador (Creator)
- Coesão alta (High Cohesion)
- Acoplamento fraco (Low Coupling)
- Controlador (Controller)


Criador
Problema: Definir quem será responsável por instanciar uma classe.
Solução: Atribua à classe "A" a responsabilidade de instanciar a classe B caso algumas destas condições sejam verdadeiras (quanto mais alternativas sejam verdadeiras melhor).

- A contém ou agrega B.
- A registra a existência de B.
- A usa B.
- A têm os dados necessários para o construtor de B.

Especialista
Problema: Qual é o princípio geral para a atribuição de responsabilidades aos objetos?
Solução: Atribua a responsabilidade ao especialista: a classe que tem as informações necessárias para assumir a responsabilidade.
Benefícios: O encapsulamento da informação é mantido uma vez que os objetos usam seus próprios dados para realizar as tarefas.

Isto normalmente leva a um baixo acoplamento entre as classes.

O comportamento do sistema é distribuído entre as classes que têm as informações, encorajando a definição de classes mais "leves", mais fáceis de entender e de manter.

Contradição: Em algumas situações, a solução sugerida pelo especialista pode ser indesejada, por às vezes causar baixa coesão.


Baixo Acoplamento
Problema: Como prover baixa dependência entre classes, reduzir o impacto de mudanças e obter alta reutilização?
Solução: Atribua as responsabilidades de modo que o acoplamento entre classes permaneça baixo. Use este princípio para avaliar alternativas.

Ponto-chave: O padrão especialista fornece "baixo acoplamento", pois o ele nos pede uma classe que tenha a maior parte da informação para executar uma tarefa em específico, se delegarmos a responsabilidade para uma classe "Animal" para tratar uma responsabilidade de persistência ao banco de dados o acoplamento será muito maior, pois eu terei de fazer algo para "Animal" entender sobre persistir o banco de dados que não tem nada a ver com sua função.


Coesão Alta
Problema: Como manter os objetos focados, compreensíveis, gerenciáveis e, em conseqüência, com Baixo Acoplamento?
Solução: Atribua responsabilidades de modo que a coesão da classe permaneça alta. Use esse critério para avaliar alternativas

Uma classe com baixa coesão sofre dos seguintes problemas:

- Difícil de compreender
- Difícil de reutilizar
- Difícil de manter
- Frágil; freqüentemente tem de ser alterada.


Como um princípio básico, uma classe com alta coesão:

- Tem um número relativamente pequeno de métodos
- A funcionalidade desses métodos é altamente relacionada
- Não faz trabalho de mais.


Controlador
Problema: Que objeto, fora da camada de apresentação, deve receber e coordenar a solicitação da execução de uma operação?

O princípio da separação Modelo-Visão pode ser enunciado em duas partes:
- Não conecte diretamente objetos pertencentes à interface com o usuário (visão) com objetos não pertencentes à interface com o usuário (IU).
- Não coloque lógica da aplicação (tal como o cálculo de impostos) nos métodos dos objetos da IU A motivação para a separação Modelo-Visão inclui:
--- Suportar a criação de classes de negócio coesas, com foco nos processos do domínio ao invés de na interface com o usuário.
--- Permitir o desenvolvimento separado das camadas de apresentação e negócio.
--- Minimizar o impacto na camada de negócio das alterações nos requisitos da interface com o usuário.
--- Permitir que novas visões sejam facilmente conectadas aos objetos de negócio existentes, sem afetar a camada de negócios.
--- Permitir a existência de múltiplas visões simultâneas para uma mesma camada de negócios (por exemplo, a visualização de dados de vendas na forma tabular ou através de um gráfico de pizzas). O objeto Controlador responde a uma questão básica no projeto de sistemas OO: Como conectar a camada de apresentação à camada da lógica do negócio?


O controlador é o primeiro objeto fora da camada de interface com o usuário a receber ou tratar uma mensagem para o sistema.

Existem duas alternativas possíveis para o objeto controlador:
- Um objeto Controlador para todo o sistema
- Um objeto Controlador por Caso de Uso (ou por cenário de Caso de Uso) Os benefícios do padrão controlador são:
--- Diminui a sensibilidade da camada de apresentação em relação à lógica de domínio
--- Oportunidade para controlar o estado do caso de uso

Conclusão
Um projeto OO sempre tem que ser bem planejado, não há um caminho certo para o desenvolvimento de um software, mas sim regras, há muitas maneiras de se chegar ao mesmo lugar, você tem que decidir como você vai construir suas classes dependendo dos impactos de coesão, escalabilidade, acoplamento, etc.

Bom é isso pessoal, espero que tenham gostado e qualquer coisa é só perguntar, se estiver ao meu alcance.


=============================================
Fontes: http://www.dcce.ibilce.unesp.br/~ines/curs...5es%20GRASP.pdf
- Livro, "Utilizando UML e Padrões"�, Craig Larman. (Ótimo livro).
- equipe.nce.ufrj.br/jonas/asi/privado3/Grasp%20Patterns.ppt