The Dependency Inversion Principle (DIP) serves as a conceptual guideline for decoupling software modules, while Dependency Injection (DI) acts as the concrete technique to apply this concept. By combining these two patterns, developers can create systems that are easier to maintain, test, and extend.

The Dependency Inversion Principle

Central to robust software architecture is the reduction of coupling between components. The Depandency Inversion Principle asserts that high-level modules—which contain business logic—should not depend directly on low-level modules—which implement mechanical details. Instead, both should rely on abstractions.

Consider a scenario where a ReportGenerator class is responsible for processing data and needs to save the output to a specific medium. A naive implemantation might look like this:

public class ReportGenerator
{
    private CsvFileWriter _writer;

    public void Generate()
    {
        try
        {
            // ... data processing logic
        }
        catch (Exception ex)
        {
            if (_writer == null)
            {
                _writer = new CsvFileWriter();
            }
            _writer.SaveError(ex.Message);
        }
    }
}

public class CsvFileWriter
{
    public void SaveError(string errorMessage)
    {
        // Code to write error to a CSV file
    }
}

In this example, the high-level ReportGenerator is tightly coupled to the low-level CsvFileWriter. If the requirement changes to save errors to a remote database or send them via an API, the ReportGenerator class must be modified, violating the Open/Closed Principle.

To adhere to DIP, we introduce an abstraction layer, typically an interface, that defines the contract for the behavior:

public class ReportGenerator
{
    private IErrorSink _sink;

    public void Generate()
    {
        try
        {
            // ... data processing logic
        }
        catch (Exception ex)
        {
            if (_sink == null)
            {
                // The choice of implementation is still hardcoded here
                _sink = new CsvFileWriter(); 
                // _sink = new DatabaseLogger();
            }
            _sink.SaveError(ex.Message);
        }
    }
}

public interface IErrorSink
{
    void SaveError(string errorMessage);
}

public class CsvFileWriter : IErrorSink
{
    public void SaveError(string errorMessage)
    {
        // Implementation for file storage
    }
}

public class DatabaseLogger : IErrorSink
{
    public void SaveError(string errorMessage)
    {
        // Implementation for database storage
    }
}

Now, ReportGenerator depends on the IErrorSink abstraction. While this decouples the classes, note that the concrete instantiation (new CsvFileWriter()) still happens inside the high-level module. To completely externalize the creation logic and allow for runtime flexibility, we use Dependency Injection.

Dependency Injection Patterns

Dependency Injection involves supplying a dependency from the out side rather than creating it internally. There are three primary methods to achieve this:

1. Constructor Injection

This is the most common approach, where the dependency is provided through the class constructor. It ensures that the object is never in an invalid state without its dependencies.

public class ReportGenerator
{
    private readonly IErrorSink _sink;

    // The dependency is injected via the constructor
    public ReportGenerator(IErrorSink sink)
    {
        _sink = sink;
    }

    public void Generate()
    {
        try
        {
            // ... logic
        }
        catch (Exception ex)
        {
            _sink.SaveError(ex.Message);
        }
    }
}

// Usage:
// var generator = new ReportGenerator(new DatabaseLogger());

This method makes the dependency immutable and explicit for the entire lifetime of the instance.

2. Method Injection

In this pattern, the dependency is passed as an argument to the method that requires it. This is useful when the dependency is only needed for a specific operation or varies between calls.

public class ReportGenerator
{
    public void Generate(IErrorSink sink)
    {
        try
        {
            // ... logic
        }
        catch (Exception ex)
        {
            // Use the passed sink
            sink.SaveError(ex.Message);
        }
    }
}

// Usage:
// var generator = new ReportGenerator();
// generator.Generate(new CsvFileWriter());
// generator.Generate(new DatabaseLogger());

3. Property Injection

Also known as Setter Injection, this involves exposing a public property to set the dependency. It offers more flexibility than constructor injection but can lead to an object being in an incomplete state if the property is not set before use.

public class ReportGenerator
{
    private IErrorSink _sink;
    
    public IErrorSink ErrorSink
    {
        get { return _sink; }
        set { _sink = value; }
    }

    public void Generate()
    {
        try
        {
            // ... logic
        }
        catch (Exception ex)
        {
            if (_sink != null)
            {
                _sink.SaveError(ex.Message);
            }
        }
    }
}

// Usage:
// var generator = new ReportGenerator();
// generator.ErrorSink = new CsvFileWriter();

These three strategies can be combined within a single system. For instance, a primary dependency might be injected via the constructor, while optional or context-specific dependencies are injected via properties or methods.

It is worth noting that in languages like C# or .NET, abstractions do not strictly require interfaces; delegates can also be used to define contracts. For example, passing an Action or a callback function represents a form of method injection.