Índice

1. La pregunta que no esperaba fallar

En una entrevista para un puesto de Programador Backend Java me hicieron una de las preguntas más básicas que existen: "¿Cuáles son los principios de la Programación Orientada a Objetos?".

No pude responderla de forma fluida. No porque no los aplique, sino porque en ese momento no los pude nominar con precisión. Sé usar una interfaz. Sé cuándo tiene sentido una clase abstracta. Sé por qué un campo tiene que ser private. Pero en el momento de la pregunta, el nombre de cada principio no me salió limpio.

Lo que sí pude hacer fue explicar con lenguaje técnico cómo trabajo: qué decisiones tomo al modelar un dominio, cómo estructuro dependencias, qué criterio uso para definir contratos. La conversación fue buena. Pero el tropiezo con algo tan elemental me quedó dando vueltas.

2. Cuándo los conceptos dejan de tener nombre

Hay un punto en el que ciertos conceptos se integran al punto de desaparecer como concepto. Uno no piensa "voy a aplicar encapsulamiento" antes de declarar un campo como private. Lo hace y ya. De la misma forma que no piensa "voy a usar polimorfismo" antes de programar contra una interfaz en Spring. Es una decisión que se toma sola, porque es la correcta en ese contexto.

Eso no es un problema cuando estás escribiendo código. Es un problema cuando alguien te pide que expliques lo que hacés. Y en una entrevista técnica, eso pasa seguido.

No es que el concepto no esté, es que el camino de vuelta al nombre se volvió más largo. Con experiencia, uno construye criterio antes de construir vocabulario técnico formal. Y a veces eso se nota.

3. Los pilares aplicados, no recitados

Encapsulamiento. Cada vez que un campo es private y el acceso está controlado por métodos de la propia clase. No es solo convención de Java: es la decisión de que el estado interno no debería ser modificable desde afuera sin pasar por la lógica que lo gestiona.

Herencia. La reutilización de comportamiento base a través de extends. En proyectos reales con Spring, aparece más en el framework que en el dominio propio.

Polimorfismo. Programar contra una interfaz o clase abstracta y dejar que el tipo concreto se resuelva en tiempo de ejecución. Es la base de la inyección de dependencias en Spring y de patrones como Strategy. Es lo que hace que un servicio no tenga que saber exactamente con qué implementación trabaja.

Abstracción. Definir contratos sin exponer implementación. En Java, interface y abstract class son los dos mecanismos, y la elección entre uno y otro tiene implicancias de diseño que no son triviales y que vale la pena conocer bien.

Ninguno de estos cuatro requiere ser recitado para ser aplicado correctamente. Pero tampoco sirve solo saber aplicarlos si no se puede hablar de ellos.

4. Por qué igual importa poder explicarlos

Hay una postura que dice: si lo aplicás bien, no importa si lo podés definir. Tiene lógica en producción, no tanto en una entrevista ni en un equipo.

En una revisión de código, el vocabulario compartido importa. Decirle a un colega "esto rompe el encapsulamiento de la clase" es más preciso y útil que describir el problema en términos vagos. Sin el vocabulario, la conversación técnica pierde filo.

En una entrevista, explicar un concepto es una señal de que entendés sus límites, no solo su mecánica. Saber cuándo no usar herencia es más valioso que saber cómo se escribe extends. Y para transmitir eso, necesitás poder hablar del concepto, no solo demostrarlo.

Eso no invalida la experiencia práctica. Pero sí significa que volver a los fundamentos de vez en cuando tiene sentido, no para reaprender lo que ya está internalizado, sino para asegurarse de que lo que uno hace bien lo puede también explicar bien.

5. Conclusión

Que un concepto esté tan integrado que ya no requiera esfuerzo consciente no es un déficit. Es lo que pasa naturalmente cuando se trabaja con algo durante mucho tiempo. El problema aparece cuando ese nivel de automatización se cruza con un contexto donde la explicación explícita es parte de lo que se evalúa.

La brecha entre lo que uno hace bien y lo que puede explicar bien no se cierra con más práctica. Se cierra verbalizando: escribiendo sobre el tema, revisando código con criterio explícito, o simplemente tomándose un momento para articular lo que uno hace de forma automática.