O Projeto Final Começa — Arquitetando um Mini Banco de Dados em Memória

Chegamos à Fase 9, o fechamento. Nos 38 artigos anteriores, você aprendeu os conceitos do C++ moderno um a um, e em cada aula eu insisti que "cada artigo é o curso em miniatura" — mostrando as peças trabalhando juntas em pequena escala. Agora vem a prova real: construir, do zero, uma aplicação de verdade que integre tudo. Escolhi um mini banco de dados em memória — uma ferramenta que armazena registros, consulta-os, filtra e ordena, como um SQLite minúsculo que vive na RAM. É um projeto ideal porque exercita naturalmente RAII, ponteiros inteligentes, classes, STL, templates, exceções e testes, todos num sistema coeso. Este primeiro artigo não escreve o motor ainda: ele arquiteta. Vamos decidir o que construir, como as partes se encaixam, e montar o esqueleto CMake. Projetar antes de codificar é, em si, uma das lições mais profissionais do curso.

O que vamos construir

Nosso banco de dados será simples mas real. Ele terá tabelas, cada uma com colunas tipadas e linhas de dados. Você poderá inserir registros, consultá-los com filtros ("todos com idade maior que 30"), ordená-los e removê-los. Um valor de célula poderá ser um inteiro, um número real ou um texto — um dado poliforme, que já aponta para o std::variant da Fase 6. Em uso, ele se pareceria com isto (a API que vamos projetar para construir depois):

// Visão do que queremos que funcione ao fim do capstone (ainda não implementado):
Tabela usuarios{{"nome", Tipo::Texto}, {"idade", Tipo::Inteiro}};

usuarios.inserir({{"nome", "Ana"}, {"idade", 30}});
usuarios.inserir({{"nome", "Bruno"}, {"idade", 25}});

// Consulta: todos com idade >= 28, ordenados por nome.
auto resultado = usuarios
    .filtrar([](const Linha& l) { return l.get_int("idade") >= 28; })
    .ordenar_por("nome");

for (const auto& linha : resultado)
    std::cout << linha.get_texto("nome") << '\n';

Note quanta coisa do curso está latente aí: Tabela é uma classe (Fase 3); filtrar recebe uma lambda (Fase 5); o encadeamento .filtrar(...).ordenar_por(...) usa a interface fluente com *this (Fase 3); os valores poliformes pedem variant (Fase 6); e por baixo tudo será containers da STL (Fase 4) com gestão automática de memória (Fase 2). Não vamos construir tudo isso hoje — vamos planejar como.

Arquitetura: as peças e suas responsabilidades

Bom software se divide em componentes com responsabilidades claras. Antes de escrever uma linha de lógica, definimos as peças do nosso banco e o que cada uma faz — o princípio de "funções e classes focadas" do artigo A Sabedoria Codificada — Core Guidelines e Código Limpo em C++, agora em escala de módulos:

O primeiro componente é o Valor (Value): representa uma única célula, que pode conter um inteiro, um real ou um texto. Ele encapsulará um std::variant e oferecerá acesso seguro e tipado. É a peça mais fundamental, e a construiremos no artigo A Primeira Pedra — Uma Célula Poliforme com std::variant.

O segundo é a Linha (Row): um registro, isto é, uma coleção de valores indexados por nome de coluna. Internamente será um mapa de coluna→valor.

O terceiro é a Tabela (Table): o coração do sistema, que possui as linhas, conhece o esquema (nomes e tipos das colunas), e oferece as operações de inserir, remover e consultar. Ela aplicará RAII possuindo suas linhas via containers da STL, sem gestão manual de memória. Construiremos a Tabela no artigo A Segunda Pedra — Linhas e Tabelas com RAII e STL.

O quarto é o motor de consultas: os métodos filtrar, ordenar_por e afins, que operam sobre as linhas usando os algoritmos da STL e lambdas, devolvendo novos conjuntos de resultados. Esse motor, com seus templates e interface fluente, é o artigo A Terceira Pedra — Um Motor de Consultas com Templates e Lambdas.

E o quinto, transversal, é o tratamento de erros: o que acontece quando você pede uma coluna que não existe, ou um tipo errado. Usaremos std::optional/std::expected e exceções conforme o caso, no artigo A Quarta Pedra — Tratamento de Erros Coerente com std::expected. Essa separação de responsabilidades — cada peça com um trabalho claro — é o que torna o sistema compreensível e testável.

O esqueleto CMake

Vamos materializar a arquitetura na estrutura do projeto, aplicando o CMake do artigo Do Comando Único ao Projeto Real — Construindo com CMake. Organizamos o código em uma biblioteca (minidb) com as peças do banco, um executável de demonstração, e um alvo de testes com Catch2:

# CMakeLists.txt — esqueleto do projeto minidb
cmake_minimum_required(VERSION 3.16)
project(MiniDB LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# A biblioteca com a lógica do banco (arquivos que criaremos nos próximos artigos).
add_library(minidb
    src/value.cpp
    src/table.cpp
)
target_include_directories(minidb PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include)

# Executável de demonstração que usa a biblioteca.
add_executable(demo src/main.cpp)
target_link_libraries(demo PRIVATE minidb)

# Testes com Catch2 (buscado automaticamente).
include(FetchContent)
FetchContent_Declare(Catch2
    GIT_REPOSITORY https://github.com/catchorg/Catch2.git
    GIT_TAG v3.5.0)
FetchContent_MakeAvailable(Catch2)

add_executable(testes tests/test_minidb.cpp)
target_link_libraries(testes PRIVATE minidb Catch2::Catch2WithMain)
enable_testing()
add_test(NAME suite COMMAND testes)

A estrutura de pastas correspondente separa interfaces (include/), implementações (src/) e testes (tests/) — a organização profissional que discutimos. Um cabeçalho inicial declara os tipos que vamos preencher:

// include/minidb/tipos.h — os tipos fundamentais que o projeto usará
#pragma once
#include <string>

namespace minidb {

// Os tipos que uma coluna pode ter. Um enum forte (enum class) evita conversões acidentais.
enum class Tipo {
    Inteiro,
    Real,
    Texto
};

}  // namespace minidb

Usamos um namespace minidb (Fase 1) para agrupar tudo e um enum class (uma enumeração forte, que não converte implicitamente para int) para os tipos de coluna. O projeto agora tem esqueleto, arquitetura e um caminho claro.

A honestidade sobre projetar antes de codificar

Prometo a franqueza de sempre, e ela vale muito aqui. Passar um artigo inteiro planejando sem escrever lógica pode parecer improdutivo para quem tem pressa de codificar. É o oposto: decidir a arquitetura antes — quais são as peças, quem é responsável por quê, como se conectam — é o que evita o retrabalho caótico de construir sem rumo. Dito isso, há um equilíbrio honesto: planejar demais, antecipando cada detalhe de um sistema que ainda não existe, também é armadilha (a paralisia por análise), e projetos reais evoluem à medida que você os constrói. A postura madura é planejar o suficiente para ter direção clara — as peças principais e suas fronteiras —, e refinar os detalhes conforme codifica, permitindo que a arquitetura se ajuste ao que você aprende no caminho. Nosso plano de cinco componentes é esse "suficiente": firme o bastante para guiar, flexível o bastante para evoluir.

Projetar antes de codificar tem medida: o suficiente para saber quem possui o quê e quais são as fronteiras entre as peças, não tanto que se antecipem detalhes que só o código revela. Definir posse logo no início é o que evita a refatoração mais cara — decidir depois que a tabela possui as linhas, e não o contrário, costuma significar mexer em tudo. O projeto final não traz conceito novo: ele cobra os que já apareceram, juntos e no mesmo lugar.

Fontes e leituras recomendadas

• Bjarne Stroustrup, A Tour of C++ (3ª ed.), capítulos finais sobre design de software: princípios de decomposição em componentes.
• cppreference.com/w/cpp/language/enum: a referência sobre enum class (enumerações fortes) que usamos para os tipos de coluna.
• ISO C++ Core Guidelines, seção "I" (Interfaces) e "C" (Classes): as diretrizes sobre projetar componentes com responsabilidades e fronteiras claras.
• John Ousterhout, A Philosophy of Software Design: um livro moderno e conciso sobre decomposição de sistemas e gestão de complexidade, altamente aplicável aqui.
• cmake.org/cmake/help/latest/module/FetchContent.html: a documentação do FetchContent, usado para trazer o Catch2 ao projeto.

Exercícios

Exercício 1

Desenhe (em texto ou diagrama) as cinco peças do nosso banco de dados e as relações entre elas: quem possui quem, quem usa quem. Por exemplo, a Tabela possui Linhas; a Linha possui Valores.

Exercício 2

Explique por que usamos enum class Tipo (enumeração forte) em vez de um enum simples ou de constantes inteiras para representar os tipos de coluna. Que erro o enum class previne?

Exercício 3

Crie a estrutura de pastas do projeto (include/minidb/, src/, tests/) e o CMakeLists.txt do esqueleto, com arquivos-fonte vazios (apenas com os includes). Confirme que cmake -S . -B build configura sem erro.

projeto/
├── CMakeLists.txt
├── include/minidb/tipos.h
├── src/value.cpp        (vazio, só #include)
├── src/table.cpp        (vazio, só #include)
├── src/main.cpp         (int main(){return 0;})
└── tests/test_minidb.cpp (só #include do Catch2)

Exercício 4

Para cada uma das cinco peças da arquitetura, cite qual(is) fase(s) do curso ela mais exercita e por quê. Por exemplo: o Valor exercita a Fase 6 (variant) e a Fase 3 (encapsulamento).

Exercício 5

Discuta o trade-off entre "planejar tudo antes" e "codificar e ajustar". Descreva uma situação em que planejar demais seria prejudicial ao nosso projeto, e uma em que planejar de menos causaria retrabalho.