Design de Classes de Domínio→ OkSeparação em Camadas→ OkTransição de Estados→ OkPrincípios SOLID→ Ok
- Geral
- Boa iniciativa na automação nos scripts em bash
.sh. Parabéns! - Faltou indicar no readme como foi feito o design e arquitetura do projeto
- Corrigir link onde há
requisitos de participação na hackatonno readme - Boa usabilidade para autenticação do usuário
- Ao invés de sempre verificar null procure ler sobre Optional
- Bom projeto, estrutura e design arquitetural. Parabéns!
- Boa iniciativa na automação nos scripts em bash
- Main
- A inicialização de dados foi uma boa para melhor experiência e usabilidade
- Boa estrutura e injeção das camadas do repositorio ao controller e menus
- O código que verifica
--adminpoderia ficar estruturado em método ou classe à parte
- View
- Evite ter código comentado, exemplo criarCompanion2
- Textos fixos de mensagens, avisos ou perguntas deslocar para constantes em interfaces ou enums
- Lógica por switch de menus pode ser melhorada com padrão command + strategy
- Boa tática para uma única instância do scanner por Menu.entrada
- Veja que o código das views seriam mais simples sem texto fixo, ifs e switchs cases
- Código em QuestaoView.mostrarQuestaoFechada ficou misturado. Implementar aleatório a parte
- Veja que saber se a questao errou ou acertou fica no model e regras no service
- Para criar questões pode ser usado o padrão Abstract Factory mas isto não compete fazer na view
- Controller
- Importante considerar interfaces dos controladores. Parabéns!
- Imagina que seu controlador agora seja via HTTP. Ainda assim a interface e demais camadas grandes impactos
- Em ValidadorDeEntradas.validarOpcoes cria um novo scanner
- Service
- Vários meetodos vazios ou sem implementações que retornam nulos
- Um pouco confuso inicialmente a usabilidade de retornar adicionarTema e adicionarExercicio
- Mas entendi que o status é um código de sucesso da açnao do usuário, mas tudo bem
- Simplifica o nome dos metodos. Veja que todos em portugues e alguns nao. Exemplo, getList para listar
- Repository
- Como melhoria futura usar um Map ao inves de duas listas em RepositorioCompanion para companion e flags
- Faltou um atualizar visto que ajustes podem ocorrer para melhor experiência do usuário
- Fez bom uso do generics na interface para diversos repositorios
- Model
- Em ZConteudoPOO, os textos poderiam ficar em interfaces ou variáveis estática
- Isto torna mais fluido a leitura do código e local central para ajustes textuais
- Imagina que no futuro você queira ter o programa em várias linguagens, como faria?
- Boa usabilidade para diversos robos em Avatar. Poderia ficar melhor em interface
- Bom design entre questões abertas e fechadas se beneficiando de princípios solid
- Poderia ter implementado comparable para ordenação padrão
- Veja que comportamentos de verificação do user poderia estar na própria Classe
- Classes de domínio tem apenas get/set. Procure ler sobre modelo anêmico
- Bacana a evolução das classes de domínio para incluir Multa, Devolução e demais
- Boa iniciativa em descrever os fluxos por diagrama de classe e sequência
- Foi próativa ao investir tempo extra com ferramentas e no readme
- Evite sempre que possivel deixar código comentado no projeto.
- Implementou controller mas não o chamou no Main
- Menus e validação de entrada em branco
- Método pagarMulta poderia retornar PagamentoMulta e não sete objetos como null
- Boa evolução ao implementar métodos emprestar e devolver. Cabe reuso sobre validação.
- Não entendi arquivos .txt misturados com classes java
- Em BibliotecaRepositorioListImpl muito código comentado
- Boa desenvolvura para implementar novos comportamentos reusáveis em BibliotecaServiceImpl
- BibliotecaServiceVirtual poderia ter ao menos um método comportamento