Ir para o conteúdo

GRASPs e GoFs: App

Histórico de revisões

Data Versão Descrição Autor(es)
15/05/2019 1.0 Introdução sobre os GoF's criacionais Guilherme Aguiar
19/05/2019 2.0 Padrões Singleton do projeto Guilherme Aguiar
20/05/2019 3.0 Grasp Especialista Guilherme Aguiar
25/06/2019 3.1 Adicionando GoFs e GRASPs Geovana Ramos
26/06/2019 3.2 Adicionando imagens Gabriela Medeiros
27/06/2019 3.3 Substituindo imagens por códigos fonte Geovana Ramos
27/06/2019 3.4 Adicionando polimorfismo Geovana Ramos

GOFs utilizados

1. Singleton
2. Builder
3. Composite
4. Adapter
5. Observer

GRASPs utilizados

1. Controller
2. Polimorfismo

Singleton

O objetivo do Singleton é permitir apenas uma instanciação de classe e fornecer um método para recuperá-la. Esse padrão de projeto foi implementado nas camadas dos controladores (controller) no contexto da arquitetura MVC. Os controllers são instanciados e utilizados pontualmente de maneira similar, em chamadas assíncronas e em fragments, que manipulam a interface.

Subjects Controller

Controller responsável por retornar a lista de todas matérias da API. Singleton - SubjectsController

Classes Controller

Controller responsável por retornar a lista de todas turmas da API. Singleton - ClassesFragment

TimeTables Controller

Singleton - ClassesFragment

Builder

O padrão Builder não foi implementado manualmente, porém o Android faz uso desse para padrão a geração de janelas de alerta. Ele disponibiliza o builder para que a janela de alerta seja criada facilmente. Ele está sendo utilizado para avisar ao usuário que o app necessita de sua permissão para salvar a grade em seu celular. Builder

Composite

Grande parte dos elementos gráficos do Android herdam de uma classe chamada "View". Considerando que cada tela do aplicativo possui layouts compostos por outros objetos gráficos, como botões e listas, e que ambos são "views", podemos observar um composite em tal relação. Composite Por exemplo, na tabela de fluxos, um TableLayout irá armazenar várias TableRows e uma TableRow irá armazenar vários objetos TextView, ImageViews etc. Ou seja, uma table tem várias linhas e cada linha pode ter diversos tipos de componentes gráficos. Composite

Adapter

Como parte da arquitetura Android, os adapters são responsáveis por modificar os elementos gráficos de uma lista. Uma lista básica pode receber exclusivamente strings únicas, porém o adapter pode modificá-la para receber outros tipos e combinação de dados e views, como: múltiplas strings, imagens, checkbox, botões, etc. Na utilização abaixo, o adapter modifica a lista para poder aceitar uma checkbox, um spinner e múltipas strings. Esses elementos serão preenchidos com os dados de cada turma de uma matéria. Adapter

Observer

O padrão observer foi implementado por meio dos listeners. Os listeners são métodos que aguardam a interação do usuário com algum elemento da tela (botões, checkbox, spiners, entre outros) para executar os comandos já determinados. No caso abaixo, essa função retorna o listener de cada matéria listada. Ao clicar em uma delas, a função é chamada. A mesma salva os dados da matéria e envia para a nova tela que será apresentada ao usuário logo em seguida. Observer

Controller

Os controllers do app são responsáveis por guardar as funções mais pesadas e de interação com a api. Dessa forma, a manutenção e execução de testes é facilitada.

Polimorfismo

Todos os controllers herdam de uma classe base controller que possui um método base para todos os módulos do projeto (ver imagens no tópico Singleton)