Polimorfismo no Salesforce: Apex, campos polimórficos, TYPEOF e getSObjectType()

Vamos combinar uma coisa: polimorfismo é daqueles nomes que parecem saídos de uma aula de física quântica. Dá um arrepio, o pessoal trava e muita gente nem tenta entender direito.

Mas, ó, spoiler: a ideia central é até simples.

Pronto. Esse é o coração da coisa toda. Quando isso faz clique na sua cabeça, tanto programação quanto banco de dados ficam muito mais intuitivos.

Agora bora destrinchar isso de verdade. Confesso que, na primeira vez que ouvi essa palavra, só pensei: “poli o quê?”. Eu me assustei tanto que lembro até quem disse isso para mim e tentou explicar. Só começou a fazer sentido quando sentei e parei para estudar de verdade.

No Apex: o controle remoto universal

Imagine um controle remoto universal. Ele tem um botão vermelho para ligar.

Você aponta para a TV e aperta. A tela liga. Depois aponta para o aparelho de som e aperta o mesmo botão. O som liga, mas nenhuma tela acende.

O comando foi o mesmo. O botão foi o mesmo. O que mudou foi o aparelho que recebeu o sinal.

No Apex, a ideia é parecida. Uma variável do tipo mais geral pode receber uma instância de um tipo mais específico. Quando um método sobrescrito é executado, vale o comportamento do objeto concreto:

public class PolimorfismoDemo {
    public virtual class Animal {
        public virtual String emitirSom() {
            return 'Som genérico';
        }
    }

    public class Cachorro extends Animal {
        public override String emitirSom() {
            return 'Au au';
        }
    }

    public static void executar() {
        Animal animal = new Cachorro();
        System.debug(animal.emitirSom()); // Au au
    }
}

A variável é Animal, mas o objeto criado é Cachorro. Por isso, o método executado é a versão sobrescrita por Cachorro. A inteligência não está no botão. Está no aparelho que recebe o sinal.

No banco de dados: a porta USB

Aqui a mágica, ou a dor de cabeça, dependendo do seu nível, acontece nos dados.

Um lookup tradicional é como um cabo proprietário que só encaixa em um tipo de aparelho. Um campo polimórfico é mais parecido com uma porta USB: o campo é um só, mas pode apontar para registros de diferentes objetos permitidos.

Em vez de criar vários relacionamentos específicos, a plataforma usa uma referência capaz de se adaptar. Mas existe um detalhe vital: o campo guarda uma referência por registro. A flexibilidade está no tipo de objeto para o qual o ID aponta.

O tipo do campo também não muda. Se a referência aponta para uma Opportunity, ela não vira decimal por causa do campo Amount. O valor de WhatId continua sendo um ID. O que muda é o objeto relacionado.

WhoId, WhatId e OwnerId: a dupla e o primo que confundem todo mundo

Impossível falar de polimorfismo no Salesforce sem esbarrar nesses nomes.

• Who: “quem?”. Em atividades, representa a pessoa relacionada, normalmente Contact ou Lead.
• What: “o quê?”. Representa o contexto relacionado à atividade, como Account, Opportunity, Case ou outro objeto aceito naquele cenário.
• Owner: representa quem possui o registro. Dependendo do objeto, pode apontar para User ou Group. Uma Queue é representada na plataforma por um registro de Group, e nem todo objeto aceita propriedade por fila.

É uma boa regra de bolso para Task e Event. Só lembre que os tipos aceitos podem variar conforme o objeto, o recurso e a configuração da org.

Com ID ou sem ID na query? Faz diferença, sim

Essa distinção é sutil, mas importante. É a diferença entre receber a chave e navegar até os dados da casa.

Com o sufixo Id, como em WhoId, a consulta retorna o identificador do registro relacionado:

SELECT Id, WhoId, WhatId
FROM Task

Sem o sufixo, você usa o relacionamento para acessar campos do registro relacionado. Um campo compartilhado pelos tipos permitidos, como Name, pode ser consultado assim:

SELECT Id, Who.Name
FROM Task

E tem uma sacada que vale ouro: o campo Type.

SELECT Id, Who.Name
FROM Task
WHERE Who.Type = 'Lead'

Em vez de trazer vários registros para o Apex e filtrar na memória, você delega o filtro ao banco e recebe somente o conjunto necessário. Isso poupa recursos e ajuda a respeitar os limites da plataforma.

TYPEOF: o recepcionista inteligente

Quem nunca tentou buscar um campo específico pelo relacionamento polimórfico e recebeu um erro? O problema é estrutural. Opportunity tem Amount, mas Account não tem. Account tem Industry, mas isso não significa que todos os possíveis destinos de What tenham esse campo.

Aí entra o TYPEOF. Pense nele como um recepcionista inteligente. Quando chega uma Account, ele pede Industry. Quando chega uma Opportunity, pede Amount e StageName. Ele não faz a pergunta errada para o visitante errado.

SELECT TYPEOF What
    WHEN Opportunity THEN Amount, StageName
    WHEN Account THEN Industry
END
FROM Task

É quase como um switch dentro da consulta. Em muitos cenários, isso evita consultas separadas por tipo e deixa a intenção do código mais clara.

Aí você pode estar pensando: “Caraca, a Monique é muito experiente então”. Não. Estou estudando para ser. E é fazendo posts sobre o que estudo que eu aprendo cada vez mais e compartilho conhecimento com você.

E o getSObjectType()? Esse é para quem pensa em limites

Imagine uma integração fictícia na qual o Apex recebe uma coleção de IDs, mas não recebe o tipo dos registros. O impulso pode ser fazer SOQL só para descobrir a qual objeto cada ID pertence. Em processamento de volume, isso consome desnecessariamente o limite de consultas.

Com getSObjectType(), o Apex identifica o tipo correspondente ao ID sem executar SOQL:

Id recordId = '00Q000000000001AAA';
Schema.SObjectType recordType = recordId.getSObjectType();

if (recordType == Lead.SObjectType) {
    // Encaminha para a lógica de Lead
} else if (recordType == Contact.SObjectType) {
    // Encaminha para a lógica de Contact
}

A forma correta é chamar o método a partir de uma instância de Id, como recordId.getSObjectType(). O método não consulta os dados do registro e não consome uma query SOQL. Ele apenas devolve o token do tipo de SObject correspondente ao ID.

Resumão para colar no monitor

Reflexão para fechar este textão que eu achei que seria curto

Porque flexibilidade também traz complexidade. Relacionamentos mais restritos facilitam validação, manutenção, consultas e otimizações da plataforma. O melhor recurso depende da necessidade real do modelo de dados.

Polimorfismo é um bisturi, não uma marreta.

Agora abra o Query Editor, teste o TYPEOF em um ambiente seguro e coloque a mão na massa.

Todo dia um passo, todo passo conta.