Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Basically, instead of having your objects creating a dependency or asking a factory object to make one for them, you pass the needed dependencies in to the object externally, and you make it somebody else's problem. This "someone" is either an object further up the dependency graph, or a dependency injector (framework) that builds the dependency graph. A dependency as I'm using it here is any other object the current object needs to hold a reference to.</p> <p>One of the major advantages of dependency injection is that it can make testing lots easier. Suppose you have an object which in its constructor does something like:</p> <pre class="lang-csh prettyprint-override"><code>public SomeClass() { myObject = Factory.getObject(); } </code></pre> <p>This can be troublesome when all you want to do is run some unit tests on SomeClass, especially if myObject is something that does complex disk or network access. So now you're looking at mocking myObject but also somehow intercepting the factory call. Hard. Instead, pass the object in as an argument to the constructor. Now you've moved the problem elsewhere, but testing can become lots easier. Just make a dummy myObject and pass that in. The constructor would now look a bit like:</p> <pre class="lang-csh prettyprint-override"><code>public SomeClass (MyClass myObject) { this.myObject = myObject; } </code></pre> <p>This is one style of dependency injection - via the constructor. Several mechanisms are possible. </p> <ul> <li>As noted in the comments, one common alternative is to define a do-nothing constructor, and have the dependencies injected via property setters (h/t @MikeVella). </li> <li><a href="http://martinfowler.com/articles/injection.html#InterfaceInjection" rel="noreferrer">Martin Fowler</a> documents a third alternative (h/t @MarcDix), where classes explicitly implement an interface for the dependencies they wish injected.</li> </ul> <p>When not using dependency injection (such as in classes that do too much work in their constructors etc.), it tends to become much harder to isolate components in unit testing. </p> <p>Back in 2013 when I wrote this answer, this was a major theme on the <a href="http://googletesting.blogspot.com/" rel="noreferrer">Google Testing Blog</a>. This remains the biggest advantage to me, as you may not always need the extra flexibility in your run-time design (for instance, for service locator or similar patterns), but you do often need to be able to isolate your classes during testing.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload