Sistema Hemocentro

TL;DR

Um sistema de banco de sangue feito em equipe de 3 na faculdade: o estoque por tipo sanguíneo é mantido pelo próprio banco de dados, com uma trigger no MySQL, e as regras de compatibilidade de doação ficam no modelo, em Java.

Contexto e problema

Projeto da disciplina de Programação Orientada a Objetos com JDBC na UMC, em 2026. O desafio era modelar o dia a dia de um hemocentro: cadastrar doadores, registrar doações, acompanhar o estoque de cada tipo sanguíneo e atender pacientes, mantendo os números do estoque sempre corretos.

O ponto delicado é a consistência: cada doação registrada muda o estoque. Se essa conta depender de cada tela lembrar de atualizar o estoque, um dia alguém esquece, e o número na tela deixa de corresponder ao sangue que existe de fato.

Meu papel

Trabalho em equipe de 3 pessoas. Fiquei responsável pela camada DAO e pelas triggers do MySQL que atualizam o estoque, nos módulos de Paciente, Doador, Doação e Estoque.

Restrições

JDBC puro, sem ORM: o objetivo da disciplina era entender o acesso a dados por baixo.
Orientação a objetos como critério de avaliação: modelos, responsabilidades e camadas bem separadas.
Prazo de disciplina e trabalho dividido entre três pessoas.

Decisões técnicas e trade-offs

Decisão	Alternativa	Por quê
Estoque atualizado por trigger no MySQL	Atualizar o estoque no Java depois de cada doação	A regra fica num lugar só. O estoque continua certo mesmo que outra parte do sistema grave uma doação; o `EstoqueDAO` só precisa ler.
Um DAO por entidade e uma `ConnectionFactory`	SQL espalhado pelas telas	Camadas separadas: as telas não conhecem SQL e a conexão é configurada num lugar só.
`PreparedStatement` em todas as consultas	Montar o SQL concatenando texto	Parâmetros tipados e proteção contra SQL injection.
Compatibilidade como regra no modelo (switch expression)	Uma tabela de compatibilidade no banco	As regras de doação são fixas, cabem num método legível e são fáceis de testar.

Arquitetura

Camadas

01Telas webcadastro, doação, estoque e compatibilidade
02ModelosDoador, Doação, Paciente, Estoque, Compatibilidade
03DAOs (JDBC)um por entidade, PreparedStatement
04MySQL 8trigger mantém o estoque por tipo

Destaques de implementação

O banco cuida do estoque

A evidência está no próprio código: o EstoqueDAO não tem método para inserir ou atualizar, só para consultar. Quem mantém a tabela ESTOQUE é a trigger disparada a cada doação.

src/DAO/EstoqueDAO.java (resumido)

public List<Estoque> consultarTodos() throws ClassNotFoundException, SQLException {
    Connection con = ConnectionFactory.getConnection();
    PreparedStatement comando = con.prepareStatement("select * from ESTOQUE");
    ResultSet rs = comando.executeQuery();
    // ...monta a lista de Estoque (tipo sanguíneo e quantidade)
}

Compatibilidade sanguínea legível

As regras de quem pode doar para quem viraram um único método, com switch expressions do Java.

src/Model/Compatibilidade.java (resumido)

return switch (tipoDoador) {
    case "O-"  -> true;                        // doador universal
    case "O+"  -> tipoPaciente.endsWith("+");  // todos Rh+
    case "A+"  -> tipoPaciente.equals("A+")  || tipoPaciente.equals("AB+");
    case "B+"  -> tipoPaciente.equals("B+")  || tipoPaciente.equals("AB+");
    case "AB+" -> tipoPaciente.equals("AB+");
    // ...e os tipos negativos
    default    -> false;
};

Resultado e impacto

Sistema entregue na disciplina, com os módulos de Paciente, Doador, Doação e Estoque e a tela de compatibilidade.
Na prática, foi onde consolidei JDBC, o padrão DAO e a separação em camadas, a base do que estudo hoje com Spring Data JPA.