1. Introduction
There is uncertainty among Java developers on whether to initialize variables when they are declared or in a constructor.
In this tutorial, we’ll take a look at what happens when we initialize variables at their declaration or in a constructor. We’ll try to point out some differences and similarities between them if they exist.
2. Field Declaration Initialization
We need to know that the Java compiler takes out all field declaration initializations and moves them as code in the constructor in the order of their appearance in the class. From this, we can deduce there are no big differences between initializing variables at the declaration or in the constructor because, after compilation, they end up in the constructor anyways:
public class A {
private B b = new B();
}
3. Constructor Field Initialization
From our above code, after compilation, we end up with this constructor:
public class A {
private B b;
public A() {
this.b = new B();
}
}
Then does it matter where we initialize data?
After knowing what happens after compilation, not that much. It’s more of a preference that we tend to form based on our experiences.
4. Guidelines
We can look into some guidelines when deciding whether to initialize data at field declaration or in the constructor.
This is a dependency injection constructor:
public A(B b) {
this.b = b;
}
A recommended way of initializing variables is to use dependency injection. By using this way of initializing objects, we adhere to different principles.
4.1. Readability
For us to have better readability, it could be important to initialize the data either at field declaration or in the constructor, not both. Of course, we should take this as a guideline, not as a rule, since you can have both.
Having all the initialization in one place makes it easier to know where to look for the initialization code. This will make it easier for any future developer to look at initialization in only one place, not scattered around multiple places.
4.2. Single Responsibility
By using the dependency injection constructor, we remove the responsibility of instantiating the B object from the A class. Following the single responsibility principle is always preferable where possible.
This will also mean we will have lower coupling between classes, another awesome guideline to follow.
4.3. Testability
Using this constructor tends to have easier ways to test our code since we can easily mock our B object and then inject it into our A object with this constructor:
B b = mock(B.class);
A a = new A(b);
4.4. Maintainability
Having lower coupling classes also brings us better maintainability of the code. Thus, we’ll be able to modify the code easier.
5. Conclusion
In this article, we’ve seen that using either field declaration or constructor initialization is more of a preference, and some differences between them can be the design principles that we want to follow.
Using the constructor initialization and dependency injection can give us some advantages of design principles.
As always, the source code for the examples is available over on GitHub.
