4. Dependency Injection

4.1. Overview

The service locator works well when there are few dependencies, and the dependency graph is not very deep. However, it has a few drawbacks:

  1. It requires each object to accept the locator as a parameter, and to know how to use it. This is problematic if you want to use existing classes that were created without knowledge of a locator. (I.e., Logger, in the Ruby library).
  2. It requires each object to know what the services are named, in the locator. If you ever decide to change the name of a service in the locator, you may have to change lots of code to comply with the change.
  3. For deep dependency graphs, it can become cumbersome to have to pass the locator to each constructor.

This is where dependency injection comes in. It allows you to define how each service is initialized, including setting dependencies (either via constructor parameters or via property accessors). In fact, it can do a lot more than that, even allowing you to specify how the lifestyle of the service should be managed and hooking “interceptors” onto the service to filter method invocations.

4.2. Setup

Setting up for DI is very similar to the setup for a service locator, but instead of passing the locator (we’ll call it a registry now), we only pass (or set) the dependencies that the service itself needs.

Dependency injection example [ruby]
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
require 'needle'

def create_application
  registry = Needle::Registry.define do |b|
    b.view          { View.new }
    b.logger        { Logger.new }
    b.database      { Database.new( b.logger ) }
    b.authenticator { Authenticator.new(b.logger, b.database) }
    b.session       { Session.new(b.logger, b.database) }

    b.app do
      app = Application.new
      app.logger = b.logger
      app.view = b.view
      app.database = b.database
      app.authenticator = b.authenticator
      app.session = b.session
      app
    end
  end

  registry[:app]
end

class Application
  attr_writer :view, :logger, :database, :authenticator, :session
end

class Session
  def initialize( logger, database )
    @database = database
    @logger = logger
  end
end

...

The create_application method is now (necessarily) a little more complex, since it now contains all of the initialization logic for each service in the application. However, look how much simpler this made the other classes, especially the Application class.

Now, each class no longer even needs to care that it is being initialized via another container. All it knows is that when it is created, it will be given each of its dependencies (either as constructor parameters or as property accessors).