Variables y Declaración

Cada vez que creaste un campo personalizado seguiste el mismo ritual: elegir el tipo, ponerle nombre y decidir qué valor lleva. Declarar una variable en Apex es exactamente ese ritual, escrito en una línea.

La nutria: El paralelo de Admin

La primera vez que creé un campo, en Setup → Object Manager → Fields & Relationships → New, me sorprendió que la primera pantalla me obligara a elegir el tipo de dato. No puedes crear un campo «que ya veremos qué guarda». Apex es igual de estricto, y por la misma razón: el tipo es lo que le permite a la plataforma protegerte de guardar «mañana» en un campo de importe.

Las cuatro partes de una declaración

Una declaración completa tiene el tipo, el nombre, el signo igual y el valor. Y termina en punto y coma, que en Apex significa «esta instrucción se ha acabado».

// Declaración con valor inicial
Integer maxDiscount = 20;

// Declarar ahora, asignar después
String accountName;
accountName = 'Acme Corp';

// Reasignar: la caja es la misma, el contenido cambia
maxDiscount = 25;

El tipo es una promesa

Cuando escribes Integer delante de un nombre, le estás prometiendo a la plataforma que ahí solo habrá números enteros. Si más adelante intentas meter texto, el código ni siquiera llega a ejecutarse: falla al compilar, igual que Salesforce te impide guardar «N/A» en un campo Number.

Integer contactCount = 12;
contactCount = 'doce';   // ❌ no compila: 'doce' no es un Integer

Cómo se nombran las variables

En Apex la convención es camelCase: la primera palabra en minúscula y cada palabra siguiente con inicial mayúscula. Y el nombre se elige como se elige la etiqueta de un campo: pensando en quien lo leerá dentro de seis meses, que probablemente serás tú.

Variables que no cambian

Si un valor no debe cambiar nunca (un porcentaje fijo, un nombre de estado), se declara con final. Es el equivalente a un campo de solo lectura: intentar reasignarlo es un error de compilación, no una sorpresa en ejecución.

final Integer MAX_RETRIES = 3;
MAX_RETRIES = 5;   // ❌ no compila: es final

Cómo vamos a trabajar: un solo caso, troceado

Los talleres de este módulo no son diez ejercicios sueltos: son un mismo encargo real, partido en diez trozos. Es exactamente lo que hace un desarrollador cuando sale de una reunión con Ventas: nadie escribe de una sentada el requisito entero, se desglosa en tareas y se empieza por la primera que ya se puede resolver.

La nutria: El encargo de Ventas, tal cual lo dijeron

Vengo de la reunión con Ventas y esto es lo que pidieron, tal cual: «Para la campaña de renovaciones de primavera queremos una ficha por oportunidad que nos diga: de qué cuenta es y con el nombre bien escrito, cuánto vale con impuestos y si necesita aprobación, cuándo se firmó y cuántos días faltan para la renovación, en qué región cae el cliente (y si no la sabemos, que ponga algo), qué cuota tiene esa región, y todo listo para mostrarlo en pantalla». A mí también me asustó la primera vez. Entero, todavía no lo puedes escribir: te faltan ocho sub-lecciones. Pero el primer trozo sí, y lo hacemos juntos.

Cada taller a partir de aquí empieza donde acabó el anterior: el código de partida ya trae resuelto lo que construiste, y encima se añade el trozo nuevo que la sub-lección de ese día te acaba de enseñar. Al llegar al checkpoint no montarás nada desde cero: solo verás el problema grande entero por primera vez, y te darás cuenta de que ya lo habías resuelto por partes.