GRASP: General Responsibility And Assignment Software Patterns

GRASP: General Responsibility and

Assignment Software Patterns

Introdução

Atualmente, a quantidade de padrões de projeto identificados e catalogados em diferentes obras é provavelmente incalculável. Afinal, existem muitas situações onde existem padrões aplicados e que poderiam ser estudados.

Não é à toa, encontrarmos padrões para instanciar objetos, para lidar com problemas de concorrência ou até para construir web services. Entre eles, os mais conhecidos são os padrões GRASP (General Responsibility Assignment Software Patterns), estudados por Craig Lerman.

 

GRASP: General Responsibility and Assignment Software Patterns escrevem os princípios fundamentais da atribuição de responsabilidades a objetos, expressas na forma de padrões; Ajudam à compreender melhor a utilização de vários do paradigma O-O em projetos mais complexos;

Exploram os princípios fundamentais de sistemas OO

­ 5 padrões fundamentais

­ 4 padrões avançados

Segue a definição detalhada dos padrões GRASP:

Especialista na Informação

O Especialista na Informação é o padrão mais utilizado na atribuição de responsabilidades entre todos os outros integrantes do GRASP, ele é um princípio básico, usado continuamente no projeto orientado por objetos.

“O Especialista não pretende ser uma idéia obscura ou fantasiosa; ele expressa a “intuição” comum de que os objetos fazem coisas relacionadas com a informação que têm.” (LARMAN, 1998).44

Ou seja, um objeto de software deve fazer as operações normalmente executadas pela abstração do mundo real que ele representa, considerando o caráter “animado” presentes nos objetos de software. Como exemplo dessa afirmação: imagine no mundo real, um contracheque não pode calcular seus valores, ele é inanimado. É necessário que alguém calcule os valores e adicione o resultado a ele. Entretanto, na orientação a objetos, todos os objetos de software podem assumir responsabilidades e fazer diversas operações pois eles são “vivos” ou “animados”. Normalmente, fazem coisas relacionadas com a informação que conhecem. Larman denomina esse comportamento de “Princípio de Animação” (LARMAN,1998).

Problema

Qual é o princípio básico de atribuição de responsabilidades a objetos? Um Modelo de Projeto pode definir dezenas ou centenas de classes de software, e uma aplicação pode exigir a satisfação de centenas ou milhares de responsabilidades. Durante o projeto orientado a objetos, quando as interações entre objetos são definidas, fazemos escolhas de atribuições de responsabilidades a classes. Se bem feitas, essas escolhas tornam os sistemas fáceis de compreender, de manter e de estender, e há a possibilidade de reutilização de componentes em futuras aplicações.

Solução

Atribuir uma responsabilidade ao especialista na informação: a classe que tem a informação necessária para satisfazer a responsabilidade.

Controlador

Os sistemas de softwares normalmente são desenvolvidos para receber uma entrada externa, processar uma tarefa sobre os dados, e gerar uma saída contendo o resultado do processamento. O foco do padrão Controlador é orientar a escolha de uma classe responsável por tratar as entradas externas ao aplicativo.

Problema

Quem deve ser responsável por tratar um evento de sistema? Um evento de entrada de um sistema é um evento gerado por um ator externo. Ele está associado com operações do sistema em resposta a eventos do sistema, da mesma forma que os métodos e as mensagens estão relacionados. Por exemplo, quando um gestor que acessa a aplicação e pressiona o botão “AdicionarVerba”, ele está gerando um evento do sistema que indica que “uma verba deve ser lançada no contracheque”. Da mesma forma, quando um escritor que usa um processador de texto pressiona o botão de verificação ortográfica, ele está gerando um evento de sistema que indica “executar uma verificação ortográfica”. Um Controlador é um objeto da interface (mas não da interface com o usuário), responsável por receber ou tratar um evento do sistema. Um Controlador define o método para a operação do sistema

Solução

Atribuir a responsabilidade de receber ou tratar uma mensagem de um evento de sistema a uma classe que represente uma das seguintes escolhas:

• Represente todo o sistema, o dispositivo ou subsistemas (controlador de fachada).

• Represente um cenário de um caso de uso dentro do qual ocorra o evento do sistema, frequentemente chamado TratadorDe<...>, ou SessãoDe<...> (controlador de caso de uso).

o Use a mesma classe controladora para todos os eventos de sistema no mesmo cenário do caso de uso.

o Dito em termos informais, uma sessão é uma instância de conversação com um ator. As sessões podem ter duração variada, mas frequentemente são organizadas em casos de uso (sessões de caso de uso).

Criador

O padrão Criador guia a atribuição de responsabilidades relacionadas com a criação de objetos de software. Seu objetivo é encontrar um objeto “criador” que necessite ser conectado ao objeto criado em qualquer momento da execução. Escolhe-lo como o “criador” garante uma solução com fraco acoplamento e uma coesão elevada.

Problema

Quem deve ser responsável pela criação de uma nova instância de uma classe? A criação de objetos é umas das atividades mais comuns em um sistema orientado por objetos. Consequentemente, é útil ter um princípio geral para a atribuição de responsabilidades de criação. Sendo essas responsabilidades bem atribuídas, o projeto apresentará acoplamento fraco, mais clareza, encapsulamento e reutilização.

Solução

Atribua à classe B a responsabilidade de criar uma instância da classe A se uma das seguintes condições for verdadeira:

• B agrega objetos de