Perfecto.
Y qué pasaría si tuviéramos otra clase concreta que implemente la interfaz y servicio aparte de la que
ya tenemos que implemente método operación?
De otra forma, por ejemplo, vámonos al package service y podríamos crear esta clase o bien.
Otra forma es click derecho en mi servicio Coppi y sobre el package click derecho pegar.
Feist Y le cambiamos el nombre, por ejemplo, mi servicio complejo, por poner un nombre, otra implementación
vamos a abrir.
Acá, en vez de mi servicio simple, vamos a cambiar el nombre componente, le colocamos complejo,
perfecto, ejecutando un proceso importante, complicado.
Guardamos, vamos a mi servicio y acá colocamos proceso importante, simple para diferencia y guardamos.
Entonces tenemos dos clases concretas que implementan la misma interfaz.
Sin embargo, en el controlador estamos inyectando por la interfaz de servicio, pero tenemos dos implementaciones.
Cuál va a inyectar?
Queda completamente ambiguo.
Spring no va a saber si inyectar mi servicio o mi servicio complejo, pero no importa.
Ejecutemos la aplicación y veamos el error que nos da como sean pre click derecho ranas.
Y acá está el error.
El controlador Index requiere un único Pint, pero hay dos implementaciones contra mi servicio y mi
servicio complejos.
Si tenemos dos candidatos posible para la misma interfaz, entonces como solución tenemos dos caminos
y en esta clase vamos a ver uno que sería marcando la clase concreta con primary o primary en la que
queremos que sea la por defecto.
Por ejemplo, si quiero que sea mi servicio complejo, la por defecto simplemente anotamos con primary
importamos.
Bueno, pues debajo de componer o arria de component da lo mismo el orden.
Guardamos y volvemos a levantar.
Bien, y ahora no da ningún error.
Si nos vamos al navegador ejecutando un proceso importante, complicado.
Perfecto.
Inyectó justo el que queríamos.
Y esto es bien potente, bien poderoso, ya que nos permite desacoplar completamente la implementación
concreta de las clases que están usando estos componentes de servicio en este caso.
Cualquier cambio.
Si queremos hacer un switch entre una clase concreta y otra, simplemente cambiamos el primary.
Por ejemplo, voy a cortar acá de una clase a otra.
Ahora quiero que mi servicio sea el primary, sea el por defecto.
Me voy a mi servicio.
Voy a notar y guardamos las dos clases.
Esperen a que se actualice.
Y ahora si actualizamos navegador debería decir simple, perfecto, ejecutando un proceso importante,
simple.
Entonces, para finalizar la anotación, Primary permite seleccionar el candidato que queremos inyectar
por defecto en nuestras clases, ya sea controlador o cualquier otra clase que utilice este componente
sin tener que estar cambiando y modificando la clase que lo utilizan, cambiando por ejemplo, el tipo
de un tipo concreto a otro.
No usamos la interfaz siempre y en las implementaciones concreta de los componentes indicamos cuál es
la principal la primaria en este caso.
Bien, por ahora nada más.
Y la próxima clase vamos a ver otra forma utilizando los calificadores o cualificar hasta la próxima.