title: Dependency injection in factories
body: <p>I'm really new to DI, but I really want to try using it.</p>
  
  <p>There's something I don't understand. Here's a simple pseudocode of a factory, I'm using a lot.</p>
  
  <pre><code>class PageFactory {
     public function __construct(/* dependency list */) {
        ... //save reference to the dependencies
     }
  
     public function createPage($pagename) {
         switch ($pagename) {
             case HomePage::name:
                 return new HomePage(/* dependency list */);
             case ContactPage::name:
                 return new ContactPage(/* dependency list */);
             ...
             default:
                 return null;
         }
     }
  }
  </code></pre>
  
  <p>It has a really simple logic, it chooses the implementation instance based on a string. It's very useful, because I can choose at a later time what page I need, and only that one will be created.</p>
  
  <p><strong>How would I rewrite this code, so my page instances would be created by a dependency container, thus I wouldn't need to handle dependencies for the factory and the pages it creates?</strong></p>
  
  <p>The only solution I see is to make the container I want to use, a dependency for the factory, and make calls to it from within the factory. I have lot's of problem with that.</p>
  
  <p>First, I don't want to couple the container into my application, and every factory it has.</p>
  
  <p>Second, and my biggest problem is, that the call for the container is really messy, it's stringly typed (i.e. <em>$container->get(<strong>'Foo'</strong>);</em>). I would like to use it as few times as possible. Only once if possible.</p>
  
  <p><strong>EDIT:</strong></p>
  
  <p>I do not want to write a DI container. I want to use an existing one. My question is on usage. How would I use a DI container instead or within the above factory, while keeping the logic on instance selection.</p>
  
  <p><strong>EDIT 2:</strong></p>
  
  <p>I started using <a href="https://r.je/dice.html" rel="noreferrer">Dice</a> as the DI container, because it's lightweight, and knows everything I need. I would prefer if I could use it in a single place and build up the whole application. For that, I'll need a way to get rid of these factories somehow, or modify it in some way to make those pages behave like dependencies, so the DI container would provide instances to them.</p>
  
  <p><strong>EDIT 3:</strong></p>
  
  <p>Yes, I need this for testing purposes. I'm also new to testing, but it is very awesome so far, I really like it.</p>
  
  <p>These pages are what MVC frameworks call controllers. But all the MVC frameworks I checked out are not making their controllers testable, because they create instances of them automatically. And because they are created by the system, their constructor parameters are not customizable by the user. </p>
  
  <p>There is a simple way to check this for any framework. I just look up the way I should use a database in a controller in that specific framework. Most frameworks are either procedural, or use some service locator, either way, they are getting their dependencies from public scope, something I do not want to do. This is why I'm not automating the controller instantiation. The downside is that I now have these weird factories, which carry a lot of dependencies. And I would like to substitute this task to a DI container.</p>
  
  <p>Most frameworks implement their own testing mechanism, which are more like functional testing, instead of unit testing, but I do not want to do that either.</p>