Dependency Injection and Policy Based Design - InformationWeek
IoT
IoT
Software // Enterprise Applications
Commentary
7/16/2008
12:00 AM
Commentary
Commentary
Commentary
50%
50%
RELATED EVENTS
[Ransomware] Taking the Mystery out of Ransomware
Dec 07, 2016
Lost data. Systems locked down. Whole companies coming to a grinding halt. When it comes to ransom ...Read More>>

Dependency Injection and Policy Based Design

I believe that one indicator that an approach or technique is a good idea is that it appears in multiple contexts or gets invented simultaneously by different people. The dependency injection pattern is an example of this because of its similarity to policy-based design. This helps reinforce my feelings that both approaches are worthwhile techniques for reducing code coupling.

I believe that one indicator that an approach or technique is a good idea is that it appears in multiple contexts or gets invented simultaneously by different people. The dependency injection pattern is an example of this because of its similarity to policy-based design. This helps reinforce my feelings that both approaches are worthwhile techniques for reducing code coupling.

I recently came upon this post (http://skepticalmethodologist.wordpress.com/dependency-injection-in-c/) describing the dependency injection pattern in C++ as ported from Java. The dependency injection pattern uses abstract classes and factories rather than concrete classes within a class to reduce coupling and improve the flexibility of a design.

Here is an example of where we might want to use the dependency injection pattern. First is the straightforward approach to implementing a class that uses another concrete class as a field.

class MyOtherClass {
  int m;
public:
  MyOtherClass(int x) : m(x) { }
  int DoSomething() { return m + 1; }
}; 

class MyClass {
  MyOtherClass m;
public:
  MyClass() : m(42) { }
  int DoSomething() { return m.DoSomething(); }
};

Now here is an dependency injection pattern ported naively from Java:

class AbstractMyOtherClass {
public:
  virtual int DoSomething() = 0;
  virtual ~AbstractMyOtherClass() { delete(m); }
};

class MyOtherClass : AbstractMyOtherClass {
  int m;
public:
  MyOtherClass(int x) : m(x) { }
  int DoSomething() { return m + 1; }
};

class MyOtherClassFactory {
  AbstractMyOtherClass* Create(int x) {
    return new MyOtherClass(x);
  }
};

struct MyClass {
  boost::scoped_ptr<AbstractMyOtherClass> m;
 public:
  MyClass(MyOtherClassFactory x)  : m(x.Create(42)) { }
  int DoSomething() { return m->DoSomething(); }
}

So why not a boost::shared_ptr you might ask? Well you should use it only if you must. Ownership in this case is very clearly linked to "MyClass", and this is where it should stay. Using boost::shared_ptr would be adding an undue ambiguity (i.e. when does the object get deleted) to your implementation.

So we now have an example of the dependency injection pattern. There are however some rather large problems with this new design: we needed to add an object factory (MyOtherClassBuilder) and an abstract base class (AbstractMyOtherClass). I don't think that that is acceptable, because it requires too much scaffolding code just to reduce a little bit of coupling. We are passing the point of diminishing returns.

This approach though points naturally to the following improved implementation:

template<typename Field = MyOtherClass, typename Factory = DefaultFactory<Field> >
class MyClass {
public:
  boost::scoped_ptr<Field> m;
  MyClass() : m(Factory().Create(42)) { }
  int DoSomething() { return m->DoSomething(); }
};

This is a very flexible design and doesn't require a substantial rewriting of existing code. I find it interesting that it is also essentially the same approach used in the STL for the standard collections, where they call the factory an allocator. The following simple implementation of DefaultFactory can be used for a large number of cases:

template<typename T>
struct DefaultFactory {
  T* Create() { return new T(); }
  template<typename U>
  T* Create(U x) { return new T(x); }
  // ...
  // add more versions of Create as needed
};

With C++ 0x we will be able to make an even better DefaultFactory class by resolving the forwarding problem using variadic template parameters.

To make this a more clear example of Policy based design, we would use a single policy template parameter that combines the other effect. For example:

struct DefaultPolicy {
  typedef MyOtherClass Field;
  typedef DefaultFactory<Field> Factory;
};

template<typename Policy = DefaultPolicy>
class MyClass {
public:
  boost::scoped_ptr<Field> m;
  MyClass() : m(Factory().Create(42)) { }
  int DoSomething() { return m.DoSomething(); }
};

So that's my approach to performing dependency injection using policy-based design. This is a bit of an oversimplification and surely contains several errors (my C++ is really rusty). I would be interested in hearing suggestion on different ways we can improve the code or design, and still achieve a benefit of reducing coupling between classes.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
How Enterprises Are Attacking the IT Security Enterprise
How Enterprises Are Attacking the IT Security Enterprise
To learn more about what organizations are doing to tackle attacks and threats we surveyed a group of 300 IT and infosec professionals to find out what their biggest IT security challenges are and what they're doing to defend against today's threats. Download the report to see what they're saying.
Register for InformationWeek Newsletters
White Papers
Current Issue
Top IT Trends to Watch in Financial Services
IT pros at banks, investment houses, insurance companies, and other financial services organizations are focused on a range of issues, from peer-to-peer lending to cybersecurity to performance, agility, and compliance. It all matters.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
Join us for a roundup of the top stories on InformationWeek.com for the week of November 6, 2016. We'll be talking with the InformationWeek.com editors and correspondents who brought you the top stories of the week to get the "story behind the story."
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.
Flash Poll