1. The Problem: A Service That Builds Its Own Dependencies#

Consider this service. The persistence and email implementations are placeholders for application code:

1
public class UserService {
2
    private final UserDao userDao = new JdbcUserDao();
3
    private final EmailService emailService = new SmtpEmailService();
4

5
    public void register(User user) {
6
        userDao.save(user);
7
        emailService.sendWelcomeEmail(user.email());
8
    }
9
}

UserService handles registration, but it also chooses and constructs the infrastructure used for that task. Replacing JDBC storage with another implementation requires editing the service. Testing registration in isolation is awkward because constructing the service also constructs its real collaborators.

The problem is the placement of those construction decisions. A service becomes easier to reuse when its caller can supply the dependencies.

2. What Gets Inverted?#

IoC is a design principle that transfers control from application code to an external mechanism, such as a framework. It is broader than object creation: framework callbacks and event handlers also invert control over when application code runs.

For dependency management, the change looks like this:

Dependency injection (DI) is the pattern of supplying an object’s collaborators from outside. Spring uses DI to implement IoC for application components, but DI also works in plain Java.

3. Start with Constructor Injection#

Define the contracts that registration needs. These examples use Java 17 or later; place each public type in its own file in the same package.

1
public record User(String email) {}

1
public interface UserDao {
2
    void save(User user);
3
}

1
public interface EmailService {
2
    void sendWelcomeEmail(String email);
3
}

Now pass both dependencies into the service:

1
import java.util.Objects;
2

3
public class UserService {
4
    private final UserDao userDao;
5
    private final EmailService emailService;
6

7
    public UserService(UserDao userDao, EmailService emailService) {
8
        this.userDao = Objects.requireNonNull(userDao);
9
        this.emailService = Objects.requireNonNull(emailService);
10
    }
11

12
    public void register(User user) {
13
        userDao.save(user);
14
        emailService.sendWelcomeEmail(user.email());
15
    }
16
}

The constructor makes the required collaborators visible. The null checks reject invalid arguments even when the service is constructed outside Spring, and final prevents reassignment of the dependency references. It does not make the collaborators themselves immutable.

Interfaces provide a convenient boundary for substituting implementations. DI does not require them: a constructor can accept a concrete class too.

1
import static org.junit.jupiter.api.Assertions.assertEquals;
2

3
import java.util.ArrayList;
4
import java.util.List;
5
import org.junit.jupiter.api.Test;
6

7
class UserServiceTest {
8
    @Test
9
    void registrationSavesUserAndSendsWelcomeEmail() {
10
        List<User> savedUsers = new ArrayList<>();
11
        List<String> recipients = new ArrayList<>();
12
        UserService service = new UserService(
13
            savedUsers::add,
14
            recipients::add
15
        );
16
        User user = new User("alice@example.com");
17

18
        service.register(user);
19

20
        assertEquals(List.of(user), savedUsers);
21
        assertEquals(List.of(user.email()), recipients);
22
    }
23
}

4. Let Spring Assemble the Objects#

A bean is an object managed by Spring’s container. Java configuration can register the service above without adding Spring annotations to it.

The following configuration uses demonstration implementations that print their actions. With spring-context available, it shows the complete wiring without requiring external services:

1
import org.springframework.context.annotation.Bean;
2
import org.springframework.context.annotation.Configuration;
3

4
@Configuration
5
public class AppConfig {
6
    @Bean
7
    public UserDao userDao() {
8
        return user -> System.out.println("Saving: " + user.email());
9
    }
10

11
    @Bean
12
    public EmailService emailService() {
13
        return email -> System.out.println("Welcoming: " + email);
14
    }
15

16
    @Bean
17
    public UserService userService(
18
            UserDao userDao, EmailService emailService) {
19
        return new UserService(userDao, emailService);
20
    }
21
}

Spring supplies the arguments to the userService() factory method using registered beans. The service still uses the same ordinary Java constructor.

Create and close the context at the application boundary:

1
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
2

3
public class Main {
4
    public static void main(String[] args) {
5
        try (var context = new AnnotationConfigApplicationContext(AppConfig.class)) {
6
            UserService service = context.getBean(UserService.class);
7
            service.register(new User("alice@example.com"));
8
        }
9
    }
10
}

Expected output:

1
Saving: alice@example.com
2
Welcoming: alice@example.com

Keep container lookups such as getBean() near startup code. Passing collaborators into business classes preserves explicit dependencies and keeps those classes easy to test.

5. Choosing an Injection Style#

Constructor injection is a useful default for required dependencies. Spring’s dependency injection guide recommends constructors for mandatory collaborators and setters for optional ones with reasonable defaults.

1
import org.springframework.beans.factory.annotation.Autowired;
2
import org.springframework.stereotype.Component;
3

4
@Component
5
public class RegistrationNotifier {
6
    private EmailService emailService = email -> {};
7

8
    @Autowired(required = false)
9
    public void setEmailService(EmailService emailService) {
10
        this.emailService = emailService;
11
    }
12

13
    public void notify(User user) {
14
        emailService.sendWelcomeEmail(user.email());
15
    }
16
}

1
@Autowired
2
private UserDao userDao;

6. What the Container Manages#

ApplicationContext coordinates bean definitions, dependency resolution, and lifecycle callbacks. In a typical configuration, it creates non-lazy singleton beans during startup; other beans may be created later.

Creation can use constructors or factory methods, including the @Bean methods above. Describing it only as reflection misses the role of explicit configuration.

Scope determines when instances are created and shared:

A singleton is not automatically thread-safe. Also, injecting a prototype into a singleton creates that dependency when the singleton is assembled; it does not produce a fresh object on each method call.

Lifecycle management has limits: Spring initializes prototype beans but does not automatically run their destruction callbacks. See the bean scope documentation for details.

7. Common Wiring Mistakes#

8. Applying IoC in Everyday Code#

Begin with the responsibilities of the class. Declare its required collaborators in a constructor, and assemble them in configuration or startup code. Use interfaces where an interchangeable contract helps, and verify business behavior with small tests that supply their own dependencies.

As the application grows, Spring can take over assembly, scopes, and lifecycle coordination. The service’s job remains straightforward: use the collaborators it receives to perform its work.