PHP 8.4 Property Hooks: O Fim dos Getters e Setters Tradicionais?

Apresentadora: E aí, pessoal, bem-vindos de volta ao Allur, o seu podcast semanal sobre o que há de mais quente no ecossistema de tecnologia, focado em PHP, Laravel, Go e desenvolvimento mobile. Eu sou a Juliana Santos e hoje o papo é de deixar qualquer desenvolvedor PHP com um sorriso de orelha a orelha. Apresentadora: Hoje eu recebo o Rafael Costa, desenvolvedor sênior e um entusiasta de longa data da comunidade PHP. O Rafael tem acompanhado de perto as discussões do "Internals" do PHP e já está testando essas novidades do 8.4 em alguns projetos experimentais. Rafael, seja muito bem-vindo ao Allur! É um prazer ter você aqui, cara. Convidado: Valeu, Juliana! O prazer é todo meu. É massa demais estar aqui no Allur pra falar desse assunto. Eu confesso que, quando vi a RFC de Property Hooks sendo aprovada, eu quase soltei um foguete, viu? Era uma das coisas que eu mais sentia falta no PHP comparado com linguagens como C# ou Swift. Apresentadora: Pois é, Rafael, a galera tá comentando muito sobre isso. Mas, pra gente começar do básico: o que diabos são esses Property Hooks? É tipo um "mágica" nova do PHP ou é algo mais estruturado? Convidado: Cara, não é mágica, é evolução mesmo. Em essência, o Property Hook permite que você defina a lógica de leitura — que é o `get` — e a lógica de escrita — o `set` — direto na declaração da propriedade da classe. Sabe aquela variável `public string $name`? Agora, logo abaixo dela, você abre chaves e escreve o que deve acontecer quando alguém tenta ler ou mudar esse valor. Tipo assim, você tira a lógica dos métodos isolados e coloca ela "colada" na propriedade. Apresentadora: Entendi. Então, em vez de eu criar um `setName` com um `trim` ou um `ucfirst` pra limpar o nome, eu faço isso direto ali na propriedade? Convidado: Exatamente! E o legal é que o PHP 8.4 introduziu uma variável "mágica", por assim dizer, que é o sinal de cifrão e um underline (`$_`). Quando você está no `set`, esse `$_` representa o valor que está chegando. Então, você faz `set { $this->name = trim($_); }` e pronto. Acabou aquele monte de método público que só servia pra higienizar dado. Apresentadora: Massa! Agora, uma dúvida que muita gente tem: isso não quebra o encapsulamento? Porque a gente aprendeu na faculdade que propriedade tem que ser `private` e o acesso tem que ser por método, né? Convidado: Essa é a melhor parte, Ju. Na verdade, isso *melhora* o encapsulamento. Porque hoje, a gente cria getters e setters só pra ter controle, mas a interface da classe fica poluída. Com os Property Hooks, a propriedade continua parecendo uma propriedade pública pro mundo exterior, mas o comportamento dela está totalmente sob seu controle internamente. É o melhor dos dois mundos: simplicidade no uso e rigor na implementação. Apresentadora: E me conta de um caso de uso real que você já testou. Onde isso brilha de verdade? Convidado: Cara, propriedades computadas são o "pulo do gato". Imagina uma classe `Retangulo`. Antigamente, ou você criava um método `getArea()`, ou você tinha que atualizar uma propriedade `$area` toda vez que mudava a largura ou a altura. Com o Property Hook, você cria uma propriedade `public float $area` e, no `get` dela, você simplesmente coloca `return $this->width * $this->height;`. Quem usa a classe só dá um `echo $rect->area`, mas o valor é calculado na hora. É muito elegante, né? Apresentadora: Nossa, com certeza! Fica muito mais intuitivo pra quem está consumindo a classe. E sobre validação? Dá pra jogar uns erros lá dentro também? Convidado: Com certeza! Dá pra colocar qualquer lógica. Se você tem uma propriedade `$idade`, no `set` você pode checar se o valor é menor que zero ou maior que 120 e já disparar uma `InvalidArgumentException` ali mesmo. O código fica muito mais "na cara", sabe? Você não precisa caçar no arquivo onde está a validação daquele campo, ela tá ali, junto da definição da variável. Apresentadora: Rafael, você trouxe um exemplo de como seria uma classe de Usuário no PHP 8.3 comparada com o 8.4. A diferença no número de linhas é gritante, né? Convidado: É bizarro, Ju. Num cenário real, uma classe que tinha, sei lá, 60 linhas só de boilerplate de getters, setters e validações simples, cai pra umas 20 linhas no PHP 8.4. E o mais importante: a legibilidade aumenta demais. Você bate o olho e entende as regras de negócio daquela entidade em segundos. É menos ruído, sabe? Apresentadora: Com certeza. Mas vem cá, nem tudo são flores. Tem algum momento em que você acha que *não* deve usar Property Hooks? Onde o método tradicional ainda ganha? Convidado: Ah, com certeza. A gente tem que tomar cuidado pra não querer "enfiar" toda a lógica do sistema dentro de um hook. Se a lógica de acesso for muito complexa, tipo, precisar consultar um banco de dados ou chamar uma API externa — o que já seria estranho pra um getter, mas enfim — é melhor usar um método explícito. Outra coisa são as "Fluent Interfaces", aqueles métodos que retornam `$this` pra você ir encadeando chamadas, tipo `$user->setName('Ju')->setEmail('[email protected]')`. Os hooks sempre retornam `void` no `set`, então eles não substituem esse padrão de encadeamento. Apresentadora: Boa observação! Então, se o meu projeto usa muito encadeamento de métodos, eu ainda vou precisar dos setters tradicionais em alguns lugares. Convidado: Exato. E tem a questão da performance e do debug também. Se você colocar lógica pesada num `get`, toda vez que acessar a propriedade, vai rodar aquilo. Pode acabar gerando um gargalo que você não percebe porque "parece" só um acesso a variável. Então, a regra de ouro é: lógica simples, formatação e validação? Vai de Hook. Lógica de negócio pesada? Fica no método. Apresentadora: Perfeito. E você acha que os frameworks, tipo o Laravel, vão adotar isso rápido? Consigo imaginar os Modelos do Eloquent ficando bem mais poderosos com isso. Convidado: Com certeza! O Taylor Otwell e a galera do core do Laravel já estão de olho. Imagina os "Accessors" e "Mutators" do Laravel, que hoje a gente faz com métodos `protected function...`, virando Property Hooks nativos? Vai ser animal. Vai facilitar muito o trabalho de quem cria bibliotecas e DTOs (Data Transfer Objects). Apresentadora: Rafael, pra gente fechar: qual dica você dá pra quem quer começar a se preparar pro PHP 8.4 e pros Property Hooks agora? Convidado: Cara, a primeira coisa é baixar o PHP 8.4 (já tem as versões RC saindo) e começar a brincar num ambiente controlado. Pega aquela classe de entidade que você odeia porque tem 500 linhas e tenta refatorar usando Hooks. Você vai ver como o código "respira" melhor. E claro, fiquem de olho na documentação oficial, porque tem alguns detalhes de herança e interfaces que são importantes entender. Apresentadora: Show de bola! Rafael, muito obrigada pela participação. Foi um papo muito esclarecedor e confesso que estou bem ansiosa pra começar a deletar uns getters e setters por aí! Convidado: Valeu, Juliana! Eu que agradeço o convite. O PHP tá mais vivo do que nunca e o 8.4 vai ser um divisor de águas. Até a próxima, pessoal! Apresentadora: É isso aí, pessoal! O PHP continua evoluindo e mostrando que produtividade e elegância podem, sim, andar juntas. Os Property Hooks não são apenas uma "perfumaria", eles são uma ferramenta real pra gente focar no que importa: a lógica de negócio, e não na infraestrutura do código.