C++ · Desktop
CadflowBankSystem — Sistema bancário em C++/MFC
Uma empresa propôs-me um desafio técnico: construir um sistema bancário de secretária em C++ nativo, sem frameworks. Este é o resultado.
Contexto
Resolvido individualmente em cerca de um mês. C++ com MFC, sobre Windows.
O problema
Contas, movimentos, transferências e consulta de saldos numa aplicação de secretária. Sem framework web, sem ORM, sem coletor de lixo: a gestão de memória, o estado da interface e a persistência dos dados passam todos a ser responsabilidade de quem escreve o código.
Decisões técnicas
Modelo de domínio separado da interface
As classes Account, Transaction e BankManager não sabem que existe uma janela. Toda a lógica bancária vive em código que não importa nada do MFC, e os diálogos limitam-se a recolher dados, chamar o modelo e mostrar o resultado. Em MFC o caminho fácil é escrever a lógica dentro do handler do botão, porque é onde os dados já estão. Funciona, e depois a mesma regra existe em três diálogos com três variações.
Persistência em ficheiro de texto
Os dados são guardados em texto simples. Foi rápido de escrever e deixa ver o conteúdo sem ferramentas, o que ajuda a depurar. O custo é que tudo o que se lê de volta tem de ser validado à mão, e qualquer erro de formato só aparece quando o programa já está a correr.
C++ nativo, com o que isso implica
Sem coletor de lixo, o tempo de vida de cada objeto é uma decisão consciente. Foi o projeto que me obrigou a perceber o que as linguagens com gestão automática de memória me tinham deixado ignorar.
O que correu mal
O MFC foi metade do problema. É uma biblioteca antiga, com convenções próprias, mapas de mensagens e ligações entre controlos e variáveis que não se parecem com nada do que eu tinha usado antes. Passei mais tempo a perceber como se faz do que a escrever a lógica em si.
A outra metade foi decidir o que cada classe devia conter. Quando se começa com Account, Transaction e BankManager numa folha em branco, cada operação pode viver em três sítios diferentes e os três parecem razoáveis à primeira. Escolher mal significa descobrir duas semanas depois que uma regra simples precisa de dados que ficaram do outro lado.
Refiz essa divisão mais do que uma vez, até ela deixar de me atrapalhar. Foi a primeira vez que percebi que desenhar classes é uma decisão sobre quem sabe o quê, e não sobre onde arrumar o código.
Resultado
Entregue, com resposta positiva da empresa.
O que faria diferente
Trocava o ficheiro de texto por SQLite. Guardar em texto foi rápido de escrever, mas obriga a validar à mão tudo o que se lê de volta, e um ficheiro corrompido só dá sinal quando já é tarde. Uma base de dados embebida resolvia isso sem acrescentar dependências que a aplicação não pudesse levar consigo.