Dependency Injection - Part Four -Embracing Abstraction

Introduction

 

Now that we have the answer to our question "why loosely coupled code?", let's try and solve the problems we found in a tightly coupled application. In this post, we will use constructor based dependency injection, however we are not going to use any DI container for now.

• Dependency Injection - Part One -Tightly Coupled Application
• Dependency Injection - Part Two - Five Reasons To Write Loosely Coupled Code
• Dependency Injection - Part 3 - Implicit Vs Explicit Dependencies

Dependency Injection

 

Dependency Injection (DI) is a technique that helps us achieve loose coupling between objects and their collaborators. In general, we refer to these collaborators as dependencies for an object. In order to achieve loose coupling, we must follow the golden rule of "not newing" our dependencies in the class, or refrain from having too many static references in our code.

 

With this in mind, classes will declare their dependencies via their constructor following the Explicit Dependency Pattern. This approach is known as "constructor injection".

 

Example

 

To demonstrate the concept, we will be using a very simple application with the following component.

• Order - represents an order placed by the user
• Commerce - accepts an Order and uses other components to process it
• PaymentProcessor - processes the user payment
• CurrencyConverter - converts the paid amount into local currency
• NotificationManager - notifies the user about the order confirmation
• Logger - logs errors (like transaction failure)

public class Program
{
    Order customerOrder = new Order { Id = 1, ProductName = "Product", Quantity = 3, UnitPrice = 75 };

    Commerce commerce = new Commerce(new CreditCardProcessor(new CurrencyConverter()),
                                     new EmailNotifier(), new TextLogger());
    commerce.ProcessOrder(customerOrder);
}

public class Commerce
{
    private PaymentProcessor _paymentProcessor;
    private NotificationManager _notificationManager;
    private Logger _logger;

    public Commerce(PaymentProcessor paymentProcessor, NotificationManager notificationManager, Logger logger)
    {
        _paymentProcessor = paymentProcessor;
        _notificationManager = notificationManager;
        _logger = logger;
    }

    public void ProcessOrder(Order order)
    {
        decimal paidAmount = order.UnitPrice * order.Quantity;
        bool paymentSuccessful = _paymentProcessor.ProcessPayment(paidAmount);

        if(paymentSuccessful)
        {
            _notificationManager.NotifyCustomer(notification: "payment successful");
        }
        else
        {
            _notificationManager.NotifyCustomer(notification: "payment failed");
            _logger.Log(errorMessage: "payment failed");
        }
    }
}

In our application, the Commerce class has an Order from the customer. In order to process the Order, it requires three collaborators, that is to say, it has a dependency on three other classes.

 

As can be seen in the above code, the Commerce class exposes all its dependencies via its constructor. Consequently, at the time of instantiating its object, the User class will be aware of all the requirements of Commerce class. Moreover, this is known as Constructor Injection, as the User class will provide all the dependencies via a constructor.

 

The Problem

 

In this instance, if we look at our application, everything looks just fine. Why? Because we have our components well separated from each other. Also, all our classes follow the Single Responsibility Principle. None of the collaborators is tightly coupled with the Commerce class, rather all of them are injected via its constructor.

 

However, if we notice we are still instantiating the dependencies for Commerce class in the Program class. While it doesn't seem to be a problem in such a small application, we will surely end up in trouble as the level of dependencies increases.

 

Summary

 

In this article, we have seen how we can achieve loose coupling using interfaces in place of concrete classes. However, it gets difficult to maintain such an application as the level of dependencies increases. Instead of instantiating the dependencies on our own, we require someone else to do this for us and provide them whenever and wherever required. Thankfully, a DI Container does that for us. It is a DI container that instantiates and provides the dependencies.