Padrões GRASP - parte 1

Após conhecer os padrões GRASP começamos a desenvolver muito mais claro e os "maus cheiros" diminuem consideravelmente, a minha intensão escrevendo este post é tentar explicar um pouco dos padrões ou conceitos GRASP, pois acredito que eles não são tão difundidos quanto os do GoF, porem são tão importante quanto.

Para começar devemos entender o que é responsabilidade, sendo assim devemos entender a responsabilidade pelo seu tamanho, por exemplo, uma grande responsabilidade pode envolver diversas classes e métodos, um exemplo disso é "gerenciar provas em um sistema de vestibular", isso pode envolver diversas classes ( sala, prova, candidato, etc ...) e diversos métodos, já se a responsabilidade for pequena isso pode envolver um único método, por exemplo, "imprimir lista de candidatos" isso talvez envolva um único método de uma classe , o entendimento de responsabilidade é importante pois assim começamos a entender a programação orientada a objetos,  para Craig Larman " uma responsabilidade não é a mesma coisa que um método - é uma abstração - porém métodos satisfazem as responsabilidades.", e Martin Fowler diz que "Entender responsabilidades é essencial para o bom projeto orientado a objetos".

As responsabilidades de um projeto podem ser divididas em “conhecer” e “fazer”

1. As responsabilidades “conhecer” estão relacionadas à distribuição das características do sistema entre as classes;
2. As responsabilidades “fazer” estão relacionadas com a distribuição do comportamento do sistema entre as classes;

A função principal dos padrões ou princípios GRASP é nos ajudar a projetar Orientado a Objetos com responsabilidade, pois como Craig Larman diz após entendermos os princípios e fundamentos os termos que veremos a seguir como especialista da informação, criador, e etc.., deixam de ser relevantes pois aprendemos o essencial que é como projetar guiados por responsabilidade.

Ao longo de 9 artigos pretendo explicar um pouco de cada padrão, e para isso vou usar o domínio sitado anteriormente, gerenciar as provas em um sistema de gerenciamento de vestibulares, para explicar o domínio vou utilizar a maneira bastante interessante que eu vi no livro DDD de Eric Evans, então vamos dar inicio ao trabalho.

Dialogo entre o Time e o Cliente para modelar o gerenciamento das provas:

...

Time: Bom dia, vamos começar pelas características da prova.

Cliente: Eu preciso definir qual o período de realização da prova, eu defino a data de realização e o horário de inicio e fim.

Time: Tem mais alguma coisa que você pretende definir ou diferenciar da prova?

Cliente: Sim, estava esquecendo já, as provas devem ser diferenciadas por tipos, hoje realizamos dois tipos de prova, Digital que são provas realizadas em nossos laboratórios de informatica, e as Presencias que são feitas em sala de aula.

Time: Notamos que você falou que 'hoje' vocês realizam essas provas, vocês pretendem inserir um novo tipo de prova?

Cliente: Sim, uma prova somente de Redação, que deve ser realizada nas fases posteriores ao processo, as fases de complementação de vagas.

Time: Então para esse primeiro momento não pretendem usar a prova de Redação?

Cliente: Não, isso é só para a 2º parte do processo.

Time: As provas podem ser realizadas ao mesmo tempo?

Cliente: Sim, porem em salas diferentes, para as provas digitais usamos bastante isso.

Time: Ok. Então vamos retomar para ver se o time entendeu o contesto, você precisa criar uma prova, definindo o período de inscrição e diferencia-las por um tipo que podem ser Digital e Presencial, e não precisamos nos preocupar se elas estarão no mesmo período, porem não podem usar as mesma salas correto? 

Cliente: Sim.

Time: Tem alguma coisa que diferencia as duas provas alem da escolha das salas?

Cliente: Sim, para quem faz prova digital eu posso definir se vai fazer a prova de redação ou não.

Time: Blz, e para quem faz prova digital, o sistema tem que restringir que as salas escolhidas sejam sempre os laboratórios?

Cliente: Não é necessário, pois as vezes temos que fazer alguns ajuste pois nem todos os laboratórios estarão disponíveis. 

Time: Ok, e tem mais algumas características sobre as salas que devemos levar em consideração? 

Cliente: Sim, precisamos diferenciar se elas vão ser usadas por deficientes físicos ou não, preciso colocar a capacidade máxima de candidatos em cada uma também.

Time: É preciso diferenciar por deficiência?

Cliente: Não, pois alocamos todos os deficientes na mesma sala, eles não são muitos por isso deixamos todos no mesmo ambiente, e assim conseguimos agilizar a logística também.

Time: Ok.

Cliente: Porem preciso que o candidato deficiente tenha uma descrição do que precisa para realizar a prova, pois assim agilizamos a logística. 

Time: Ok, e sobre as salas tem algo mais a ser dito?

Cliente: Sim, preciso imprimir a lista de porta, com todos os candidatos de cada sala, com nome, CPF, também tem que ter a lista de presença com o nome, CPF e local para assinatura do candidato.

Time: Ok, vamos retomar então: você precisa criar uma prova, definindo o período de inscrição e diferencia-las por um tipo que podem ser Digital e Presencial, e não precisamos nos preocupar se elas estarão no mesmo período, porem não podem usar as mesma salas, a diferença entre elas inicialmente é que para as provas digitais você poderá definir se vai ter redação ou não, as salas vão ser de dois tipos para quem possui uma deficiência e para quem não possui, para ambas as salas vamos gerar duas listas, uma de presença e outra de porta que a unica coisa que diferencia entre elas é o local para assinatura, os candidatos com deficiência devem conter a informação do que necessitam para realizar a prova, esta correto?

Cliente: Sim exatamente isso.

Portanto, em cima do dialogo mostrado vou apresentar os padrões GRASP, abaixo está um primeiro esboço do diagrama de classe, mas com o tempo esse diagrama deve mudar pois vamos trabalhar bastante ele até o fim desses post, vamos começar pelo Information Expert (Especialista da Informação).

Nome : Especialista da Informação (Expert)

Problema : Qual é o principio básico pelo qual atribuir responsabilidade a objetos?

Solução : Atribua responsabilidade a classe que tenha informação necessária para satisfazê-la.

Vantagens:

• Fácil manutenção;
• Facilita a criação dos teste unitários;
• Código Limpo;
• Reaproveitamento de funcionalidades;
• Mais fácil de refatorar;

Para um objeto possuir determinada responsabilidade ele necessita de informação, sobre si próprio, sobre os objetos que estão relacionados com ele, sobre o mundo que esta em torno e assim por diante. No domínio apresentado sabemos que a sala tem uma capacidade de candidatos e se ela for ultrapassada o candidato naturalmente deve ir para outra sala disponível, pois bem, quem deve ser o responsável por isso?

Como a prova possui a informação das salas que estão vinculadas ela vai possuir a responsabilidade de adicionar o candidato, porem quem possui a informação sobre capacidade e de quantos candidatos estão alocados é a sala, pois bem ela vai ter a responsabilidade de nos informar se ainda a vagas disponíveis, e por ultimo como a lista de candidatos esta em sala a prova deve adicionar o candidato nela, por isso teremos mais um método adicionar Candidato em Sala. Abaixo está o diagrama de sequencia e o novo diagrama de Classes.

Diagramas Classes Original Expandido:

Diagrama de Sequencia:

Diagrama de Classes:

Pois bem, acho que nesse primeiro post aprendemos bastante sobre o padrão Expert, que no meu ponto de vista é o mais importante, no decorrer dos próximos post vou apresentar um por um dos padrões GRASP, até a próxima.