Refatoração SOLID - Olimpíadas de Questões

Este repositório contém a refatoração do sistema legado de Olimpíadas, aplicando os princípios SOLID sem alterar o comportamento funcional e sem utilizar frameworks externos.

Explicação das Principais Mudanças

O código original consistia em uma classe "God Object" (App.java) que era responsável por armazenar dados (listas estáticas), ler inputs do usuário, formatar dados de saída (tabuleiro de xadrez) e executar regras de negócio.

A principal mudança foi a divisão do sistema em camadas lógicas:

• Domain: Classes de modelo de negócios.
• Repository: Abstrações e implementações em memória para armazenamento de dados.
• UI: Classes responsáveis pela interface com o usuário (leitura do terminal e impressão).
• Service: Classes que contêm as regras de negócio puras.
• Menu: Utilização do padrão Command para gerenciar as opções do sistema.

Onde cada princípio do SOLID foi aplicado

• S - Single Responsibility Principle (SRP): Aplicado ao remover todas as responsabilidades conflitantes da classe App. Foi criada a classe ConsoleUI para lidar exclusivamente com System.in/out e AvaliacaoService exclusivamente para calcular as notas. A formatação do FEN do tabuleiro também foi separada da lógica de negócios.

• O - Open/Closed Principle (OCP): Aplicado na estrutura do Menu Principal através da interface AcaoMenu. Agora, se precisarmos adicionar uma nova opção ao menu (ex: "Deletar Participante"), basta criar uma nova classe que implementa AcaoMenu e registrá-la na App.java, sem precisar modificar o loop principal ou um switch-case gigante. A classe está aberta para extensão, mas fechada para modificação.

• L - Liskov Substitution Principle (LSP): Aplicado no uso das coleções do menu (AcaoMenu). O loop na classe App confia cegamente que o método .executar() de qualquer subtipo funcionará corretamente. Além disso, as variáveis que instanciam os repositórios usam a interface Repositorio<T>, podendo ser substituídas por implementações futuras em banco de dados de forma transparente.

• I - Interface Segregation Principle (ISP): Aplicado na criação da interface Repositorio<T>. Em vez de criar uma interface gigante chamada BancoDeDados contendo métodos para todas as entidades (ex: salvarParticipante(), salvarProva()), criamos uma interface genérica e focada que obriga as classes a implementarem apenas as operações relativas ao seu próprio escopo.

• D - Dependency Inversion Principle (DIP): Aplicado na injeção de dependências. As classes de Ação do Menu (como CadastrarParticipanteAcao) não dependem das listas estáticas originais nem instanciam seus próprios bancos de dados. Elas dependem da interface Repositorio e recebem as instâncias concretas via construtor na inicialização da aplicação (App.java).