Propriedades
get e set: lido como campo, mas roda código.
dataforge
blueprint Retangulo:
private _largura: Float := 1.0
private _altura: Float := 1.0
action setup(largura, altura):
self.largura := largura
self.altura := altura
get largura():
yield self._largura
set largura(v):
given v smaller_eq 0:
trigger "largura precisa ser positiva"
self._largura := v
get altura():
yield self._altura
set altura(v):
given v smaller_eq 0:
trigger "altura precisa ser positiva"
self._altura := v
// so leitura: nao ha 'set area'
get area():
yield self._largura * self._altura
get e_quadrado():
yield self._largura is self._alturaPor que importa#
Quem usa escreve r.area e r.largura := 4 — não r.obter_area(). A diferença aparece depois: você pode transformar um campo em propriedade sem quebrar quem já usava.
E o setter é o lugar da validação. Um campo público aceita qualquer coisa; uma propriedade decide o que é válido no momento da escrita, não depois.
Só leitura, só escrita#
Uma propriedade com get e sem set recusa a atribuição, dizendo o que falta:
text
erro[DF0301]: 'Retangulo.area' is read-only: it has a 'get' but no 'set'.
Add one: set area(valor): …O contrário também vale: set sem get é escrita apenas, e ler dá erro.
Herança#
dataforge
blueprint Base:
action setup():
self.n := 3
get dobro():
yield self.n * 2
blueprint Filho extends Base:
action setup():
self.n := 5
out (spawn Filho()).dobro // 10 — o get do pai lê o campo do filhoArmadilhas#
E cuidado com o custo: quem lê obj.x espera um custo de leitura. Se a conta é cara — bate no banco, percorre uma lista grande —, um método com nome é mais honesto.