Dependency Injection & IoC Explained | Loose Coupling in Spring | Spring Boot Full Course #4

Main ideas / lessons

• Why these concepts exist (problem motivation):

  • You can write “clean” Java without Spring, but core Spring ideas—Dependency Injection and Inversion of Control—are meant to make code more loosely coupled and easier to extend/test.
  • The lecture focuses on console/Java-core concepts, not Spring MVC/Boot features.

• Initial problem: tight coupling

  • In a basic design, OrderService:
    1. Creates a concrete EmailService object (new EmailService()).
    2. Calls sendNotification() on it.
  • This causes:
    • Tight coupling to a concrete class (order logic depends on EmailService specifically).
    • Poor extensibility: switching to SMS/Popup notifications forces modifying OrderService.
    • Single Responsibility violations: OrderService does both:
      • order/business logic
      • dependency/object creation (“factory work”)

• Step toward loose coupling: programming to interfaces

  • Create a NotificationService interface with sendNotification().
  • Implement it with multiple concrete classes:
    • EmailService
    • PopUpNotificationService
    • SMSService
  • Update OrderService to depend on the interface type rather than a concrete class:
    • NotificationService notification;
  • Still, if OrderService creates the concrete object itself, the design remains problematic.

• Solution: Dependency Injection (DI)

  • Move dependency creation out of OrderService.
  • Let OrderService receive a NotificationService instance from outside (commonly via:
    • constructor injection or
    • setter injection).
  • With DI, OrderService no longer cares whether the notification is email/SMS/popup—only that it can call sendNotification().

• Benefits of DI

  • Loose coupling / Open-Closed Principle: you can add/swap notification types without changing OrderService.
  • Easier unit testing:
    • Previously, testing OrderService forced using the real dependency (e.g., real EmailService) because it was created internally.
    • With DI, you can inject a fake/stub notification service implementation (e.g., DummyEmailService) to test order behavior without triggering real notification behavior.

• Inversion of Control (IoC): concept and relationship to DI

  • IoC is described as “control flow inversion”:
    • Initially: OrderService creates the notification dependency (control flows from OrderService → EmailService).
    • After DI: an external component creates the dependency and passes it into OrderService (control becomes “inverted”; creation/wiring moves outside).
  • Dependency Inversion (a principle/approach) is related:
    • The lecture states:
      • IoC is the principle/idea
      • Dependency Inversion is a technique/approach to achieve IoC
  • In real Spring usage, Spring takes over the wiring/creation that the main method did manually.

• How Spring fits in (high-level)

  • Spring provides an IoC container (Spring IoC container).
  • The container replaces what main was doing:
    • creating objects (beans)
    • managing their lifecycles (when created/destroyed)
    • wiring/connecting dependencies between objects
  • The lecturer emphasizes:
    • Dependency Injection and IoC are not inherently “Spring-only”; Spring automates them.
    • In Spring code, explicit new is reduced; the container manages objects.
  • Terminology note:
    • In Spring, container-managed objects are called beans.
    • Not every Java object is necessarily a bean—beans are those managed by the container.

---

Methodology / structure presented (conceptual steps)

1) Demonstrate the tight-coupling problem (baseline)

• Create an OrderService with a method like placeOrder().
• Create a concrete EmailService with a method like sendNotification().
• In OrderService:
  • create the dependency internally (e.g., notification = new EmailService()),
  • then call notification.sendNotification().
• Result: changing notification type requires editing OrderService.

2) Reduce coupling using interfaces (still shows creation problem)

• Define an interface NotificationService (with sendNotification()).
• Implement it with:
  • EmailService implements NotificationService
  • PopUpNotificationService implements NotificationService
  • SMSService implements NotificationService
• Update OrderService to use:
  • a field/reference of type NotificationService
• Important limitation called out:
  • If OrderService still creates the concrete implementation internally, coupling problems remain.

3) Apply Dependency Injection (DI) properly

• Modify OrderService to accept NotificationService from outside.
• Common injection approaches covered:

A) Constructor injection

• Add a constructor to OrderService:
  • OrderService(NotificationService notification)
• Store the passed dependency in an instance variable.
• When placeOrder() runs:
  • call notification.sendNotification().

B) Setter injection

• Provide:
  • an empty constructor (optional) and
  • a setter like setNotification(NotificationService notification).
• In main, create OrderService then call:
  • order.setNotification(new EmailService()) (or SMS/Popup).
• placeOrder() uses the injected instance variable.

C) Field injection

• Mentioned as a “third type,” but deferred:
  • lecturer says it will be covered in Spring (not feasible/meaningful in plain Java the same way).

4) Test improvement using DI (testing approach)

• Instead of injecting the real EmailService, create a fake/dummy notification implementation of NotificationService.
• Inject the fake into OrderService (via constructor or setter).
• Run unit tests:
  • verify order logic,
  • avoid real external side effects (like sending real emails).

5) How Spring IoC container changes wiring (automation)

• Replace manual wiring done in main with Spring container responsibilities:
  • Create beans
  • Inject dependencies
  • Manage object lifecycle and relationships
• Outcome:
  • main becomes simpler (in the Spring version of the code),
  • OrderService remains focused on its business logic.

---

Speakers / sources featured

• Speaker: “Coder Army” (the instructor/host)