Best Practices for Dependency Injection With Spring
Learn how to use Project Lombok when adopting dependency injection using the Spring Framework.
Join the DZone community and get the full member experience.
Join For Free 
In this post, I’m going to show you how to use Project Lombok for best practices in dependency injection with the Spring Framework.
The Spring Framework itself has a variety of different ways we can perform dependency injection. The flexibility of options is a strength of the Spring Framework. However, not all of the dependency injection options are considered best practices. Some are actually very poor.
You may also like: How Dependency Injection (DI) Works in Spring Java Application Development
Dependency Injection Examples
I’ve set up examples for us to review the different dependency injection options we have to work with.
Let’s use an example Spring Service. For our purposes, the service has one method that returns a string. We’ll take our ‘service’ and use Spring to inject it into some faux controllers. Keep in mind, we’re just exploring how we can do dependency injection with the Spring Framework.
Example Service
xxxxxxxxxx
public class MyService {
public String getHello(){
return "Hello";
}
}
Our field controller has one public property for the service. We can annotate this field, and Spring will inject an instance of the service.
Property Injection
Field Controller
xxxxxxxxxx
public class FieldController {
MyService myService;
public String saySomething(){
return myService.getHello();
}
}
This is just a public property and does not have a setter. Clearly, this is not a good practice. Nor is it recommended.
We can improve on this slightly, and make the access to the field private. The Spring Framework does allow you to autowire private fields. You do see people doing this. And Spring will perform some reflection magic to perform dependency injection.
Private Field Controller
xxxxxxxxxx
public class PrivateFieldController {
private MyService myService;
public String saySomething(){
return myService.getHello();
}
}
While better than just using a private field, testing becomes a headache. You either need to bring up the Spring Context or use some Spring utilities to perform dependency injection for testing. Not the end of the world, but generally annoying.
We can improve upon this by providing a setter for the private property. Getters and setters are generally considered best practices in object-oriented programming. It's trivial to instruct Spring to use the setter for dependency injection by annotating the setter method.
Method Injection
Setter Controller
xxxxxxxxxx
public class SetterController {
private MyService myService;
public void setMyService(MyService myService) {
this.myService = myService;
}
public String saySomething(){
return myService.getHello();
}
}
This is a clear improvement upon using a private field. Some will complain this is too much code to write. But in reality, tasks like this have been automated in modern IDEs since season one of South Park.
Constructor Injection
The next option is to use a constructor. This is the best method we have looked at so far. When using a constructor to set injected properties, you do not have to provide the autowire annotation. This is a nice feature, which saves us a bit of typing. Annotation of constructors for dependency injection has been optional since Spring Framework version 4.2.
Constructor Controller
xxxxxxxxxx
public class ConstructorController {
private MyService myService;
public ConstructorController(MyService myService) {
this.myService = myService;
}
public String saySomething(){
return myService.getHello();
}
}
Constructor-based dependency injection is certainly considered a best practice. There was a time I personally favored setter-based injection, but I have come around to constructor-based.
We can still improve our example. There are two main concerns right now. One, the type of our service is a concrete type. Dependency injection of a hard type is not considered a best practice.
The second problem is that the property we are injecting is not declared final. Thus, in theory, the class could modify the injected property after it was instantiated.
Dependency Injection Best Practices
Best practices for dependency injection is to utilize interfaces, constructors, and final properties.
I’ve set up a ‘best practice’ service interface and provided a service implementation – which is annotated with the Spring Service annotation.
Best Practice Service Interface
xxxxxxxxxx
public interface BpService {
String getHello();
}
Best Practice Service Implementation
xxxxxxxxxx
public class BpServiceImpl implements BpService {
public String getHello() {
return "The Best Hello!";
}
}
Using Project Lombok
Now, the secret sauce using Project Lombok for best practices in dependency injection is to:
- Declare a final property of the interface type
- Annotate the class using Project Lombok’s required args constructor
Now, Project Lombok will generate a constructor for all properties declared final. And Spring will automatically use the Lombok provided constructor to autowire the class.
Lombok Controller
public class BpFinalConstructorController {
private final BpService bpService;
public String saySomething(){
return bpService.getHello();
}
}
This is a real nice way of doing this. Your code stays very clean. When working with Spring, it’s not uncommon to need several autowired properties.
When you need to add another bean, simply declare a final property.
If you refactor, and no longer need a Spring managed dependency, just delete the final property.
You’re no longer maintaining setters or constructor code. Project Lombok alleviates this mundane task from you.
I’ve been using this technique for sometime now in my day-to-day coding. It’s definitely a timesaver. And leads to cleaner code. Gone are unused properties and unused constructor parameters. Refactoring is just a little less painful now!
Source code for this post is available here on GitHub.
Further Reading
Spring Core: Dependency Injection
How Dependency Injection (DI) Works in Spring Java Application Development
Published at DZone with permission of John Thompson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments