System Design (HLD)Dependency Injection Fundamentals

Dependency Injection Fundamentals

LevelIntermediate

Duration60 mins

TopicDependency Injection Fundamentals

4 / 5

Interface Injection

The Lesser-Known Injection Pattern

Among the three injection patterns—Constructor, Setter, and Interface—Interface Injection is the least commonly used and least discussed. Yet understanding it completes your dependency injection vocabulary and helps you recognize it when you encounter it in frameworks and legacy systems.

With Interface Injection, the dependent class implements an interface that declares a method for receiving the dependency. The injector knows that any class implementing that interface can receive the dependency through that method. The interface itself becomes the contract for injection.

This pattern inverts the usual relationship: instead of the class deciding how to receive dependencies, an interface dictates the injection mechanism.

What You Will Learn

By the end of this page, you will understand Interface Injection mechanics, recognize where it appears in practice (especially in frameworks), compare it to Constructor and Setter Injection, and know when—and when not—to use this pattern in your designs.

Understanding Interface Injection

Interface Injection follows this pattern:

Define an injection interface — An interface declares a method for receiving a specific dependency type.
Dependent class implements the interface — By implementing the interface, the class signals that it needs that dependency and knows how to receive it.
Injector checks for interface implementation — The injector/framework detects that the class implements the injection interface.
Injector calls the injection method — The framework invokes the interface method, passing the dependency.

The key distinction: the interface defines how injection happens, not the class's arbitrary setter or constructor.

interface-injection-anatomy.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
// ANATOMY OF INTERFACE INJECTION
 
// Step 1: Define injection interfaces
// Each interface declares a method for receiving a specific dependency
interface LoggerAware {
    setLogger(logger: Logger): void;
}
 
interface RepositoryAware {
    setRepository(repository: Repository): void;
}
 
interface EventPublisherAware {
    setEventPublisher(publisher: EventPublisher): void;
}
 
// Step 2: Dependent class implements relevant interfaces
// The class signals which dependencies it needs by implementing interfaces
class OrderService implements LoggerAware, RepositoryAware {
    private logger!: Logger;
    private repository!: Repository;
    
    // Interface-mandated injection methods
    setLogger(logger: Logger): void {
        this.logger = logger;
    }
    
    setRepository(repository: Repository): void {
        this.repository = repository;
    }
    
    async processOrder(order: Order): Promise<void> {
        this.logger.info(`Processing order ${order.id}`);
        await this.repository.save(order);
    }
}
 
// Step 3 & 4: Injector/framework detects interfaces and calls methods
function injectDependencies(target: unknown, container: Container): void {
    // Check for LoggerAware interface
    if (isLoggerAware(target)) {
        target.setLogger(container.get<Logger>("Logger"));
    }
    
    // Check for RepositoryAware interface
    if (isRepositoryAware(target)) {
        target.setRepository(container.get<Repository>("Repository"));
    }
    
    // Check for EventPublisherAware interface
    if (isEventPublisherAware(target)) {
        target.setEventPublisher(container.get<EventPublisher>("EventPublisher"));
    }
}
 
// Type guards for interface detection
function isLoggerAware(obj: unknown): obj is LoggerAware {
    return typeof (obj as LoggerAware).setLogger === "function";
}
 
function isRepositoryAware(obj: unknown): obj is RepositoryAware {
    return typeof (obj as RepositoryAware).setRepository === "function";
}

The •Aware Naming Convention

You'll often see interface injection interfaces named with the *Aware suffix: ApplicationContextAware, LoggerAware, EnvironmentAware. This convention comes from Spring Framework and signals that implementing the interface grants awareness of (access to) that dependency.

Interface Injection vs Setter Injection

At first glance, Interface Injection looks identical to Setter Injection—both use setter methods to provide dependencies. The crucial difference lies in who defines the setter method:

Setter Injection: The class defines its own setter methods. The setter signature is arbitrary—the class controls it.

Interface Injection: An interface defines the setter method. The class implements the interface and must conform to its signature. The framework/injector looks for interface implementations, not arbitrary methods.

Setter Injection vs Interface Injection
Aspect	Setter Injection	Interface Injection
Who defines the setter	The dependent class	An interface (shared contract)
Method signature	Arbitrary (class decides)	Standardized (interface mandates)
Detection by injector	By method name/annotation	By interface implementation
Coupling	Class coupled to setter convention	Class coupled to interface type
Consistency	Each class may differ	All implementers use same method
Framework integration	Annotations or naming conventions	Type-safe interface checking

setter-injection-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// SETTER INJECTION
// Class defines its own method
 
class OrderService {
    private log?: Logger;
    
    // Arbitrary name decided by class
    setLog(logger: Logger) {
        this.log = logger;
    }
}
 
class UserService {
    private logging?: Logger;
    
    // Different name, same purpose
    setLogging(logger: Logger) {
        this.logging = logger;
    }
}
 
// Injector needs to know each
// class's specific setter name
inject(orderService, "setLog", logger);
inject(userService, "setLogging", logger);

interface-injection-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// INTERFACE INJECTION
// Interface defines the method
 
interface LoggerAware {
    setLogger(logger: Logger): void;
}
 
class OrderService implements LoggerAware {
    private logger?: Logger;
    
    // Must match interface signature
    setLogger(logger: Logger) {
        this.logger = logger;
    }
}
 
class UserService implements LoggerAware {
    private logger?: Logger;
    
    // Same method, same name
    setLogger(logger: Logger) {
        this.logger = logger;
    }
}
 
// Injector uses interface check
if (isLoggerAware(service)) {
    service.setLogger(logger);
}

The standardization benefit:

Interface Injection provides consistency across a codebase or framework. Every class that needs a Logger implements LoggerAware and receives it through setLogger(). The injector doesn't need to know anything about the class's internals—just check if it implements the interface and call the standardized method.

This is why frameworks use Interface Injection: they can inject framework-provided services into user classes without knowing anything about those classes beyond which interfaces they implement.

Real-World Interface Injection in Frameworks

Interface Injection appears prominently in frameworks that need to inject framework services into user-defined classes. The most notable example is *Spring Framework's Aware interfaces.

spring-aware-interfaces.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// SPRING FRAMEWORK *AWARE INTERFACES
 
// ApplicationContextAware - receive the Spring container
public interface ApplicationContextAware {
    void setApplicationContext(ApplicationContext context);
}
 
// BeanNameAware - receive the bean's name in the container
public interface BeanNameAware {
    void setBeanName(String name);
}
 
// EnvironmentAware - receive environment configuration
public interface EnvironmentAware {
    void setEnvironment(Environment environment);
}
 
// ResourceLoaderAware - receive resource loading capability
public interface ResourceLoaderAware {
    void setResourceLoader(ResourceLoader loader);
}
 
// Example: A service using Interface Injection
@Service
public class DynamicPluginLoader implements 
        ApplicationContextAware, 
        EnvironmentAware {
    
    private ApplicationContext context;
    private Environment environment;
    
    // Spring calls this automatically during initialization
    @Override
    public void setApplicationContext(ApplicationContext context) {
        this.context = context;
    }
    
    // Spring calls this automatically during initialization
    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }
    
    public void loadPlugin(String pluginName) {
        // Use context to dynamically lookup beans
        String pluginClass = environment.getProperty("plugin." + pluginName);
        Plugin plugin = context.getBean(pluginClass, Plugin.class);
        plugin.initialize();
    }
}

Servlet Lifecycle Callbacks:

Java Servlet specification uses a similar pattern. Servlets implement interfaces to receive container-provided resources:

servlet-lifecycle.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// SERVLET SPECIFICATION INTERFACE INJECTION
 
// ServletContextAware equivalent
public interface ServletContextListener {
    void contextInitialized(ServletContextEvent event);
    void contextDestroyed(ServletContextEvent event);
}
 
// HttpSessionAware equivalent
public interface HttpSessionListener {
    void sessionCreated(HttpSessionEvent event);
    void sessionDestroyed(HttpSessionEvent event);
}
 
// Example servlet receiving the ServletConfig
public class MyServlet extends HttpServlet {
    
    private ServletConfig config;
    
    // Container calls this during servlet initialization
    @Override
    public void init(ServletConfig config) throws ServletException {
        this.config = config;
        // Access context, parameters, etc.
        String dbUrl = config.getInitParameter("database.url");
    }
    
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        // Use config...
    }
}

.NET's IServiceProvider Pattern:

In .NET, interface injection appears in hosting and middleware contexts:

dotnet-interface-injection.cs
C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// .NET HOSTED SERVICE INTERFACE INJECTION
 
// IHostedService - for long-running background services
public interface IHostedService
{
    Task StartAsync(CancellationToken cancellationToken);
    Task StopAsync(CancellationToken cancellationToken);
}
 
// Implementing class receives lifecycle callbacks
public class BackgroundEmailSender : IHostedService
{
    private readonly IEmailQueue _queue;
    private Timer _timer;
    
    // Constructor injection for business dependencies
    public BackgroundEmailSender(IEmailQueue queue)
    {
        _queue = queue;
    }
    
    // Interface injection: host calls this to start the service
    public Task StartAsync(CancellationToken cancellationToken)
    {
        _timer = new Timer(ProcessQueue, null, TimeSpan.Zero, TimeSpan.FromSeconds(10));
        return Task.CompletedTask;
    }
    
    // Interface injection: host calls this during shutdown
    public Task StopAsync(CancellationToken cancellationToken)
    {
        _timer?.Dispose();
        return Task.CompletedTask;
    }
    
    private void ProcessQueue(object state)
    {
        // Process pending emails
    }
}

Framework Integration Point

Interface Injection is most common at framework integration points—where your code receives framework-provided capabilities. When you need to access the application context, environment, lifecycle events, or container services, you'll often see interfaces like *Aware, *Listener, or *Callback.

Advantages and Disadvantages

Advantages

•Standardization — All classes needing a dependency use the same interface, same method name
•Type-safe detection — Injector checks interface implementation, not arbitrary method names
•Self-documenting — Interface list on a class shows what framework services it needs
•Framework decoupling — Framework injects through interface; class doesn't import framework types
•Explicit opt-in — Class explicitly signals its needs by implementing interfaces

Disadvantages

•Interface proliferation — Each injectable dependency needs a dedicated interface
•Incomplete state — Like setter injection, object exists before dependencies are injected
•Mutability — Dependencies can potentially be re-injected
•Invasive — Class must implement framework-defined interfaces
•Less common — Developers unfamiliar with pattern may be confused

When Interface Injection makes sense:

Framework-provided services — The framework controls what's injected (e.g., ApplicationContext, Environment). You don't choose the implementation; you just receive it.
Cross-cutting concerns — Logging, configuration, and monitoring that many classes might need. A single LoggerAware interface serves the entire codebase.
Plugin systems — Plugins implement interfaces to receive host-provided capabilities without knowing the host's concrete types.
Lifecycle callbacks — When the container/framework needs to notify objects of lifecycle events (initialization, shutdown).

When to avoid Interface Injection:

Business dependencies — For domain services depending on other domain services, Constructor Injection is clearer and enforces completeness.
Many dependencies — If a class needs 5 interfaces, it becomes cluttered: class Service implements A, B, C, D, E. Constructor parameters are more compact.
Required dependencies — Interface Injection doesn't guarantee dependencies are provided before use. Constructor Injection does.
Application code — Interface Injection is primarily a framework pattern. In application code, prefer Constructor/Setter Injection.

Implementing Your Own Interface Injection

While Interface Injection is most common in frameworks, you can implement it in your own codebase for cross-cutting concerns. Here's a complete implementation:

custom-interface-injection.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// IMPLEMENTING INTERFACE INJECTION
 
// Step 1: Define injection interfaces for cross-cutting concerns
interface LoggerInjectable {
    injectLogger(logger: Logger): void;
}
 
interface ConfigInjectable {
    injectConfig(config: AppConfig): void;
}
 
interface MetricsInjectable {
    injectMetrics(metrics: MetricsCollector): void;
}
 
// Type guards for runtime detection
function isLoggerInjectable(obj: unknown): obj is LoggerInjectable {
    return obj !== null && 
           typeof obj === "object" && 
           typeof (obj as LoggerInjectable).injectLogger === "function";
}
 
function isConfigInjectable(obj: unknown): obj is ConfigInjectable {
    return obj !== null && 
           typeof obj === "object" && 
           typeof (obj as ConfigInjectable).injectConfig === "function";
}
 
function isMetricsInjectable(obj: unknown): obj is MetricsInjectable {
    return obj !== null && 
           typeof obj === "object" && 
           typeof (obj as MetricsInjectable).injectMetrics === "function";
}
 
// Step 2: Create the injector
class DependencyInjector {
    private logger: Logger;
    private config: AppConfig;
    private metrics: MetricsCollector;
    
    constructor(
        logger: Logger,
        config: AppConfig,
        metrics: MetricsCollector
    ) {
        this.logger = logger;
        this.config = config;
        this.metrics = metrics;
    }
    
    inject<T>(target: T): T {
        // Check each interface and inject if implemented
        if (isLoggerInjectable(target)) {
            target.injectLogger(this.logger);
        }
        
        if (isConfigInjectable(target)) {
            target.injectConfig(this.config);
        }
        
        if (isMetricsInjectable(target)) {
            target.injectMetrics(this.metrics);
        }
        
        return target;
    }
    
    // Create and inject in one step
    create<T>(Factory: new () => T): T {
        const instance = new Factory();
        return this.inject(instance);
    }
}
 
// Step 3: Classes implement interfaces as needed
class OrderService implements LoggerInjectable, MetricsInjectable {
    private logger!: Logger;
    private metrics!: MetricsCollector;
    private readonly repository: OrderRepository;
    
    // Constructor for business dependencies
    constructor(repository: OrderRepository) {
        this.repository = repository;
    }
    
    // Interface methods for cross-cutting concerns
    injectLogger(logger: Logger): void {
        this.logger = logger;
    }
    
    injectMetrics(metrics: MetricsCollector): void {
        this.metrics = metrics;
    }
    
    async processOrder(order: Order): Promise<void> {
        const startTime = Date.now();
        this.logger.info(`Processing order ${order.id}`);
        
        await this.repository.save(order);
        
        this.metrics.recordTiming("order.process", Date.now() - startTime);
        this.logger.info(`Order ${order.id} processed`);
    }
}
 
// Step 4: Usage
const injector = new DependencyInjector(
    new WinstonLogger(),
    loadConfig(),
    new PrometheusMetrics()
);
 
// Create with constructor dependency, then inject cross-cutting
const orderService = new OrderService(new PostgresOrderRepository());
injector.inject(orderService);
 
// Now orderService has logger & metrics injected

Combining with Constructor Injection

The most practical pattern combines Constructor Injection for business dependencies and Interface Injection for framework/cross-cutting concerns. Business logic receives its collaborators through the constructor; logging, configuration, and monitoring come through interfaces.

Testing with Interface Injection

Testing classes that use Interface Injection follows a similar pattern to Setter Injection testing. You must ensure injection methods are called before exercising the class:

testing-interface-injection.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
describe("OrderService with Interface Injection", () => {
    let service: OrderService;
    let mockRepository: jest.Mocked<OrderRepository>;
    let mockLogger: jest.Mocked<Logger>;
    let mockMetrics: jest.Mocked<MetricsCollector>;
    
    beforeEach(() => {
        // Create mocks
        mockRepository = {
            save: jest.fn(),
            findById: jest.fn()
        };
        
        mockLogger = {
            info: jest.fn(),
            error: jest.fn(),
            warn: jest.fn()
        };
        
        mockMetrics = {
            recordTiming: jest.fn(),
            incrementCounter: jest.fn()
        };
        
        // Create service with constructor dependency
        service = new OrderService(mockRepository);
        
        // Call interface injection methods
        service.injectLogger(mockLogger);
        service.injectMetrics(mockMetrics);
    });
    
    describe("processOrder", () => {
        it("should log and record metrics", async () => {
            const order = createTestOrder({ id: "ORD-123" });
            mockRepository.save.mockResolvedValue(undefined);
            
            await service.processOrder(order);
            
            expect(mockLogger.info).toHaveBeenCalledWith(
                "Processing order ORD-123"
            );
            expect(mockMetrics.recordTiming).toHaveBeenCalledWith(
                "order.process",
                expect.any(Number)
            );
        });
    });
    
    describe("without logger injected", () => {
        it("should throw if logger not injected", async () => {
            // Create new service without injecting logger
            const uninitializedService = new OrderService(mockRepository);
            // Don't call injectLogger
            
            await expect(uninitializedService.processOrder(createTestOrder()))
                .rejects.toThrow();
        });
    });
});
 
// Helper to create fully injected service
function createFullyInjectedService(
    repository: OrderRepository
): OrderService {
    const service = new OrderService(repository);
    service.injectLogger(createMockLogger());
    service.injectMetrics(createMockMetrics());
    return service;
}

Using an injector in tests:

Alternatively, create a test injector that provides mock implementations:

test-injector.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Create a test injector with mocks
function createTestInjector() {
    const mockLogger = createMockLogger();
    const mockConfig = createMockConfig();
    const mockMetrics = createMockMetrics();
    
    const injector = new DependencyInjector(
        mockLogger,
        mockConfig,
        mockMetrics
    );
    
    return {
        injector,
        mocks: {
            logger: mockLogger,
            config: mockConfig,
            metrics: mockMetrics
        }
    };
}
 
// In tests
describe("OrderService via injector", () => {
    it("should use injected mocks", async () => {
        const { injector, mocks } = createTestInjector();
        
        const service = injector.inject(
            new OrderService(createMockRepository())
        );
        
        await service.processOrder(createTestOrder());
        
        expect(mocks.logger.info).toHaveBeenCalled();
    });
});

Injection Patterns Comparison

With all three injection patterns explored, let's consolidate the comparison:

Complete Injection Pattern Comparison
Criterion	Constructor	Setter	Interface
Object readiness	Immediate	After setters called	After interface methods called
Dependency visibility	Explicit in constructor	Scattered setters	Scattered interfaces
Immutability	Easy (readonly fields)	Requires discipline	Requires discipline
Required dependencies	Perfect fit	Needs validation	Needs validation
Optional dependencies	Possible with defaults	Natural fit	Less common
Testing	Simple - pass mocks	Remember to call setters	Remember to call injection methods
Framework detection	Analyze constructor	Naming/annotations	Interface implementation
Primary use case	Business dependencies	Optional/late deps	Framework services

The Decision Guide

Use Constructor Injection for required business dependencies that the class cannot function without. Use Setter Injection for optional dependencies that enhance but aren't essential. Use Interface Injection when implementing framework contracts or standardizing cross-cutting concern injection across many classes.

Summary: Interface Injection Mastery

Interface Injection completes your dependency injection vocabulary. Let's consolidate the essential knowledge:

Key Takeaways

•Mechanics — An interface defines an injection method. Classes implement the interface to receive the dependency. The injector detects interface implementation.
•vs Setter — The interface standardizes the injection method across all implementing classes, unlike arbitrary setters.
•Framework usage — Common in Spring (*Aware interfaces), Servlets, .NET (IHostedService), and other frameworks for injecting framework services.
•Best suited for — Framework-provided services, cross-cutting concerns, lifecycle callbacks, plugin systems.
•Avoid for — Business dependencies, required dependencies, application-level code. Use Constructor Injection instead.
•Hybrid pattern — Constructor Injection for business dependencies, Interface Injection for framework/cross-cutting concerns.
•Testing — Similar to Setter Injection—ensure injection methods are called before exercising the class.

What's next:

The final page of this module addresses the crucial decision: Choosing the Right Injection Style. You'll develop a decision framework for selecting among Constructor, Setter, and Interface Injection based on specific requirements, constraints, and trade-offs. This practical guidance completes your Dependency Injection fundamentals.

Pattern Recognition Complete

You now understand all three injection patterns: Constructor, Setter, and Interface. Each has its place—Constructor for the common case, Setter for optional dependencies, Interface for framework integration. The next page provides the framework for choosing among them in real-world scenarios.

4 / 5

Loading learning content...

System Design (HLD)Dependency Injection Fundamentals

Dependency Injection Fundamentals

LevelIntermediate

Duration60 mins

TopicDependency Injection Fundamentals

4 / 5

Interface Injection

The Lesser-Known Injection Pattern

This pattern inverts the usual relationship: instead of the class deciding how to receive dependencies, an interface dictates the injection mechanism.

What You Will Learn

Understanding Interface Injection

Interface Injection follows this pattern:

Define an injection interface — An interface declares a method for receiving a specific dependency type.
Dependent class implements the interface — By implementing the interface, the class signals that it needs that dependency and knows how to receive it.
Injector checks for interface implementation — The injector/framework detects that the class implements the injection interface.
Injector calls the injection method — The framework invokes the interface method, passing the dependency.

The key distinction: the interface defines how injection happens, not the class's arbitrary setter or constructor.

interface-injection-anatomy.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
// ANATOMY OF INTERFACE INJECTION
 
// Step 1: Define injection interfaces
// Each interface declares a method for receiving a specific dependency
interface LoggerAware {
    setLogger(logger: Logger): void;
}
 
interface RepositoryAware {
    setRepository(repository: Repository): void;
}
 
interface EventPublisherAware {
    setEventPublisher(publisher: EventPublisher): void;
}
 
// Step 2: Dependent class implements relevant interfaces
// The class signals which dependencies it needs by implementing interfaces
class OrderService implements LoggerAware, RepositoryAware {
    private logger!: Logger;
    private repository!: Repository;
    
    // Interface-mandated injection methods
    setLogger(logger: Logger): void {
        this.logger = logger;
    }
    
    setRepository(repository: Repository): void {
        this.repository = repository;
    }
    
    async processOrder(order: Order): Promise<void> {
        this.logger.info(`Processing order ${order.id}`);
        await this.repository.save(order);
    }
}
 
// Step 3 & 4: Injector/framework detects interfaces and calls methods
function injectDependencies(target: unknown, container: Container): void {
    // Check for LoggerAware interface
    if (isLoggerAware(target)) {
        target.setLogger(container.get<Logger>("Logger"));
    }
    
    // Check for RepositoryAware interface
    if (isRepositoryAware(target)) {
        target.setRepository(container.get<Repository>("Repository"));
    }
    
    // Check for EventPublisherAware interface
    if (isEventPublisherAware(target)) {
        target.setEventPublisher(container.get<EventPublisher>("EventPublisher"));
    }
}
 
// Type guards for interface detection
function isLoggerAware(obj: unknown): obj is LoggerAware {
    return typeof (obj as LoggerAware).setLogger === "function";
}
 
function isRepositoryAware(obj: unknown): obj is RepositoryAware {
    return typeof (obj as RepositoryAware).setRepository === "function";
}

The •Aware Naming Convention

Interface Injection vs Setter Injection

At first glance, Interface Injection looks identical to Setter Injection—both use setter methods to provide dependencies. The crucial difference lies in who defines the setter method:

Setter Injection: The class defines its own setter methods. The setter signature is arbitrary—the class controls it.

Setter Injection vs Interface Injection
Aspect	Setter Injection	Interface Injection
Who defines the setter	The dependent class	An interface (shared contract)
Method signature	Arbitrary (class decides)	Standardized (interface mandates)
Detection by injector	By method name/annotation	By interface implementation
Coupling	Class coupled to setter convention	Class coupled to interface type
Consistency	Each class may differ	All implementers use same method
Framework integration	Annotations or naming conventions	Type-safe interface checking

setter-injection-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// SETTER INJECTION
// Class defines its own method
 
class OrderService {
    private log?: Logger;
    
    // Arbitrary name decided by class
    setLog(logger: Logger) {
        this.log = logger;
    }
}
 
class UserService {
    private logging?: Logger;
    
    // Different name, same purpose
    setLogging(logger: Logger) {
        this.logging = logger;
    }
}
 
// Injector needs to know each
// class's specific setter name
inject(orderService, "setLog", logger);
inject(userService, "setLogging", logger);

interface-injection-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// INTERFACE INJECTION
// Interface defines the method
 
interface LoggerAware {
    setLogger(logger: Logger): void;
}
 
class OrderService implements LoggerAware {
    private logger?: Logger;
    
    // Must match interface signature
    setLogger(logger: Logger) {
        this.logger = logger;
    }
}
 
class UserService implements LoggerAware {
    private logger?: Logger;
    
    // Same method, same name
    setLogger(logger: Logger) {
        this.logger = logger;
    }
}
 
// Injector uses interface check
if (isLoggerAware(service)) {
    service.setLogger(logger);
}

The standardization benefit:

This is why frameworks use Interface Injection: they can inject framework-provided services into user classes without knowing anything about those classes beyond which interfaces they implement.

Real-World Interface Injection in Frameworks

Interface Injection appears prominently in frameworks that need to inject framework services into user-defined classes. The most notable example is *Spring Framework's Aware interfaces.

spring-aware-interfaces.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// SPRING FRAMEWORK *AWARE INTERFACES
 
// ApplicationContextAware - receive the Spring container
public interface ApplicationContextAware {
    void setApplicationContext(ApplicationContext context);
}
 
// BeanNameAware - receive the bean's name in the container
public interface BeanNameAware {
    void setBeanName(String name);
}
 
// EnvironmentAware - receive environment configuration
public interface EnvironmentAware {
    void setEnvironment(Environment environment);
}
 
// ResourceLoaderAware - receive resource loading capability
public interface ResourceLoaderAware {
    void setResourceLoader(ResourceLoader loader);
}
 
// Example: A service using Interface Injection
@Service
public class DynamicPluginLoader implements 
        ApplicationContextAware, 
        EnvironmentAware {
    
    private ApplicationContext context;
    private Environment environment;
    
    // Spring calls this automatically during initialization
    @Override
    public void setApplicationContext(ApplicationContext context) {
        this.context = context;
    }
    
    // Spring calls this automatically during initialization
    @Override
    public void setEnvironment(Environment environment) {
        this.environment = environment;
    }
    
    public void loadPlugin(String pluginName) {
        // Use context to dynamically lookup beans
        String pluginClass = environment.getProperty("plugin." + pluginName);
        Plugin plugin = context.getBean(pluginClass, Plugin.class);
        plugin.initialize();
    }
}

Servlet Lifecycle Callbacks:

Java Servlet specification uses a similar pattern. Servlets implement interfaces to receive container-provided resources:

servlet-lifecycle.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// SERVLET SPECIFICATION INTERFACE INJECTION
 
// ServletContextAware equivalent
public interface ServletContextListener {
    void contextInitialized(ServletContextEvent event);
    void contextDestroyed(ServletContextEvent event);
}
 
// HttpSessionAware equivalent
public interface HttpSessionListener {
    void sessionCreated(HttpSessionEvent event);
    void sessionDestroyed(HttpSessionEvent event);
}
 
// Example servlet receiving the ServletConfig
public class MyServlet extends HttpServlet {
    
    private ServletConfig config;
    
    // Container calls this during servlet initialization
    @Override
    public void init(ServletConfig config) throws ServletException {
        this.config = config;
        // Access context, parameters, etc.
        String dbUrl = config.getInitParameter("database.url");
    }
    
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
        // Use config...
    }
}

.NET's IServiceProvider Pattern:

In .NET, interface injection appears in hosting and middleware contexts:

dotnet-interface-injection.cs
C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// .NET HOSTED SERVICE INTERFACE INJECTION
 
// IHostedService - for long-running background services
public interface IHostedService
{
    Task StartAsync(CancellationToken cancellationToken);
    Task StopAsync(CancellationToken cancellationToken);
}
 
// Implementing class receives lifecycle callbacks
public class BackgroundEmailSender : IHostedService
{
    private readonly IEmailQueue _queue;
    private Timer _timer;
    
    // Constructor injection for business dependencies
    public BackgroundEmailSender(IEmailQueue queue)
    {
        _queue = queue;
    }
    
    // Interface injection: host calls this to start the service
    public Task StartAsync(CancellationToken cancellationToken)
    {
        _timer = new Timer(ProcessQueue, null, TimeSpan.Zero, TimeSpan.FromSeconds(10));
        return Task.CompletedTask;
    }
    
    // Interface injection: host calls this during shutdown
    public Task StopAsync(CancellationToken cancellationToken)
    {
        _timer?.Dispose();
        return Task.CompletedTask;
    }
    
    private void ProcessQueue(object state)
    {
        // Process pending emails
    }
}

Framework Integration Point

Advantages and Disadvantages

Advantages

•Standardization — All classes needing a dependency use the same interface, same method name
•Type-safe detection — Injector checks interface implementation, not arbitrary method names
•Self-documenting — Interface list on a class shows what framework services it needs
•Framework decoupling — Framework injects through interface; class doesn't import framework types
•Explicit opt-in — Class explicitly signals its needs by implementing interfaces

Disadvantages

•Interface proliferation — Each injectable dependency needs a dedicated interface
•Incomplete state — Like setter injection, object exists before dependencies are injected
•Mutability — Dependencies can potentially be re-injected
•Invasive — Class must implement framework-defined interfaces
•Less common — Developers unfamiliar with pattern may be confused

When Interface Injection makes sense:

Framework-provided services — The framework controls what's injected (e.g., ApplicationContext, Environment). You don't choose the implementation; you just receive it.
Cross-cutting concerns — Logging, configuration, and monitoring that many classes might need. A single LoggerAware interface serves the entire codebase.
Plugin systems — Plugins implement interfaces to receive host-provided capabilities without knowing the host's concrete types.
Lifecycle callbacks — When the container/framework needs to notify objects of lifecycle events (initialization, shutdown).

When to avoid Interface Injection:

Business dependencies — For domain services depending on other domain services, Constructor Injection is clearer and enforces completeness.
Many dependencies — If a class needs 5 interfaces, it becomes cluttered: class Service implements A, B, C, D, E. Constructor parameters are more compact.
Required dependencies — Interface Injection doesn't guarantee dependencies are provided before use. Constructor Injection does.
Application code — Interface Injection is primarily a framework pattern. In application code, prefer Constructor/Setter Injection.

Implementing Your Own Interface Injection

While Interface Injection is most common in frameworks, you can implement it in your own codebase for cross-cutting concerns. Here's a complete implementation:

custom-interface-injection.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
// IMPLEMENTING INTERFACE INJECTION
 
// Step 1: Define injection interfaces for cross-cutting concerns
interface LoggerInjectable {
    injectLogger(logger: Logger): void;
}
 
interface ConfigInjectable {
    injectConfig(config: AppConfig): void;
}
 
interface MetricsInjectable {
    injectMetrics(metrics: MetricsCollector): void;
}
 
// Type guards for runtime detection
function isLoggerInjectable(obj: unknown): obj is LoggerInjectable {
    return obj !== null && 
           typeof obj === "object" && 
           typeof (obj as LoggerInjectable).injectLogger === "function";
}
 
function isConfigInjectable(obj: unknown): obj is ConfigInjectable {
    return obj !== null && 
           typeof obj === "object" && 
           typeof (obj as ConfigInjectable).injectConfig === "function";
}
 
function isMetricsInjectable(obj: unknown): obj is MetricsInjectable {
    return obj !== null && 
           typeof obj === "object" && 
           typeof (obj as MetricsInjectable).injectMetrics === "function";
}
 
// Step 2: Create the injector
class DependencyInjector {
    private logger: Logger;
    private config: AppConfig;
    private metrics: MetricsCollector;
    
    constructor(
        logger: Logger,
        config: AppConfig,
        metrics: MetricsCollector
    ) {
        this.logger = logger;
        this.config = config;
        this.metrics = metrics;
    }
    
    inject<T>(target: T): T {
        // Check each interface and inject if implemented
        if (isLoggerInjectable(target)) {
            target.injectLogger(this.logger);
        }
        
        if (isConfigInjectable(target)) {
            target.injectConfig(this.config);
        }
        
        if (isMetricsInjectable(target)) {
            target.injectMetrics(this.metrics);
        }
        
        return target;
    }
    
    // Create and inject in one step
    create<T>(Factory: new () => T): T {
        const instance = new Factory();
        return this.inject(instance);
    }
}
 
// Step 3: Classes implement interfaces as needed
class OrderService implements LoggerInjectable, MetricsInjectable {
    private logger!: Logger;
    private metrics!: MetricsCollector;
    private readonly repository: OrderRepository;
    
    // Constructor for business dependencies
    constructor(repository: OrderRepository) {
        this.repository = repository;
    }
    
    // Interface methods for cross-cutting concerns
    injectLogger(logger: Logger): void {
        this.logger = logger;
    }
    
    injectMetrics(metrics: MetricsCollector): void {
        this.metrics = metrics;
    }
    
    async processOrder(order: Order): Promise<void> {
        const startTime = Date.now();
        this.logger.info(`Processing order ${order.id}`);
        
        await this.repository.save(order);
        
        this.metrics.recordTiming("order.process", Date.now() - startTime);
        this.logger.info(`Order ${order.id} processed`);
    }
}
 
// Step 4: Usage
const injector = new DependencyInjector(
    new WinstonLogger(),
    loadConfig(),
    new PrometheusMetrics()
);
 
// Create with constructor dependency, then inject cross-cutting
const orderService = new OrderService(new PostgresOrderRepository());
injector.inject(orderService);
 
// Now orderService has logger & metrics injected

Combining with Constructor Injection

Testing with Interface Injection

Testing classes that use Interface Injection follows a similar pattern to Setter Injection testing. You must ensure injection methods are called before exercising the class:

testing-interface-injection.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
describe("OrderService with Interface Injection", () => {
    let service: OrderService;
    let mockRepository: jest.Mocked<OrderRepository>;
    let mockLogger: jest.Mocked<Logger>;
    let mockMetrics: jest.Mocked<MetricsCollector>;
    
    beforeEach(() => {
        // Create mocks
        mockRepository = {
            save: jest.fn(),
            findById: jest.fn()
        };
        
        mockLogger = {
            info: jest.fn(),
            error: jest.fn(),
            warn: jest.fn()
        };
        
        mockMetrics = {
            recordTiming: jest.fn(),
            incrementCounter: jest.fn()
        };
        
        // Create service with constructor dependency
        service = new OrderService(mockRepository);
        
        // Call interface injection methods
        service.injectLogger(mockLogger);
        service.injectMetrics(mockMetrics);
    });
    
    describe("processOrder", () => {
        it("should log and record metrics", async () => {
            const order = createTestOrder({ id: "ORD-123" });
            mockRepository.save.mockResolvedValue(undefined);
            
            await service.processOrder(order);
            
            expect(mockLogger.info).toHaveBeenCalledWith(
                "Processing order ORD-123"
            );
            expect(mockMetrics.recordTiming).toHaveBeenCalledWith(
                "order.process",
                expect.any(Number)
            );
        });
    });
    
    describe("without logger injected", () => {
        it("should throw if logger not injected", async () => {
            // Create new service without injecting logger
            const uninitializedService = new OrderService(mockRepository);
            // Don't call injectLogger
            
            await expect(uninitializedService.processOrder(createTestOrder()))
                .rejects.toThrow();
        });
    });
});
 
// Helper to create fully injected service
function createFullyInjectedService(
    repository: OrderRepository
): OrderService {
    const service = new OrderService(repository);
    service.injectLogger(createMockLogger());
    service.injectMetrics(createMockMetrics());
    return service;
}

Using an injector in tests:

Alternatively, create a test injector that provides mock implementations:

test-injector.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// Create a test injector with mocks
function createTestInjector() {
    const mockLogger = createMockLogger();
    const mockConfig = createMockConfig();
    const mockMetrics = createMockMetrics();
    
    const injector = new DependencyInjector(
        mockLogger,
        mockConfig,
        mockMetrics
    );
    
    return {
        injector,
        mocks: {
            logger: mockLogger,
            config: mockConfig,
            metrics: mockMetrics
        }
    };
}
 
// In tests
describe("OrderService via injector", () => {
    it("should use injected mocks", async () => {
        const { injector, mocks } = createTestInjector();
        
        const service = injector.inject(
            new OrderService(createMockRepository())
        );
        
        await service.processOrder(createTestOrder());
        
        expect(mocks.logger.info).toHaveBeenCalled();
    });
});

Injection Patterns Comparison

With all three injection patterns explored, let's consolidate the comparison:

Complete Injection Pattern Comparison
Criterion	Constructor	Setter	Interface
Object readiness	Immediate	After setters called	After interface methods called
Dependency visibility	Explicit in constructor	Scattered setters	Scattered interfaces
Immutability	Easy (readonly fields)	Requires discipline	Requires discipline
Required dependencies	Perfect fit	Needs validation	Needs validation
Optional dependencies	Possible with defaults	Natural fit	Less common
Testing	Simple - pass mocks	Remember to call setters	Remember to call injection methods
Framework detection	Analyze constructor	Naming/annotations	Interface implementation
Primary use case	Business dependencies	Optional/late deps	Framework services

The Decision Guide

Summary: Interface Injection Mastery

Interface Injection completes your dependency injection vocabulary. Let's consolidate the essential knowledge:

Key Takeaways

•Mechanics — An interface defines an injection method. Classes implement the interface to receive the dependency. The injector detects interface implementation.
•vs Setter — The interface standardizes the injection method across all implementing classes, unlike arbitrary setters.
•Framework usage — Common in Spring (*Aware interfaces), Servlets, .NET (IHostedService), and other frameworks for injecting framework services.
•Best suited for — Framework-provided services, cross-cutting concerns, lifecycle callbacks, plugin systems.
•Avoid for — Business dependencies, required dependencies, application-level code. Use Constructor Injection instead.
•Hybrid pattern — Constructor Injection for business dependencies, Interface Injection for framework/cross-cutting concerns.
•Testing — Similar to Setter Injection—ensure injection methods are called before exercising the class.

What's next:

Pattern Recognition Complete

4 / 5