325

I read in some posts about Spring MVC and Portlets that field injection is not recommended. As I understand it, field injection is when you inject a Bean with @Autowired like this:

@Component public class MyComponent { @Autowired private Cart cart; }

During my research I also read about constructor injection:

@Component public class MyComponent { private final Cart cart; @Autowired public MyComponent(Cart cart){ this.cart = cart; } }

What are the advantages and the disadvantages of both of these types of injections?

EDIT 1: As this question is marked as duplicate of this question i checked it. Cause there aren't any code examples neither in the question nor in the answers it's not clear to me if i'm correct with my guess which injection type i'm using.

Improve this question
2
  • 5
    If field-injection is as bad as you describe, why does Spring allow it? Field injection has its own benefits, in making the code more readable and less verbose. If you are disciplined enough in your coding, you can be sure things wouldn't break even if you use field injection. Commented Jun 27, 2018 at 22:23
  • 3
    @ashes Because it was a neat feature at the time, and the implications weren't entirely thought through. The same reason that Date(int,int,int) exists. Commented Sep 26, 2018 at 23:19

4 Answers 4

Reset to default
496

Injection types

There are three options for how dependencies can be injected into a bean:

  1. Through a constructor
  2. Through setters or other methods
  3. Through reflection, directly into fields

You are using option 3. That is what is happening when you use @Autowired directly on your field.

Injection guidelines

Edit: These 3 links mentioned here are for Spring 4.2., for newer version documentation as per 2023 (6.09) see list below

A general guideline, which is recommended by Spring (see the sections on Constructor-based DI or Setter-based DI) is the following:

  • For mandatory dependencies or when aiming for immutability, use constructor injection
  • For optional or changeable dependencies, use setter injection
  • Avoid field injection in most cases

Field injection drawbacks

The reasons why field injection is frowned upon are as follows:

  • You cannot create immutable objects, as you can with constructor injection
  • Your classes have tight coupling with your DI container and cannot be used outside of it
  • Your classes cannot be instantiated (for example in unit tests) without reflection. You need the DI container to instantiate them, which makes your tests more like integration tests
  • Your real dependencies are hidden from the outside and are not reflected in your interface (either constructors or methods)
  • It is really easy to have like ten dependencies. If you were using constructor injection, you would have a constructor with ten arguments, which would signal that something is fishy. But you can add injected fields using field injection indefinitely. Having too many dependencies is a red flag that the class usually does more than one thing, and that it may violate the Single Responsibility Principle.

Conclusion

Depending on your needs, you should primarily use constructor injection or some mix of constructor and setter injection. Field injection has many drawbacks and should be avoided. The only advantage of field injection is that it is more convenient to write, which does not outweigh all the cons.

Further reading

I wrote a blog article about why field injection is usually not recommended: Field Dependency Injection Considered Harmful.

Spring Documentation

Spring 4.2 (from original post)

Spring 6.0.9 (2023 Current Stable version)

Improve this answer
Sign up to request clarification or add additional context in comments.

15 Comments

It is general not good idea and not nice to tell the world "field injection should be avoided". Show pros and contras and let other to decide oneself ;) Many people have other experiences and own way of looking at things.
That may be the case here, but there are other cases where the community has come to a general consensus to discourage something. Take, for example, Hungarian Notation.
You give some good points as testability and dependency visibility but i am not agree with all. Constructor injection has no drawbacks? Having 5 or 6 fields to inject in class which performs real compositions of call may be desirable. I disagree also with you with immutability. Having final fields is not mandatory to have a class immutable. It is preferable. Which is very different.
I think you meant "For mandatory dependencies or when aiming for immutability"
I was referring to link at the beginning of the answer which links to the spring docs
|
97

This is one of the never-ending discussions in software development, but major influencers in the industry are getting more opinionated about the topic and started to suggest constructor injection as the better option.

Constructor injection

Pros:

  • Better testability. You do not need any mocking library or a Spring context in unit tests. You can create an object that you want to test with the new keyword. Such tests are always faster because they do not rely on the reflection mechanism. (This question was asked 30 minutes later. If the author had used constructor injection it would not have appeared).
  • Immutability. Once the dependencies are set they cannot be changed.
  • Safer code. After execution of a constructor your object is ready to use as you can validate anything that was passed as a parameter. The object can be either ready or not, there is no state in-between. With field injection you introduce an intermediate step when the object is fragile.
  • Cleaner expression of mandatory dependencies. Field injection is ambiguous in this matter.
  • Makes developers think about the design. dit wrote about a constructor with 8 parameters, which actually is the sign of a bad design and the God object anti-pattern. It does not matter whether a class has 8 dependencies in its constructor or in fields, it is always wrong. People are more reluctant to add more dependencies to a constructor than via fields. It works as a signal to your brain that you should stop for a while and think about your code structure.

Cons:

  • More code (but modern IDEs alleviate the pain).

Basically, the field injection is the opposite.

Improve this answer

4 Comments

testability, yes , It was a nightmare for me to mock the field injected beans. Once, I used the contsructor injection, I need not to do any unnecessary mocking
Can you voucher_wolves please give an example of constructor injection and its test.
If you want to new object in your testing, it can only be done using constructor injection stackoverflow.com/questions/62774713/… I normally use InjectMocks and Mocks. Is using new() in JUnit a good practice?
"It is always wrong" - I am skeptical of extreme absolute statements like that, especially after enough times of finding that the code becomes much more convoluted and ultimately never gets produced when you get too absolute and run into an edge case because you're trying to move heaven and earth to get the rule tight.
50

Matter of taste. It is your decision.

But I can explain, why I never use constructor injection.

  1. I don't want to implement a constructor for all my @Service, @Repository and @Controller beans. I mean, there are about 40-50 beans or more. Every time if I add a new field I would have to extend the constructor. No. I don't want it and I don't have to.

  2. What if your Bean (Service or Controller) requires a lot of other beans to be injected? A constructor with 4+ parameters is very ugly.

  3. If I'm using CDI, constructor does not concern me.

EDIT #1: Vojtech Ruzicka said:

class has too many dependencies and is probably violating single responsibility principle and should be refactored

Yes. Theory and reality. Here is en example: DashboardController mapped to single path *:8080/dashboard.

My DashboardController collects a lot of informations from other services to display them in a dashboard / system overview page. I need this single controller. So I have to secure only this one path (basic auth or user role filter).

EDIT #2: Since everyone is focused on the 8 parameters in the constructor... This was a real-world example - an customers legacy code. I've changed that. The same argumentation applies to me for 4+ parameters.

It's all about code injection, not instance construction.

Improve this answer

20 Comments

Very ugly constructor with 8 dependencies is actually awesome as it is a red flag that something is wrong, class has too many dependencies and is probably violating single responsibility principle and should be refactored. It is actually a good thing.
@VojtechRuzicka it is not nice for sure but sometimes you can not avoid it.
I'd say a rule of thumb of 3, let alone 40-50, dependencies for any class should be a sign that you need to refactor. There's no way a class with 40 dependencies is sticking to single responsibility principal or open/close principal.
@AminJ The rule is great, but reality is different. Company I'm working is over 20 years and we have a lot of legacy code. Refactoring is a good idea, but it cost money. Also I don't know why are are saying it but I didn't mean 40-50 dependencies, I mean 40-50 beans, components, modules...
@dit, your situation is clearly one in which technical debt is causing you to make sub-optimal choices. By your own words, you are in a situation where your decision making is significantly influenced by legacy code over 20 years old. When starting out in a new project, would you still recommend field injection, over constructor injection? Maybe you should put a caveat in your answer to indicate in which cases you would choose field injection.
|
4

One more comment - Vojtech Ruzicka stated that Spring injects beans in such three ways (the answer with the biggest numbers of points) :

  1. Through a constructor
  2. Through setters or other methods
  3. Through reflection, directly into fields

This answer is WRONG - because FOR EVERY KIND OF INJECTION SPRING USES REFLECTION! Use IDE, set breakpoint on setter / constructor, and check.

This can be a matter of taste but it can also be a matter of a CASE. @dieter provided an excellent case when field injection is better. If You're using field injection in integration tests that are setting up Spring context - the argument with testability of the class is also invalid - unless You want to write later on tests to Your integration tests ;)

Improve this answer

3 Comments

Could you please clarify on all three inject approaches use reflection? I set a breakpoint for constructor inject but did not spot anything reflection-like.
<init>:13, Bleh (com.wujq.cameldemo) newInstance0:-1, NativeConstructorAccessorImpl (sun.reflect) newInstance:62, NativeConstructorAccessorImpl (sun.reflect) newInstance:45, DelegatingConstructorAccessorImpl (sun.reflect) newInstance:423, Constructor (java.lang.reflect) This is callstack from constructor type injection bean - topn entries.
Please read the following article. Field injection is costlier than other 2 types as it relies on reflection API. baeldung.com/…

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.