การฉีดผ่านคอนสตรักเตอร์เทียบกับฟิลด์

Spring can inject dependencies three ways: through the constructor, into fields, or via setters. They all work, but they are not equal in quality.

The Spring team and community strongly recommend constructor injection. This lesson explains why.

Field injection places @Autowired directly on a field. It looks compact, but hides the dependency and complicates testing.

Constructor injection declares dependencies as constructor parameters. Spring supplies them when building the bean. Fields can be final, signaling true immutability.

Since Spring 4.3, if a bean has a single constructor, @Autowired is optional. This keeps constructor-injected classes clean and annotation-light.

Constructor injection lets every dependency be final. The object is fully initialized once and never changes its collaborators, which prevents accidental reassignment and aids thread safety.

Field injection cannot use final, so the object can exist in a partially built state.

A constructor makes dependencies explicit, so unit tests can build the object directly with mocks — no Spring context, no reflection.

A bloated constructor is a visible code smell. If a class needs eight collaborators, the long parameter list screams that it does too much. Field injection hides this and lets god-classes grow unnoticed.

Constructor injection surfaces circular dependencies at startup with a clear error, because two beans cannot both be constructed first. Field injection can mask the cycle until runtime, leading to subtle bugs.

A startup failure is the right time to discover and fix a design cycle.

Setter injection suits genuinely optional dependencies that can change after construction. It is rarely needed; prefer constructor injection for required collaborators.

If constructors feel verbose, Lombok’s @RequiredArgsConstructor generates one from all final fields, giving constructor injection’s benefits with minimal code.

Constructor injection wins on every axis:

• Immutable, fully initialized objects
• Trivial unit testing without a container
• Cycles and over-dependency become visible
• No reflection-only access for tests

Test your understanding of injection styles.

Prefer constructor injection.

• Enables final, immutable dependencies
• Single constructor needs no @Autowired
• Unit-testable without the Spring context
• Exposes circular dependencies and over-large classes
• Use setters only for optional, mutable collaborators