- Projeto realizado durante a fase 5 - App World da graduação FIAP;
- Trata-se de um aplicativo para cadastro de contatos.
Padrões de design (Design Patterns) são aplicados para uma melhor organização de projetos, assim facilitando a manutenção e compreensão de partes da aplicação.
O design pattern Model-View-Controller (Modelo-Visualização-Controle) tem como propósito separar as camadas da aplicação, aonde:
- Model → Representa a estrutura dos dados da regra de negócio da aplicação, assim centralizamos a estrutura das tabelas do banco de dados e das classes que as representam;
- View → Representa a interface da aplicação, renderizando os dados contidos nas estruturas da camada Model;
- Controller → Realiza a integração entre as camadas de Model e de View, acessando o banco de dados e capturando dados inseridos pelo usuário.
Aplicamos o MVC separando as responsabilidades das classes, aonde cada arquivo representa uma camada do MVC:
- Model → Contato.kt;
- View → MainActivity.kt;
- Controller → ContatoRepository.kt.
O design pattern Data Transfer Object (Objeto Transferidor de dados) tem como propósito fornecer métodos para acesso ao banco de dados, configurando quais métodos poderão ser executados para transferência de dados para o banco.
Aplicamos o DTO na interface ContatoDao.kt
que, por meio das anotações, fornece os métodos a serem implementados para realizarmos o CRUD (operações CREATE, READ, UPDATE e DELETE) nas tabelas do banco de dados. A classe
ContatoDb possui o método .contatoDao() que
nos retorna uma instância da interface ContatoDao, isso é possível pois a biblioteca Room Database usada no projeto realiza o proxy dessa interface, instanciando-a e retornando essa instância.
O design pattern State Hoisting (Elevação de estado) tem como propósito a divisão de obrigações dos componentes da aplicação, aonde um componente pai fornece a lógica da aplicação para os componentes filhos. Esses componentes filhos ficam encarregados de apenas renderizar o conteúdo recebido do componente pai, assim centralizando a lógica da aplicação.
Aplicamos o State Hoisting no arquivo MainActivity.kt,
aonde o componente pai
ContatosScreen
armazena as funções e as passa para os componentes filho
ContatoForm e
ContatoList
que as recebem como argumentos.
O design pattern Singleton (Coisa única) tem como propósito haver apenas uma única instância de uma classe que é usada e acessada por todos os componentes da aplicação.
Aplicamos o Singleton na classe ContatoDb
no método .getDatabase()
que retorna uma instância única da classe ContatoDb para que a conexão com o banco de dados fique centralizada,
isso é feito utilizando o bloco companion block do Kotlin que permite a criação de códigos estáticos, e o modificador lateinit na propriedade instance que permite
a inicialização tardia de classes.
- Celso Furtado (instrutor);
- Bruno Henrique;
- Por enquanto nenhuma validação para a entrada de dados foi aplicada ao projeto;
- Texto autoral, redigido por Bruno Henrique;
- Caso encontre bugs ou tenha sugestões, abra uma issue ou entre em contato.