Dependency Injection (DI)

Inversion of Control is the overarching principle behind DI. Instead of a plugin creating or finding its own dependencies (a 'pull' model), the host framework assumes responsibility and 'pushes' dependencies into the plugin at runtime. This inverts the traditional flow of control, making the framework the orchestrator of component lifecycles.

• Framework as Coordinator: The host controls when plugins are instantiated, configured, and provided with their required services.
• Loose Coupling: Plugins are not statically bound to concrete implementations of their dependencies, only to abstractions (interfaces).

The primary goal of DI is to decouple a plugin's core logic from the specific implementations of the services it uses. A plugin declares what it needs (e.g., a DatabaseClient interface), not how to get it.

• Abstraction over Implementation: Plugins depend on stable interfaces or abstract classes.
• Swappable Implementations: The host can inject a real ProductionDatabaseClient or a mock InMemoryDatabaseClient for testing without changing the plugin's code.
• Example: A billing plugin requires a PaymentProcessor. Through DI, it receives a configured StripeProcessor or PayPalProcessor instance, unaware of which one.

Dependencies are not hidden but are explicitly declared by the plugin, typically through its constructor, method parameters, or settable properties. This makes the plugin's requirements clear and enforceable.

• Constructor Injection: Dependencies are provided as parameters to the plugin's constructor. This is the most common and recommended form, guaranteeing the plugin is fully initialized and immutable.
• Setter/Property Injection: Dependencies are assigned via public setter methods or properties after construction. Offers more flexibility but can lead to temporally incomplete states.
• Interface Injection: The dependency provides an injector method that the plugin implements. Less common in modern systems.

The host framework, often with an IoC Container (e.g., Spring, .NET's built-in DI, InversifyJS), acts as a central registry and factory for all injectable objects. It manages the complete object graph.

• Registration: Services (dependencies) are registered with the container against an abstraction (interface).
• Resolution: When a plugin is instantiated, the container automatically resolves and injects all its declared dependencies, recursively resolving their dependencies too.
• Lifecycle Management: The container can manage singleton, scoped, or transient lifetimes for dependencies, ensuring efficient resource use.

DI is a cornerstone of testable software design. By decoupling plugins from concrete dependencies, it becomes trivial to isolate the plugin's logic for unit testing.

• Mock Injection: During tests, a test harness can inject mock or stub implementations of dependencies (e.g., using libraries like Mockito, Moq, or Jest).
• Focus on Unit Logic: Tests can verify the plugin's behavior in response to specific inputs from its dependencies without needing a running database, API, or filesystem.
• Integration Testing: The same mechanism allows for injecting real, but test-configured, implementations for broader integration tests.

DI facilitates the externalization of configuration. How a dependency is configured (e.g., API endpoints, connection strings) is separated from the plugin's code and managed by the host.

• Configuration Injection: The host can inject a Configuration object or specific config values (like API keys) into services before they are provided to plugins.
• Environment Agnosticism: A plugin can run in development, staging, and production environments without code changes; only the injected configuration differs.
• Dynamic Reconfiguration: In some systems, dependencies can be re-injected with new configuration at runtime, supporting dynamic updates.

Inversion of Control is the overarching design principle that DI implements. It inverts the traditional flow of a program: instead of a component creating its own dependencies, a framework or container (the 'host') manages their lifecycle and provides them. DI is the primary mechanism for achieving IoC.

• Framework Control: The host system calls the plugin, not the other way around.
• Hollywood Principle: "Don't call us, we'll call you."
• Foundation for DI: IoC containers are the engines that perform dependency injection.

The Plugin Lifecycle defines the sequence of states a plugin transitions through within a host system. DI is deeply integrated into this lifecycle, particularly during initialization.

• Discovery: The host finds the plugin's manifest.
• Loading: The plugin's code is loaded into memory.
• Initialization (DI Phase): The host's IoC container injects required dependencies into the plugin.
• Execution: The plugin's methods are invoked.
• Deactivation & Unloading: Dependencies are disposed of, and the plugin is removed from memory.

An API Contract is a formal specification that defines the interfaces between a plugin host and its plugins. For DI to work, these contracts must clearly define the service interfaces that plugins depend on.

• Interface Definition: Specifies the methods and properties a service must provide.
• Loose Coupling: Plugins depend on abstract interfaces, not concrete implementations.
• Schema Enforcement: Often defined using Interface Definition Languages (IDL), OpenAPI, or JSON Schema. The DI container uses this contract to resolve the correct implementation to inject.

The Microkernel Pattern is a minimalist architectural style where a tiny, stable core provides only essential services (like communication and plugin loading). All other functionality is implemented as plugins. DI is fundamental for providing these plugins with the core services they need.

• Minimal Core: The kernel is kept as small and simple as possible.
• Plugin Extensibility: All features (file systems, UI, drivers) are plugins.
• Kernel as DI Container: The microkernel often acts as the IoC container, injecting communication buses and other core utilities into the plugins.

A Capability Model is a security architecture where plugins declare the specific system resources or privileges they require. This works in tandem with DI to enforce security policy.

• Declarative Security: A plugin's manifest lists required capabilities (e.g., network_access, write_storage).
• Policy-Driven Injection: The DI container can check a plugin's granted capabilities before injecting a dependency that provides access to a protected resource.
• Sandboxing Enforcement: If a plugin requests a dependency it doesn't have the capability for, injection can be denied or a null/mock object can be provided instead.

A Plugin Dependency Graph is a directed graph that models the dependencies between plugins and services. The DI container uses this graph to resolve the correct order of instantiation and injection.

• Directed Acyclic Graph (DAG): Dependencies flow in one direction to avoid circular dependencies.
• Topological Sorting: The container analyzes the graph to determine which services must be created first.
• Transitive Dependencies: If Plugin A depends on Service B, and Service B depends on Service C, the container must create C, then B, then inject B into A.