CiviCRM Community Forums (archive)

In the past few years, the "dependency injection" pattern ( http://en.wikipedia.org/wiki/Dependency_injection ) has caught on in PHP. I think one can fairly summarize DI as the difference between these two snippets:

<?php
// FILE: Example/NewsWidget.php
namespace Example;
class NewsWidget {
  function render() {
    $http = new HttpClient();
    $response = $http->get('http://example.com/news.json');
    if ($response->isOK()) {
      $templateEngine = new SmartyTemplateEngine();
      echo $templateEngine->render('news', json_decode($response->getContent()));
    }
  }
}

// FILE: Example/HttpClient.php
namespace Example;
class HttpClient {
  function get($url) {
    $resp = new Response(file_get_contents($url));
    // ...check for errors; add to $resp ...
    return $resp;
  }
}

and

<?php
// FILE: Example/NewsWidget.php
namespace Example;
class NewsWidget {
  protected $http;
  protected $templateEngine;

  function __construct(HttpInterface $http, TemplateInterface $templateEngine) {
    $this->http = $http;
    $this->templateEngine = $templateEngine;
  }

  function render() {
    $response = $this->http->get('http://example.com/news.json');
    if ($response->isOK()) {
      echo $this->templateEngine->render('news', json_decode($response->getContent()));
    }
  }
}

// FILE: Example/HttpClient.php
namespace Example;
class HttpClient implements HttpInterface {
  function get($url) {
    $resp = new Response(file_get_contents($url));
    // ...
    return $resp;
  }
}

// FILE: services.yml
service:
  httpClient:
    class: \Example\HttpClient
  templateEngine:
    class: \Example\SmartyTemplateEngine
  newsWidget:
    class: \Example\NewsWidget
    arguments: [ '@httpClient', '@templateEngine']

This has some trade-offs.
 + Pro: It's easier to swap and reconfigure the parts (like HttpClient and SmartyTemplateEngine) without changing NewsWidget. The new structure is great for testing with mock objects ( http://phpunit.de/manual/3.7/en/test-doubles.html ). For example, you can write test-cases with a mock HTTP client that returns HTTP 200 (with valid JSON), HTTP 200 (with malformed JSON), HTTP 404, etc (depending on the particular test-case). This is easier, faster, more portable than setting up a real HTTP server to simulate the various responses.
 + Con: We've added a new file and +12 lines of "wiring" code (which "wires together" the news widget, the http client, and the template-engine). That's a 50% increase -- more files, more SLOC, more boilerplate, more cross-referencing, less cohesion.

Of course, this changes a bit depending on which "dependency injection" implementation is used. Symfony's dependency-injection system gets it to this level -- its encourages flexible, testable code but requires more boilerplate. Other application frameworks use "auto-wiring" which makes the "services.yml" file optional. A configuration file can be used for advanced situations, but for typical situations one uses annotations instead:

<?php
// FILE: Example/NewsWidget.php
namespace Example;
class NewsWidget {
  /**
   * @Inject("httpClient")
   */
  protected $http;

  /**
   * @Inject("templateEngine")
   */
  protected $templateEngine;

  function render() {
    $response = $this->http->get('http://example.com/news.json');
    if ($response->isOK()) {
      echo $this->templateEngine->render('news', json_decode($response->getContent()));
    }
  }
}

// FILE: Example/HttpClient.php
namespace Example;

/**
 * @Service("httpClient")
 */
class HttpClient implements HttpInterface {
  function get($url) {
    $resp = new Response(file_get_contents($url));
    // ...
    return $resp;
  }
}

The annotations specify how to "wire together" services in a normal situation. The @Service annotation tells the auto-wiring service to make an instance of \Example\HttpClient called "httpClient"; then the @Inject annotation tells the auto-wiring service to put a reference to "httpClient" in the NewsWidget::$http property. However, you don't have to use these defaults: for example, when writing a unit-test with a mock HTTP service, you can inject the mock HTTP service. So you get the same flexibility without fewer files and less boilerplate.

There appear to be some addons for Symfony which enable autowiring. I haven't used/tested them yet:
 - http://jmsyst.com/bundles/JMSDiExtraBundle/master/usage
 - https://github.com/kutny/autowiring-bundle

I think it would be great to introduce DI with autowiring to Civi 5.0.

Hi,

Could extensions benefit from DI too?
Eg a mailchimp/sendgrid extension injecting itself as the mail delivery service or the bounce processing one?

relevant discussion on D8 about DI and services

https://drupal.org/node/2133171

Sorry, should have clarified, my point was that that pattern as implemented would be awesome if it could allow extensions to replace a core service.