El contenedor construye los beans y les suministra sus colaboradores, así que las clases declaran lo que necesitan en vez de construirlo. Se prefiere la inyección por constructor porque las dependencias son obligatorias y visibles, los campos pueden ser final y el objeto queda inmutable y completamente inicializado, la clase es testeable con un new normal y sin reflexión, y una dependencia circular falla ruidosamente al arrancar en vez de esconderse tras una inyección perezosa por campo.
Por qué lo preguntan los entrevistadores
Es una pregunta de diseño disfrazada de framework. El entrevistador quiere oír hablar de testeabilidad e inmutabilidad más que de la mecánica de las anotaciones, además de conciencia sobre los ámbitos de bean y la trampa del singleton con estado mutable en un bean compartido. Que sepas explicar cómo probarías la clase sin contexto de Spring les dice mucho sobre tus hábitos de pruebas unitarias.
Cómo estructurar tu respuesta
- Describe la inversión de control en una frase.
- Da las ventajas concretas de la inyección por constructor.
- Menciona los ámbitos y el peligro del estado en un singleton.
- Explica cómo esto le da forma a tus pruebas.
Ejemplo de respuesta
El contenedor es dueño de la creación de objetos, así que mi clase pide lo que necesita en su constructor y Spring lo resuelve e inyecta. Uso inyección por constructor porque hace obvio el contrato: si una clase recibe cinco colaboradores, eso queda visible en la firma en vez de escondido en cinco campos anotados, y normalmente me dice que la clase hace demasiado. Los campos pueden ser final, así que el objeto queda completamente construido y es seguro publicarlo entre hilos, y puedo instanciarlo en un test con argumentos de constructor normales y sin contexto de Spring, lo que mantiene rápidos los tests unitarios. Las dependencias circulares también salen a la luz al arrancar como un fallo en vez de taparse. Sobre el ámbito, los beans son singletons por defecto, así que los mantengo sin estado; un campo mutable en un servicio singleton es una condición de carrera esperando peticiones concurrentes. Cuando necesito estado por petición lo paso como parámetro de método en vez de tirar de un bean con ámbito de petición. La inyección por campo la evito activamente, ya que oculta dependencias y necesita reflexión para montarla en un test.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Cómo manejarías dos beans del mismo tipo?
- ¿Qué pasa cuando inyectas un bean prototype en un singleton?
- ¿Cómo pruebas un componente que depende de la petición actual?
Más preguntas para Desarrollador Java
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas