Programação orientada a modelos: o gerador precisa saber o que não pode tocar

Dave Clemmer apresenta, no Stack Overflow Blog, uma proposta de programação orientada a modelos baseada em sua experiência com a linguagem e IDE Mo+.[16] Nesse contexto, modelo significa uma representação estruturada do domínio ou sistema, não um modelo de linguagem de IA.[16] O texto é um ensaio que mistura experiência implementada e possibilidades de pesquisa, não o lançamento de uma plataforma nova pronta para adoção.[16]

O princípio aproveitável para engenharia é separar requisitos, transformação e código personalizado. Gerar uma aplicação uma vez é uma demonstração. Gerá-la novamente sem apagar decisões humanas é o problema operacional.

O que muda para quem desenvolve

A proposta separa a estrutura, que define tipos de nós e atributos, dos dados que preenchem essa organização.[16] Clemmer destaca uma forma desacoplada de desenvolvimento em que o modelo descreve requisitos e pode orientar vários componentes sem determinar todo o desenho da implementação.[16]

Isso sugere uma fronteira útil para projetos atuais: descreva explicitamente entidades, validações e contratos, mas não obrigue todas as decisões de arquitetura a caber no gerador. O código manual precisa continuar tendo um lugar reconhecido no processo.

O ensaio propõe separar arquivos gerados e manuais, oferecer pontos de personalização e atualizar ou remover somente arquivos realmente administrados pelo gerador.[16] Minha leitura é que essa responsabilidade deve ser verificável. Um nome de pasta ou um comentário no início do arquivo ajuda, mas não substitui a definição de propriedade e os critérios de alteração.

Como aplicar

Comece com um modelo pequeno de entidades e gere apenas artefatos repetitivos, como DTOs ou documentação de contratos. Deixe regras de negócio em arquivos manuais. Registre a versão do modelo, a versão do gerador e a lista exata dos arquivos administrados.

Defina como detectar personalizações num arquivo gerado. Se houver mudança manual inesperada, prefira interromper e apresentar um conflito a sobrescrever silenciosamente. Remoções também precisam de escopo: um artefato fora do inventário não deve ser apagado por parecer antigo.

Um experimento verificável tem três etapas. Primeiro, gere duas vezes sem alterar entradas e confira se há diferenças. Depois, mude um atributo e verifique quais arquivos foram afetados. Por fim, acrescente uma personalização permitida e confirme que ela sobrevive à nova geração.

Inclua ainda o caso de retirar uma entidade. Observe se o gerador remove somente os arquivos que administra e se relata dependências manuais que exigem revisão. Esse teste exercita justamente o limite que uma demonstração inicial costuma esconder.

Se o modelo for importado de um banco ou de outro sistema, estabeleça precedência entre dados importados e ajustes locais. O ensaio ressalta que alterações manuais precisam sobreviver a importações futuras.[16] A política deve produzir um conflito explícito quando não houver reconciliação segura.

Cuidados e limites

Gramática dinâmica, filtros de efeitos colaterais e uso direto como linguagem de aplicação aparecem entre as possibilidades discutidas, com questões ainda abertas.[16] Paralelismo amplo é apresentado como possibilidade derivada de estado imutável, não como recurso que o autor diga ter implementado.[16]

O Mo+ continua disponível com fontes e instalador, mas sua última oferta como complemento do Visual Studio foi em 2014.[16] Isso não demonstra manutenção recente nem justifica adoção sem avaliação.

A disciplina pode ser aplicada com ferramentas atuais sem reproduzir toda a proposta. O trade-off é manter modelo e transformações como novas dependências do projeto. O ganho só existe se a regeneração reduzir inconsistência sem transformar personalizações em vítimas do próximo comando.

Fonte

[16] Fonte: Stack Overflow Blog | Publicação: 09/10/2026 às 11:59:04