views:

128

answers:

1

I have a class which depends on 3 classes, all 3 of which have other classes they rely on. Currently, I'm using a container class to build up all the required classes, inject them into one another and return the application.

The simplified version of the container looks something like this:

class Builder
{
    private $_options;

    public function __construct($options)
    {
        $this->_options = $options;
    }

    public function build()
    {
         $cache = $this->getCache();
         $response = $this->getResponse();
         $engine = $this->getEngine();

         return new Application($cache,$response,$engine);
    }

    public function getResponse()
    {
         $encoder = $this->getResponseEncoder();
         $cache = $this->getResponseCache();

         return new Response($encoder,$cache);
    }

    // Methods for building each object
}

I'm not sure if this would be classified as FactoryMethod or a DI Container. They both seem to solve the same problem in the same way - They build objects and inject dependencies. This container has some more complicated building methods, like loading observers and attaching them to observable objects.

Should factories be doing all the building (loading extensions etc) and the DI container should use these factories to inject dependencies? That way the sub-packages, like Cache, Response etc, can each have their own specialised factories.

+1  A: 

A DI Container is definitely a Factory, but it's a general-purpose factory.

However, if you use it in a pull-based way by asking it to create dependencies for you every time you need them, you would be employing the Service Locator anti-pattern. That's just a general-purpose factory and actually has little to do with DI.

True Dependency Injection is, as the name implies, push based. You write all your code using simple patterns like Constructor Injection, and use the DI Container to resolve your entire dependency graph in one go in the application's Composition Root, injecting all dependencies into their respective consumers.

Mark Seemann