How does the Dependency Inversion Principle relate to how Spring's @Autowired dependency injection works?

Spring's @Autowired mechanism is Dependency Inversion applied automatically at framework scale: a class declares a constructor parameter typed as an interface, and Spring's container is responsible for supplying a concrete bean that implements it at runtime, rather than the class constructing that dependency itself. This mirrors exactly the NotificationService example, where the class's constructor takes a NotificationChannel interface instead of building an EmailService directly — the only difference is that Spring automates the job of deciding which concrete implementation to hand over, instead of that decision being made explicitly in application code. Because the class only ever depends on the interface, Spring can swap in a completely different implementation for different environments or profiles — a real EmailService in production and a fake or test double in a test context — without changing the class's own source at all. This is also exactly why Spring-managed classes are so straightforward to unit test: since dependencies always arrive as interfaces through the constructor, a test can construct the class directly with a hand-written fake, bypassing the Spring container entirely.