Injection styles: constructor vs setter vs field

Constructor injection — the dependency is a constructor parameter

The dependency is declared as a parameter of the constructor, and the class stores it in a final/readonly field. Because the object cannot be built without supplying it, a required dependency is guaranteed present the moment the object exists.

class OrderService {
  constructor(private readonly sender: MessageSender) {}   // required, immutable
  placeOrder(c: string) { this.sender.send(c, "Confirmed"); }
}
new OrderService(new EmailSender());   // can't build it without a sender

This buys you four things at once. (1) A required dependency is guaranteed — there is no way to construct a half-built object. (2) The field can be final/readonly, so the dependency is immutable and can't be swapped out from under you. (3) The dependency is visible in the public API — anyone reading the constructor signature sees exactly what this class needs. (4) You can build it in a plain unit test with new OrderService(fakeSender) — no framework, no reflection, no container.

Setter (property) injection — a setX() called after construction

Here the object is constructed first, then the dependency is handed in through a setter or writable property afterward.

class OrderService {
  private sender?: MessageSender;
  setSender(s: MessageSender) { this.sender = s; }   // set AFTER construction
  placeOrder(c: string) { this.sender?.send(c, "Confirmed"); }
}
const svc = new OrderService();   // ⚠️ valid object, but sender is undefined here
svc.setSender(new EmailSender()); // ...until you remember to call this

The strength of setter injection is the same as its weakness: the dependency is optional and reconfigurable. That's perfect when a dependency genuinely is optional — a cache you may or may not attach, a logger that defaults to no-op. But for a required dependency it's a trap: between new and setSender(...) the object exists in a half-built state where calling placeOrder() blows up or silently does nothing. The dependency is no longer guaranteed, the field can't be final, and it's only partly visible in the API — you have to know to look for the setter.

Field injection — a framework sets a private field directly

The dependency is declared as a private field with a framework annotation, and the framework uses reflection to set it directly — no constructor parameter, no setter. In Java this is the @Autowired field.

class OrderService {
    @Autowired                       // framework reaches in via reflection
    private MessageSender sender;    // can't be final; hidden from the API
    void placeOrder(String c) { sender.send(c, "Confirmed"); }
}
// new OrderService() leaves sender = null unless the framework wires it.

Field injection looks the cleanest — no boilerplate at all. But it's the one most teams discourage, for concrete reasons. The dependency is hidden — nothing in the public API tells you the class needs a MessageSender. The field can't be `final`, so it's mutable and the object can briefly exist with a null dependency. And worst for daily work: you can't test it with a plain `new` — new OrderService() leaves the field null, so you must spin up the framework or use reflection to inject a fake. A required dependency hidden behind reflection is exactly the thing constructor injection makes safe.

The scorecard

Line the three up against the properties that actually matter and the pattern is obvious. Constructor injection is the only style that wins every row; setter injection is half-and-half (its 'looseness' is a feature only for optional deps); field injection loses the rows you care about most.

Pick the style by what the dependency is

The choice isn't about taste — it follows from whether the dependency is required or optional, and whether you want it immutable.

• Constructor — your default. Use it for every required dependency: a service's repository, its sender, its clock. You get a guaranteed, immutable, self-documenting dependency you can fake with a plain new in a test.
• Setter — only for genuinely optional or reconfigurable deps. An optional cache, a logger that defaults to no-op, something you legitimately reconfigure at runtime. If the object works fine without it, a setter is honest about that.
• Field — avoid in production code. It hides the dependency, blocks final, and drags the framework into your unit tests. The one common exception is test code in some frameworks, where field injection into a test class is tolerated for brevity.