Spring: Why do we autowire the interface and not the implemented class?

Spring: Why do we autowire the interface and not the implemented class? 🌱

When working with the Spring framework, you may have encountered code where the interface is autowired instead of the implemented class. This may seem confusing at first, but fear not! In this blog post, we will address common issues and explain why autowiring the interface is the preferred approach. Let's dive in! 💪

How does Spring know which polymorphic type to use? 🤔

One of the main benefits of using an interface is the ability to have multiple implementations. When you autowire an interface, Spring gets to choose which implementation to use based on the configuration. It does this through a process called dependency injection.

In our example code, you can see that there are two implementations of the IA interface: B and C. By using the @Qualifier annotation, we can specify which implementation we want Spring to inject. In the MyRunner class, we have annotated the IA dependency with @Qualifier("b"), telling Spring to use the B implementation.

But what if we don't use @Qualifier? In that case, Spring will try its best to match the interface to an implementation based on the configuration. If there is only one implementation of the interface, Spring will correctly inject it. However, if there are multiple implementations, Spring will throw an exception, indicating an ambiguous injection. In such cases, using @Qualifier becomes necessary to disambiguate the injection.

Do I need @Qualifier or @Resource? 🤷‍♂️

The @Qualifier annotation is often used to specify the name of the bean we want to inject. In our example, we've used @Qualifier("b") to tell Spring to use the B implementation. However, there is an alternative approach using the @Resource annotation.

The @Resource annotation, without any parameters, can also be used to autowire an interface. It performs a similar function to @Qualifier, but instead of specifying the name of the bean, it uses the variable name to resolve the dependency. In our example, if we replace @Qualifier("b") with @Resource, Spring will look for a bean with the same name as the variable worker (case insensitive) and inject it.

So, whether you use @Qualifier or @Resource depends on your preference and coding style. Both annotations achieve the same result: injecting the desired implementation of an interface.

Why do we autowire the interface and not the implemented class? 🤔

The primary reason for autowiring the interface instead of the implemented class is to promote loose coupling.

By coding to an interface, you create a contract that decouples the implementation details from the code that uses it. This allows for flexibility and easy switching of implementations without affecting the consuming code. This is particularly useful when you have multiple implementations that can be configured based on the specific requirements of your application.

Let's say you decide to introduce a new implementation of the IA interface called D which has some additional functionality. By simply creating the D class and configuring it in Spring, you can easily switch from using B to D by just changing the configuration. This promotes modularity and maintainability in your codebase.

Additionally, coding to an interface makes your code more testable. You can easily create mock implementations for testing purposes, allowing you to isolate and test specific components of your codebase without relying on the actual implementation.

Wrapping Up and Taking Action! 🎉

In this blog post, we have explained why it is preferred to autowire the interface instead of the implemented class in Spring. We've gone over Spring's ability to handle polymorphism, the usage of @Qualifier and @Resource, and the advantages of loose coupling and testability.

Now it's your turn! Start applying these concepts in your Spring projects and see the benefits for yourself. Let us know in the comments section if you have any questions or share your experiences with autowiring interfaces in Spring.

And remember, keep coding the Spring way – flexible, testable, and modular! 💻🌼