Sie sind auf Seite 1von 10

The Dependency Injection Pattern What is it and why do I care?

? A couple of weeks ago I wrote about using the Inversion of Control (IoC) principle to create classes that are easier to unit test. One major thing I left out of that post was using the Dependency Injection pattern to loosely couple classes from their dependencies. In a nutshell, dependency injection just means that a given class or system is no longer responsible for instantiating their own dependencies. In this case Inversion of Control refers to moving the responsibility for locating and attaching dependency objects to another class or a DI tool. That might not sound that terribly profound, but it opens the door for a lot of interesting scenarios.

While theres a fair amount of unnecessary buzz and hype about the concept, Ive found Dependency Injection to be very advantageous for doing Test Driven Development without pulling your hair out. If youve seen articles or blog posts about Dependency Injection but dont quite internalize the value of DI yet, here are the facts as I see them:

1.

Dependency Injection is an important pattern for creating classes that are easier to unit test in isolation

2. 3. 4. 5.

Promotes loose coupling between classes and subsystems Adds potential flexibility to a codebase for future changes Can enable better code reuse The implementation is simple and does *not* require a fancy DI tool

The PicoContainer team even has silly tee shirts printed up that say I expected a paradigm shift, but all I got was a lousy constructor function. DI is certainly a case where a minimum of effort supplies quite a bit of benefit. Dont blow it off just because it seems trivial.

There are tools out there that do Dependency Injection in .Net. I use my own tool called StructureMap in my development, but Im going to focus on only the concept of DI in this post.

Example Problem My first experience with conscious usage of DI was a WinForms client communicating with the backend via web services that was built with the Model View Presenter (Humble Dialog Box) architecture for easier unit testing. Most screens in the client end up with something like this set of classes:

Model Whatever business object/DataSet/chunk of data is being displayed or edited View A WinForms UserControl class. Displays data to a user and captures user input and screen events (duh).

Service A web service proxy class to send requests to the backend Presenter The controller class that coordinates all of the above.

The presenter class without Dependency Injection might look like this.

public class Presenter { private View _view; private Model _model; public Presenter(){} public object CreateView(Model model) { _model = model; _view = new View(); _view.DisplayModel(model); return _view; } public void Close() { bool canClose = true; if (_view.IsDirty()) { canClose = _view.CanCloseDirtyScreen(); } if (canClose) { _view.Close(); } } public void Save() { Service service = new Service(); service.Persist(_model); } }

This code cannot be unit tested in isolation because it has a tight coupling to a concrete implementation of both the WinForms UserControl (View) and the proxy class to a web service (Service). This code as is cannot function without both the User Interface and a web server running the backend. The point of

using the MVP is to isolate most of the user interface logic away from the WinForms and web service mechanics to enable effective unit testing, so were missing something here. To unit test the presenter logic wed like to replace the user interface and web service dependencies with a Mock object inside our test fixture classes. In order to mock the view and service, we first need to use the Dependency Inversion Principle to make the Presenter class depend on an abstracted IView and IService interface instead of the concrete UserControl and WebProxy classes. The next thing to do is to alter thePresenter class so that we can substitute at run time the mock objects instead of the concrete classes within the unit tests. This is where Dependency Injection comes into play.

There are a couple of different flavors of Dependency Injection (via Martin Fowler + the Pico guys)

1. 2.

Constructor Injection Attach the dependencies through a constructor function at object creation Setter Injection Attach the dependencies through setter properties Interface Injection This is an odd duck. Ive never used it or seen this used. I suspect its usage is driven by specific DI tools in the Java world.

3. 4.

Service Locator Use a well known class that knows how to retrieve and create dependencies. Not technically DI, but this is what most DI/IoC container tools really do.

Constructor Injection My preference is to use the Constructor Injection flavor of DI. The mechanism here is pretty simple; just push the dependencies in through the constructor function.

public class Presenter { private IView _view; private Model _model; private IService _service; public Presenter(IView view, IService service) { _view = view;

_service = service; } public object CreateView(Model model){} public void Close(){} public void Save(){} }

[TestFixture] public class PresenterTestFixture { private IMock _serviceMock; private IMock _viewMock; private Presenter _presenter;

[SetUp] public void SetUp() { // Create the dynamic mock classes for IService and IView _serviceMock = new DynamicMock(typeof(IService)); _viewMock = new DynamicMock(typeof(IView)); // Create an instance of the Presenter class using the mock objects _presenter = new Presenter((IView) _viewMock.MockInstance,

(IService) _serviceMock.MockInstance); } }

One of the benefits of using Constructor Injection is that the constructor function now explicitly declares the dependencies of a class. I also thing Constructor Injection makes it easier for other developers to use your class because it expresses a contract. Give the class what it needs in its constructor function and it should be ready to function. Its usually a best practice to create a valid object in as few steps as possible for ease of use. Using Constructor Injection also allows you to maintain more encapsulation by eliminating the need to expose getter and setter properties for dependencies like the IService interface that are immutable.

Exposing the dependencies in a constructor function is arguably a violation of encapsulation because now a client of Presenter would have to create instances ofIView and IService first before calling the constructor function. To get around this issue I usually suggest a compromise. Create a second no argument constructor that builds the default instances for clients of Presenter to use. The full constructor is usually commented as a testing constructor. Some people think this pattern is evil redundancy, but it gets the job done.

// Testing constructor public Presenter(IView view, IService service) { _view = view; _service = service; } // Default constructor public Presenter() : this(new View(), new Service()){}

Setter Injection Setter injection is just creating a setter property to replace a dependency on a previously instantiated object. I dont like Setter Injection because it requires extra, hidden steps to prepare an object to execute. Ive been burned a couple times in the last year when Ive inherited some code that depended on setters to set up dependencies. That being said, Setter Injection does work and is often necessary when youre dealing with existing code. Michael Feathers recommends using Setter Injection as a dependency breaking technique for legacy code when a dependency is too difficult to expose through a constructor.

Heres the Presenter class using Setter Injection.

public class Presenter { private IView _view; private Model _model; private IService _service; public Presenter() { _view = new View(); _service = new Service();

} public IView View { get { return _view; } set { _view = value; } }

public IService Service { get { return _service; } set { _service = value; } }

public object CreateView(Model model){} public void Close(){} public void Save(){} }

[TestFixture] public class PresenterTestFixture { private IMock _serviceMock; private IMock _viewMock; private Presenter _presenter;

[SetUp] public void SetUp() { // Create the dynamic mock classes for IService and IView _serviceMock = new DynamicMock(typeof(IService)); _viewMock = new DynamicMock(typeof(IView));

// Create an instance of the Presenter class _presenter = new Presenter();

// Attach the Mock objects

_presenter.View = (IView) _viewMock.MockInstance; _presenter.Service = (IService) _serviceMock.MockInstance; } }

Heres a variation on Setter Injection Ive seen other teams use. In the getter of the property, just create the default instance of the dependency if it hasnt been created. I dont like this approach because it hides the dependencies of a class. I think this is creating Mystery Meat dependencies and brittle code. In practice I thought that this made it difficult to retrofit unit tests into existing code. Of course, retrofitting unit tests onto existing code is always hard so maybe thats really not a drawback.

// Always access the _view field through the Property public IView View { get { if (_view == null) { _view = new View(); } return _view; } set { _view = value; } }

Service Locator An alternative to using Dependency Injection is to use a Service Locator to fetch the dependency objects. Using a Service Locator creates a level of indirection between a class and its dependencies. Heres a version of the Presenter class that gets its IViewand IService dependencies by asking StructureMaps ObjectFactory class for the default type and configuration of IView and IService. While it is generally possible to use the Service Locator to return mock or stub objects inside test fixtures, I would still prefer to leave a testing constructor so the unit tests can be simpler. I find that using a Service Locator within a unit test can be confusing because its not clear where the mock object is used.

public class Presenter

{ private IView _view; private Model _model; private IService _service;

public Presenter() { // Call to StructureMap to fetch the default configurations of IView and IService _view = (IView) StructureMap.ObjectFactory.GetInstance(typeof(IView)); _service = (IService) StructureMap.ObjectFactory.GetInstance(typeof(IService)); } public object CreateView(Model model){} public void Close(){} public void Save(){} }

Ive seen several teams go their own way to create custom Service Locators, usually with a Singleton like this.

public class ServiceFactory { private static IService _instance = new Service(); private ServiceFactory(){} public static IService GetInstance() { return _instance; }

// Used to register mock or stub instances in place of // the concrete Service class public static void RegisterInstance(IService instance) { _instance = instance; }

I detest this pattern and Ive been eliminating this from my teams primary product. There are just too many opportunities to screw up your tests by not having isolated unit tests. Its also unnecessary because there are existing tools specifically for this.

Good for More than Unit Testing Ive focused almost entirely on the value of Dependency Injection for unit testing and Ive even bitterly referred to using DI as Mock Driven Design. Thats not the whole story though. One of original usages for Dependency Injection was to provide smoother migration paths away from legacy code. One evolutionary approach to replacing legacy code is the Strangler approach. Making sure that any new code that depends on undesirable legacy code uses Dependency Injection leaves an easier migration path to eliminate the legacy code later with all new code.

public interface IDataService{}

// Now public class ProxyToNastyLegacyDataService : IDataService{}

// Later public class CleanNewCodeDataService : IDataService{}

public class StranglerApplication { public StranglerApplication(IDataService dataService){} }

Another benefit of Dependency Injection is increasing the potential for reuse later. Going back to the MVP architecture, what if you need to replace the heavy WinForms client with an ASP.NET system? The View is obviously useless, and I think its probably silly to use a Web Service when a local class will do for theIService implementation. We can potentially reuse the Presenter class; just inject a different implementation for both IView and IService.

public class ASPNetView : System.Web.UI.UserControl, IView {

public class LocalService : IService { }

public class WebClientMasterController { public void CreateView(Page page) { ASPNetView view = (ASPNetView) page.Controls[0]; Model model = this.GetModel(); IService service = new LocalService(); // Presenter can work with a different concrete implementation of // IView and IService Presenter presenter = new Presenter(view, service); presenter.CreateView(model); }

public Model GetModel(){return new Model();} }

Using a Dependency Injection Tool

Using Dependency Injection potentially adds some overhead to using the classes that dont create their own dependencies. This is where one of the Dependency Injection tools can pay large dividends by handling this mechanical work and creating some indirection between clients and dependencies. The next (and last) post in the whole Inversion of Control chain will look at using a Dependency Injection tool to wire up an application.

Das könnte Ihnen auch gefallen