poo-avaliacao-fernando-lopes.md

POOtathon POOmpetition POOdyssey

• https://github.com/plasmus777/Loja-apps/
• https://github.com/plasmus777/projetos-ada/tree/main/Projetos-AdaTech/src/com/github/plasmus777/biblioteca

Avaliação dos Requisitos

• Design de Classes de Domínio → Ok
• Separação em Camadas → Ok
• Transição de Estados → Ok
• Princípios SOLID → Ok

Avaliação do Projeto

• Geral
  • Ao invés de sempre verificar null procure ler sobre Optional
  • Imprimir no console é papel da view e não das outras camadas
  • Utilize tratamentos de exceções não checadas em runtime
  • Documente as interfaces
  • Procure usar menos condições estruturando em padrões de projeto, melhor design
  • Use mais os comportamento das classes de domínio para checar e realizar ações
  • Fez um bom uso no design por enums e estruturas de controle e navegação
  • Implementou uso do comparable para ordenação nativa nas classes de domínio
  • Bom design sobre mecanismo simples para autenticação de usuário
  • Ótima iniciativa de impl ortogonal com InputHelper
• Views
  • ApplicationView no metodo show() aplicar padrão strategy com HashMap
  • A idéia é não usar mais fluxos condicionais ou switch com menos código
  • Poderia separar métodos para listar e outros para coletar
  • Evite códigos comentados como em AuthView
  • Uma evolução para menos linhas com println é criar arquivo txt template
  • Com template você aplica parâmetros para sobrepor igualmente faz em relatórios
  • Métodos em UserView bem elaborados mas pode reusar e quebrar em métodos menores
  • Classe View poderia ter mais métodos para reuso
  • Deixei opcional uso dos controllers mas poderia ter realizado uso para melhor design
• Main
  • Bom design no uso do userService e applicationService com application e publisher
  • Scanner deveria ser instanciado pelo controller e view atraves de um static factory
  • Eficiente inicialização application com mainView.show();
• Service
  • Muitas chamadas ao application1.getPublisher().getAuthToken(). Simplifique!
  • Muitos else e if em vários metodos e procure documentar as interfaces
  • Método listAll() com comportamentos da view em imprimir.
  • Veja que comportamentos de verificação do user poderia estar na própria Classe
  • Procure ler sobre modelo anêmico
  • Ou seja, as classes de domínio devem ter comportamento e saber verificar seu estado
• Repository
  • ApplicationDatabase no metodo update() não deveria imprimir que é papel da view
  • Boa separação de bases do application e user
• Model
  • Implementou metodo equals mas há casos com possível nullpointer

Avaliação Desafio 01

• Readme razoável mas ok o qual descreveu as atividades bem resumidas
• Boa exemplificação no fluxo do emprestar e devolver
• Evite chamadas aninhadas em uma mesma linha, exemplos linhas 43 a 52
• Isto torna complexo o código de entender além de difícil achar erros se houver
• Ao invés disto poderia chamar oconsultar antes e atribuir a uma variável
• Fluxo de validação do emprestar e devolver passível de reuso. Avalie!
• Boa implementação com validações do método reservar
• BibliotecaServiceVirtualImpl sem comportamento
• Faltou chamar o repository para atualizar dados do item ao emprestar, devolver e reservar
• E o retorno apontar para os próximos métodos e comportamentos, por exemplo:

   ItemCatalogo item = bibliotecaFisica.consultar("re").getFirst();
   bibliotecaFisica.emprestar(item, "Ronaldo");