Padrões GRASP

1. Creator

Além do padrão Creator nativo da Orientação a Objetos, onde as classes criam suas próprias instâncias, houve a aplicação do padrão Creator nos relacionamentos de composição do projeto, sendo eles entre:

• Tópico (Todo) e Avaliação (Parte): Uma avaliação deve necessariamente estar vinculada a um tópico, logo, o todo, no caso, o Tópico, deverá ser o responsável por disparar a criação da instância da parte (Avaliação).

• Tópico (Todo) e Resposta (Parte): A resposta é uma resposta a um tópico, logo não existe resposta se não existe um tópico, dessa forma, o todo, no caso, o Tópico, deverá ser o responsável por disparar a criação da instância da parte (Resposta).

• Escola (Todo) e Infraestrutura (Parte): Só existirá uma infraestrutura, se ela estiver vinculada à uma escola, logo o todo, a Escola, deverá ser responsável por disparar a criação da instância da parte (Infraestrutura).

• Escola (Todo) e Endereço (Parte): De forma semelhante ao tópico acima, um endereço só existirá se estiver vinculado à uma escola, logo, o todo (Escola), deverá ser responsável por disparar a criação da instância da parte (Endereço).

Seguem as imagens dos relacionamentos em que o padrão Creator foi aplicado no diagrama de classes:

2. Controller

O padrão Controller define quem deve lidar com os eventos do sistema. No Android as Activities e Fragments disparam estes eventos, entretanto, no projeto MeAjuda? quem realmente define o que deve ser feito quando os eventos são disparados são as Presenters. Desta forma, as Activities e Fragments apenas captam os eventos, enquanto as Presenters definem o que fazer com eles, logo, são nelas que o padrão Controller foi aplicado.

Além disso, pode-ser dizer que as Presenter também são um tipo Indireção, visto que funcionam como mediadoras entre a View e a Model.

Implementação no código: Classes do pacote Presenter

3. Invenção Pura

O padrão da Invenção Pura é utilizado para atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial que não represente um conceito do domínio do problema, apoiando a alta coesão, baixo acoplamento e reutilização de software. No projeto, o padrão foi aplicado através da criação de várias classes na camada DAO (Data Access Object). As classes desta camada aplicam este padrão pois:

• São altamente coesas, isto é, cada classe tem a responsabilidade única de comunicar os dados da sua entidade referente da aplicação para o banco de dados e vice-versa.
• São classes artificiais que não representam um conceito do domínio do problema.

Implementação no código: Classes do pacote DAO