It goes without saying that every object needs to be created before it can be used. It does not matter whether we are talking about a domain, frameworks, libraries or any other type of the classes. When your code is an Object-Oriented, those classes are only definitions of the objects. You cannot use objects before they are created.
When we are talking about object’s initialization, we often need to think about dependencies. How will you inject them? Will you use the constructor or setter?
Let me help you make a right decision.
Once upon a time..
… there was a need to handle some event. To do so, we had to, first of all, retrieve necessary data from the Repository and then pass it to the Trigger which was responsible for triggering an appropriate action based on given data.
During implementation we created the following class:
public class SomeHandler {
public SomeHandler(Repository repository, Trigger trigger) {
// some code
}
public void handle(SomeEvent event) {
// some code
}
}Things always change, though. Our customer told us that from time to time they would need to store some information retrieved from the repository before an appropriate action is taken. They need this data for statistical purposes and further analysis.
After the change this is what our class looked like:
public class SomeHandler {
public SomeHandler(Repository repository, Trigger trigger) {
// some code
}
public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker) {
// some code
}
public void handle(SomeEvent event) {
// some code
}
}Another month goes by and another requirement comes from our client. They want to have a possibility of enabling notification just after triggering an event. This is necessary for them in case of some emergency issues. They want to have higher transparency.
Ok, now we’ve got two things that may be enabled:
public class SomeHandler {
public SomeHandler(Repository repository, Trigger trigger) {
// some code
}
public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker) {
// some code
}
public SomeHandler(Repository repository, Trigger trigger, Notifier notifier) {
// some code
}
public SomeHandler(Repository repository, Trigger trigger, SnapshotTaker snapshotTaker, Notifier notifier) {
// some code
}
public void handle(SomeEvent event) {
// some code
}
}The code looks good, doesn’t it? Ok, that was a rhetorical question. Let’s do something about it.
Constructor or not?
In the example above we’ve got the class with four constructors. Why so many? Because of the changing needs of our customer. And this is perfectly fine. An application should satisfy client’s needs.
Where is the problem? The problem is with the design of the class.
Why do we have so many constructors? Because some dependencies are optional, their presence depends on external conditions.
Do we need so many constructors?
Before we answer this question, it is good to ask different one: what’s the purpose of the constructor?
We should create an object in a valid state. We should not allow to create an instance if there is something more that hasto be done to make an object usable. That’s why all required dependencies should be placed in a constructor.
On the other hand, we should place in the constructor only the required dependencies. Constructor is not a place for anything optional. If something is optional, this means we don’t need it to create a valid object.
If we would like to use other dependencies that are nice to have we should inject them in different way. And this is where setters come into play. We are not forced to invoke setter method. We may have a need, but this is not required. You should use setters when dependency is an option.
So, do we need so many constructors? Let the code be the answer:
public class SomeHandler {
public SomeHandler(Repository repository, Trigger trigger) {
// some code
}
public void setSnapshotTaker(SnapshotTaker snapshotTaker) {
// some code
}
public void setNotifier(Notifier notifier) {
// some code
}
public void handle(SomeEvent event) {
// some code
}
}Less code and more descriptive. From the first moment you know what is required and what just might be used.
But wait! Setter?!
I don’t like setters. Why? Because those methods in some way break encapsulation.
But what can we use instead of setters? What can be used instead in a given example?
Well, we will not avoid those methods. Or to be more precise – we need their functionality. There is a need to let the customer enable the functionality. In a given example mutators needs to stay because they’re needed. However, we can always make the code better. More domain-related. How? We just need to show this relation with the domain:
public class SomeHandler {
public SomeHandler(Repository repository, Trigger trigger) {
// some code
}
public void enable(SnapshotTaker snapshotTaker) {
// some code
}
public void enable(Notifier notifier) {
// some code
}
public void handle(SomeEvent event) {
// some code
}
}I wrote that I don’t like setters, because their break encapsulation, but this is not only about the method’s functionality itself. Another problem with using methods like setX is that even their names are implementation-oriented. Sometimes setter functionality is necessary. However, remember to name a method in a way that will show domain connotation.
Too many options
Sometimes too many options also pose a problem. It can be a sign that you’re violating Single Responsibility Principle.
If there are too many options it might mean that there are too many responsibilities and it is worth re-thinking your current solution.
Be very careful whenever adding another optional part into the code of the class. Maybe this class is doing too much?
Word at the end
Hopefully you find the article useful.
You should know now that you ought to place only required dependencies in your constructors . Any optional dependencies require other well-named methods.
What’s next?
Let’s go and create some object:)
| Reference: | Constructor or setter? from our JCG partner Sebastian Malaca at the Let’s talk about Java blog. |
I think, a better way to do it, would be to extract an interface, and create decorators with Notifier and another with SnapshotTaker. If You make something optional, it means that you probably will need to check if it is set, and than take some action which will make that code a little bit harder to test.
Yes, it can be solved it this way, but the purpose of the article was to show and explain when we should use the constructor and setter methods come into play.
What about looking at this from another angle?
What you could be saying with optional dependencies is that there are /aspects/ to an object. One could think of introducing aspect oriented technology for certain cases.
Hold your horses! I’m not trying to say that aspects are a silver bullet, but it can be a consideration. Each decision needs to be evaluated.