Some Random Notes

Strategy via the Constructor

2 min read

Answer: Why Constructor Injection is the Gold Standard

Passing strategies (and dependencies in general) via the constructor is favored over field injection (@Autowired on private fields) or setter injection for several critical architectural reasons.

1. Immutability & Thread Safety

When you pass a strategy through the constructor, you can assign it to a final (in Java) or readonly (in C#/TypeScript) field.

  • The Benefit: It guarantees the strategy cannot be swapped or mutated at runtime. This makes your application highly predictable and naturally thread-safe, which is crucial in enterprise web applications handling concurrent requests.

2. Guaranteed Valid State (No Nulls)

An object should not be allowed to exist if it isn’t fully equipped to do its job.

  • The Benefit: Constructor injection acts as a strict contract. The Dependency Injection container (like Spring) must provide the strategy before the object is created. This completely eliminates the risk of a NullPointerException (unlike setter injection, where a setter might be forgotten).

3. Effortless Unit Testing

This is arguably the biggest day-to-day benefit for developers.

  • The Benefit: With field injection, testing requires reflection tools (like Mockito’s @InjectMocks) or spinning up the heavy Spring Context. With constructor injection, you test your class exactly like a normal object: new MyService(new MockStrategy()). Tests run faster and are less coupled to external libraries.

4. Framework Independence

Your core business logic shouldn’t be tied to the tool used to run it.

  • The Benefit: Your class remains a Plain Old Java Object (POJO). It doesn’t need framework-specific annotations scattered throughout its code. If you migrate from Spring Boot to Micronaut or Quarkus, your core domain classes require zero changes.

5. Built-in “Code Smell” Detection

Constructor injection naturally protects your architecture against bloat.

  • The Benefit: If a constructor requires 7, 8, or 10 dependencies, it becomes visually obvious that the class is doing too much. It serves as a glaring indicator that you are violating the Single Responsibility Principle (SRP) and need to refactor. Field injection easily hides this bloat.

Conclusion

While field injection requires less typing, Constructor Injection results in code that is safer, easier to test, framework-agnostic, and architecturally sound. This is why the Spring team officially recommends it as the primary injection method.

Backlinks