Orientação a objetos

Blueprints, records, traits — e quando usar cada um.

DataForge tem três formas de agrupar dados e comportamento. A escolha entre elas é a decisão de modelagem mais frequente, e a que mais custa quando erra.

A pergunta que decide entre os dois primeiros: dois desses, com os mesmos valores, são a mesma coisa? Dois pontos (1, 2) são — record. Duas contas com o mesmo saldo não são — blueprint.

O que o 4.1 trouxe#

Até o 4.0 um blueprint tinha métodos, herança e traits. Faltava tudo o que separa a API pública do detalhe interno:

blueprint Conta:
    private saldo: Float := 0.0
    protected titular: String := ""

    action setup(titular):
        self.titular := titular

    action depositar(valor):
        given valor smaller_eq 0:
            trigger "deposito precisa ser positivo"
        self.saldo += valor
        yield self.saldo

    action sacar(valor):
        given valor bigger self.saldo:
            trigger "saldo insuficiente"
        self.saldo -= valor
        yield self.saldo

    get extrato():
        yield $"{self.titular}: {self.saldo}"

• Campos declarados com tipo e padrão — campos e visibilidade
• `private` e `protected` que valem de verdade, não por convenção
• Propriedades get/set — propriedades
• Métodos estáticos — estáticos
• Sobrecarga de operadores — operadores
• Abstratos e contratos conferidos na declaração — abstratos
• `final` para impedir sobrescrita

Por onde começar#

Se você já usa blueprint, comece por campos e visibilidade — é o que muda mais o código do dia a dia. Se está modelando algo novo, modelagem discute as escolhas antes da sintaxe.

Os dez exercícios do módulo 21 percorrem tudo isso na ordem, cada um rodando e com .md explicando o conceito.