0

This has been bugging me a bit... It is a question regarding Dependency Injection.

The code is trivial and it merely demonstrates the problem:

public static void Main(string[] args)
        {    
            //Take new instance from the app config
            IVehicle vehicle = CreateVehicle(); 

            //inject the new instance
            var mainClass = new GenericClass();
            mainClass.InjectType(vehicle); 

            //call the generic class 
            mainClass.DoSomething(); 
        }

        public static IVehicle CreateVehicle()
        {
            var dynamicType = Type.GetType(ConfigurationManager.AppSettings["ClassName"]);

            var vehicle = Activator.CreateInstance(dynamicType);

            return (IVehicle)vehicle; 
        }

 public class GenericClass : IInjectDependent
    {
        IVehicle vehicleDependent;

        public void DoSomething()
        {
            vehicleDependent.Drive();
            Console.ReadLine();
        }

        public void InjectType(IVehicle vehicle)
        {
            vehicleDependent = vehicle;
        }
    }

 public interface IInjectDependent
    {
        void InjectType(IVehicle vehicle);
    }

Not much going on there.

  1. A quick factory-like method to create a vehicle type (pulled from app config in this case).
  2. The created type is then injected to the 'generic' class via a method implemented with the IInjectDependent
  3. The 'generic' class with the injected type then goes off and calls the logic on the concrete classes (bus, car, ambulance, and whatever class implements the IVehicle interface)

...my question is - the same could be easily achieved with parameterised constructor on the 'generic' class:

 public class GenericClass 
    {
        IVehicle vehicleDependents;

        public GenericClass(IVehicle vehicle)
        {
            vehicleDependent = vehicle; 
        }

        public void DoSomething()
        {
            vehicleDependent.Drive();
            Console.ReadLine();
        }  
    }

This way we don't need the interface and the method that comes with it. We simply ask for the type in the constructor.

So what are the benefits of using interface over constructor in this case? Thanks.

tom33pr
  • 853
  • 2
  • 12
  • 30

1 Answers1

1

There is a post about Dependency Injection(DI) here. See @Thiago Arrais's answer, in particular.

It seems nice if the constructors are minimal, and dependencies are specified as interfaces. This means other code can easily instantiate your class, and also supply its own impementation.

Community
  • 1
  • 1
mcsilvio
  • 1,098
  • 1
  • 11
  • 20
  • I totally agree regarding the decoupling and using interfaces, as far as pure OO is concerned. Fine; however, swapping the var instantiation from interface implementation to the constructor still preservers decoupling. The main class (in this case) will still not know of the concrete type, it will still have the interface type injected. We only changing the way the type is injected here... – tom33pr Jan 17 '14 at 16:29
  • Ok, then take it to the next step. If you decouple so much that you no longer require GenericClass, then you don't need to include it in your project. That means, another project can use IVehicle from your project and supply its own implementation of IVehicle itself. – mcsilvio Jan 17 '14 at 16:34
  • Ok I see that I am on a tangent. But I've got your solution. Keeping constructors free of input variables is useful. Why? Other code might have to call your constructor, and in those cases, you want your constructor to have as few dependencies as possible (or none). More dependencies in the constructor = more entities that don't exist when other code needs your constructor. Here's a few concrete examples: – mcsilvio Jan 17 '14 at 16:36
  • ...You may overload the constructor :) – tom33pr Jan 17 '14 at 16:41
  • I'm going to change my answer. – mcsilvio Jan 17 '14 at 16:43