0

Someone told me that before dependency injection frameworks came around there developers would use a factory to implement DI. Can anyone provide an example how a factory pattern can be used for DI. I mean just by thinking about it a factory is a depenendency injector but i cant find any examples on the web.

j2emanue
  • 60,549
  • 65
  • 286
  • 456
  • This answer may help. "Dependency Injection vs Factory Pattern": http://stackoverflow.com/a/12399680/4797330 – BranLakes Apr 17 '15 at 21:08

1 Answers1

1

This off the top of my head, untested code (with C#)

public class CarFactory : ICarFactory{

   private static CarFactory instance = null;

   public static ICarFactory SingletonInstance {
       get {
            if (this.instance == null){
                 this.instance = new CarFactory();
                 return this.instance;
            }
       },
       set {
           this.instance = value;
       }
   }

   public ICar CreateCar(string make){

       switch(make)
       {
           case "Toyota": return new Toyota();
           case "Honda" : return new Honda();
           default: throw new Exception();
       }

   }

}

public interface ICarFactory {
    ICar CreateCar(string make);
} 

public class Toyota : ICar
{
}

public class Honda : ICar
{
}

And usage would be something like :

ICar car = CarFactory.SingletonInstance.CreateCar("Toyota");

Exposing the singleton instance of the CarFactory publically enables you to mock the CarFactory for your unit tests and you can have your mocked CarFactory return mocked ICars when calling CreateCar.

Now replace the Cars in the factory by actual dependencies such as classes that implement services. And voila, you have a Factory that contains all your dependencies. You can now use the Factory to "resolve" your dependencies. You can take the example and push it further by using generic types and a dictionary (hashtable) where the key is the type name and the value the implementation instance such as:

public T Create<T>(){
    return mydictionary.get(typeof(T).Name);
}

Something like that... You get the drift...

Hope it helps!

TchiYuan
  • 4,258
  • 5
  • 28
  • 35
  • so then would you agree that a dependency injection is nothing more then a factory implementation ? – j2emanue Apr 18 '15 at 03:22
  • doesn't this just give you a Service Locator and not dependency injection? See the answers to [this question](http://stackoverflow.com/questions/1557781/whats-the-difference-between-the-dependency-injection-and-service-locator-patte). – Sam Holder Apr 18 '15 at 07:58
  • There are several ways of using dependency injection: 1# is to have the dependency "injected" in your class through your setters. 2# is to have your dependencies "injected" through your classe's constructor. 3# is to have your dependencies accessible through a global object, in this case the CarFactory.SingletonInstance (since it's static). I like the global object approach since it makes your constructor's signature focus on business objects (stuff that matters). More fancy DI frameworks also allow special method attributes to "inject" the dependencies. – TchiYuan Apr 18 '15 at 18:01
  • Here's a global object (static) approach example to implementing dependency injection directly from Microsoft which leverages Microsoft's dependency injection library "Microsoft Unity": https://msdn.microsoft.com/en-us/library/vstudio/hh323691%28v=vs.100%29.aspx The concept shown works for any dependency injection library. – TchiYuan Apr 18 '15 at 18:05
  • @SamHolder The line between a service locator and dependency injection is very very slim. Yes, if you use a global object to access your dependencies that means that your class depends on the global object and that's not "pure" dependency injection. So yes it leans more towards the "service locator" pattern. But, seriously, don't bang your head too much on this one. Use whatever you feel is right. The important thing is that you're able to easily write unit tests that don't cross over multiple logical layers of your project because those are no longer "unit" tests. – TchiYuan Apr 18 '15 at 18:21
  • @j2emanue yes, it's a kind of factory but it has so much more "depth" than a simple factory. It's much more flexible and much more configurable and thus much more powerful. For example, a factory can quickly become messy if your dependencies require other dependencies that require other dependencies or if you have a lot of different services. What do you then ? You'll end up with factories all over the place. – TchiYuan Apr 18 '15 at 18:33