title: IoC Factory: Pros and contras for Interface versus Delegates
body: <p>Any place where you need a run-time value to construct a particular dependency, Abstract Factory is the solution.</p>
  
  <p>My qestion is: Why do many sources favor FactoryInterface over FactoryDelegate to implement this pattern?
  What are the pros and contras for both solutions?</p>
  
  <p>Here is an example to understand what i mean</p>
  
  <p>If you have a Service that needs a Repository with a certain Context then the Service constructor
  needs a factory to create or access its repository. </p>
  
  <p>The common solution for this is to create a <strong>RepositoryFactoryInterface</strong> like this.</p>
  
  <pre><code>public IRepositoryFactory {
      IRepository Create(ContextInformation context);
  }
  
  public class MyService {
      private IRepositoryFactory repositoryFactory;
      public MyService(IRepositoryFactory repositoryFactory)
      {
          this.repositoryFactory = repositoryFactory:
      }
  
      public void DoSomeService()
      {
          ContextInformation context = ....;
  
          IRepository repository = this.repositoryFactory.Create(context);
  
          repository.Load(...);
          ...
          repository.Save(...);
      }
  }
  </code></pre>
  
  <p>You also need to implement IRepositoryFactory interface some way</p>
  
  <pre><code>public MyEf4RepositoryFactory : IRepositoryFactory
  {
      IRepository Create(ContextInformation context)
      {
          return new MyEf4Repository(context);
      }
  }
  </code></pre>
  
  <p>... and use it in the application</p>
  
  <pre><code>public void main()
  {
      IRepositoryFactory repoFactory = new MyEf4RepositoryFactory();
      IService service = new MyService(repoFactory); 
  
      service.DoSomeService();
  }
  </code></pre>
  
  <p>----- End of mainstream solution ------</p>
  
  <p>Instead of the RepositoryFactoryInterface you can do the same with a <strong>factorydelegate</strong> that requires less coding like this.</p>
  
  <pre><code>public class MyService {
      private Func&lt;ContextInformation, IRepository&gt; repositoryFactory;
      public MyService(Func&lt;ContextInformation, IRepository&gt; repositoryFactory)
      {
          this.repositoryFactory = repositoryFactory:
      }
  
      public void DoSomeService()
      {
          ContextInformation context = ....;
  
          IRepository repository = this.repositoryFactory(context);
  
          repository.Load(...);
          ...
          repository.Save(...);
      }
  }
  </code></pre>
  
  <p>... and use it in the application</p>
  
  <pre><code>public void main()
  {
      IService service = new MyService(context =&gt; new MyEf4Repository(context)); 
  
      service.DoSomeService();
  }
  </code></pre>
  
  <p>In my opinion the factorydelegate <code>context =&gt; new MyEf4Repository(context)</code> is much more compact than 
  declaring and implementing an interface <code>IRepositoryFactory</code> and <code>MyEf4RepositoryFactory</code>.</p>
  
  <p>There must be a reason for this and i want to know why.</p>
  
  <p>Here is one example source that uses the interface aproach: <a href="https://stackoverflow.com/questions/1943576/is-there-a-pattern-for-initializing-objects-created-via-a-di-container/1945023#1945023">answer to is-there-a-pattern-for-initializing-objects-created-via-a-di-container</a></p>
  
  <p>[Update]15 Months after asking this question and having more experience with the java universers i changed my mind: Now I prefer interfaces over delegates . But i cannot say why. It is just a feeling. Maybe because I am more used to it?</p>