Channels ▼

Christopher Diggins

Dr. Dobb's Bloggers

Dependency Injection and Policy Based Design

July 16, 2008

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 ( 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;
  MyOtherClass(int x) : m(x) { }
  int DoSomething() { return m + 1; }

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

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

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

class MyOtherClass : AbstractMyOtherClass {
  int m;
  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;
  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 {
  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 {
  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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.