What is Dependency Injection?

Think of Spring Boot like a restaurant kitchen: your class should not run out and gather ingredients in the middle of cooking.

Question: What is Dependency Injection?

Answer: Dependency Injection means Spring creates the objects your class needs and gives them to it, instead of your class creating them with new. In Spring Boot, the ApplicationContext (the container) manages these objects, called beans, and connects them for you. This makes code easier to test, easier to change, and less tightly coupled to one specific implementation.

Interview-Ready Answer: I use Dependency Injection when I want Spring Boot to provide a class’s dependencies instead of my code building them manually. Spring’s container creates the beans, chooses the right implementation, and injects them, usually through the constructor. The big advantage is loose coupling: I can swap a real payment service for a mock in tests without changing the service code.

Core idea

Detailed Explanation: Dependency Injection is a way to apply Inversion of Control, which means your code does not control object creation and wiring by itself. Instead, Spring Boot’s container owns that job. A bean is just an object managed by Spring, and the container keeps track of how beans depend on each other.

How Spring does it under the hood

1. Spring scans the classpath for component classes such as @Component, @Service, @Repository, @Controller, and @Bean methods.
2. It builds bean definitions, which are descriptions of how each object should be created and wired.
3. For each bean, Spring resolves dependencies by type first. If more than one bean matches, it uses @Primary or @Qualifier to break the tie.
4. Spring creates required dependencies before the bean that needs them, then injects them through the constructor, setter, or field.
5. After wiring, Spring runs lifecycle callbacks such as initialization methods and then keeps singleton beans ready for use.

If a required dependency is missing, startup fails fast with an error like NoSuchBeanDefinitionException. If more than one bean fits and Spring cannot decide, you get NoUniqueBeanDefinitionException. That fail-fast behavior is good because it catches wiring mistakes early.

Which injection style should you prefer?

In modern Spring Boot, constructor injection is the default choice for most services. Since Spring 4.3, if a class has only one constructor, @Autowired is not required. That small detail is often asked in interviews.

When to use it

• Use DI for services that collaborate with repositories, clients, gateways, or other services.
• Use it when you want to swap implementations by environment, such as sandbox versus live payment providers.
• Use it when you want easy unit testing with mocks.
• Do not use it to create random plain objects that do not need Spring management.

Performance and edge cases

DI is mainly a startup-time cost. Spring resolves the bean graph once, so the work is roughly linear in the number of beans and dependency links, not on every method call. In a small app with 50-100 beans, the cost is usually tiny; in a larger app with hundreds of beans, startup can take seconds mostly because of classpath scanning, reflection, and proxy creation, not because injection itself is slow.

Some important edge cases: circular dependencies are a design smell, and Spring Boot 2.6+ disables many of them by default; optional dependencies can be handled with ObjectProvider or setter injection; and if you have multiple beans of the same type, be explicit with @Primary or @Qualifier. The mental model to remember is simple: Spring builds the object graph, and your code just uses the finished objects.

Real-World Example: Imagine an ecommerce checkout service. It needs a payment gateway, a tax calculator, and maybe a fraud checker. With DI, the checkout service depends on interfaces, so Spring can inject a sandbox gateway in development and a live gateway in production, while your business code stays the same.

What goes wrong when someone misunderstands DI? A developer hard-codes new StripePaymentGateway() inside the service. Now tests accidentally depend on real credentials, staging calls the wrong endpoint, and swapping providers becomes a code change instead of a config change. In production, the symptom is usually checkout failures, logs showing the wrong gateway, and support tickets from orders stuck in PENDING because the service could not be mocked or replaced cleanly.

The outage pattern is very recognizable: unit tests start making network calls, CI becomes flaky, and logs show NullPointerException or unexpected external API errors because an object was created outside Spring and never injected with its collaborators. DI prevents that by making dependencies explicit and centrally managed.

Follow-up & Tricky Questions:

• How is Dependency Injection different from Inversion of Control? IoC is the bigger idea that Spring controls object creation and flow; DI is the common way that control is implemented by supplying dependencies from the container.
• What is the difference between constructor injection and field injection? Constructor injection makes required dependencies explicit and easier to test. Field injection is shorter, but it hides dependencies and makes plain unit testing harder.
• What happens if two beans have the same type? Spring first matches by type, then uses @Primary or @Qualifier to choose one. If it still cannot decide, startup fails fast.
• How do you inject something optional? Use ObjectProvider, Optional, or setter injection when absence is valid. Optional dependencies should not force the whole app to fail at startup.
• Will Spring inject beans into objects created with new? No. Only Spring-managed beans are wired by the container; manually created objects bypass DI completely.
• Is @Autowired required on a single constructor? No, not in modern Spring. Since Spring 4.3, a class with one constructor is injected automatically.
• Can Spring inject static fields? No. Spring injects instance members on managed beans, not static fields on the class itself.
• Does constructor injection allow circular dependencies? Usually no, and that is a good thing because circular design is hard to maintain. Spring Boot 2.6+ also tightened circular dependency handling by default.

Common Mistakes:

• Using new inside a Spring service. Correction: inject the dependency so Spring can manage it and tests can replace it.
• Choosing field injection for everything. Correction: prefer constructor injection for required dependencies.
• Forgetting @Qualifier or @Primary when multiple beans implement the same interface. Correction: tell Spring exactly which bean you want.
• Confusing DI with service location. Correction: in DI, the container pushes dependencies into your class; your class should not go fetch them itself.

Memory Hook: You cook; Spring stocks the pantry. Your class does the work, but Spring supplies the ingredients, so the recipe stays clean and the kitchen can swap ingredients without rewriting the chef.

Cheat Sheet:

• DI means Spring gives your class its dependencies.
• Beans are Spring-managed objects inside the ApplicationContext.
• Constructor injection is the best default for required dependencies.
• Use @Primary or @Qualifier when several beans match.
• Use ObjectProvider or setter injection for optional dependencies.
• After startup, injected method calls are just normal Java calls.

Practice Tasks:

• Take a class that uses new and convert it to constructor injection.
• Add two implementations of one interface, then fix the ambiguity with @Primary or @Qualifier.
• Write a small test where the injected gateway is replaced by a mock and confirm the service still works.