10

I understand the concept and can use both the Factory Pattern and Dependency Injection, however they seem a little at odds with each other conceptually. Is it a case of using one over the other? Or can they be used in conjunction with each other?

If using DI would you hard code the creation of classes within a Factory? Wouldn't this defeat the point of DI? As the factory is dependant on the existence of the classes it creates, and thus would need them passed to the factory at runtime when using DI.

Or would you pass the classes that the factory is meant to create to the factory is meant to create? If so wouldn't that defeat the point of building a factory in the first place? As the Injector would basically be doing all the work of the factory.

Thank you very much for your attention, I look forward to your insights.

  • In the spirit of creativity and future clarity, one might inject a DI instance into a factory class to resolve any dependencies of the desired, potential product instances. Let your conditional inside the Factory control the logic. Allow the DI instance to handle instance creation and dependency resolution. Simply stated, use a DI instance within a conditional. This way, you can get the product instance you want and all dependencies will be resolved. – Anthony Rutledge Jul 31 '18 at 1:26
6

If using DI would you hard code the creation of classes within a Factory? Wouldn't this defeat the point of DI?

No, it does not violate the Dependency Inversion (not Injection) Principle because it is the purpose of the factory is to create for us some concrete object.

Or would you pass the classes that the factory is meant to create to the factory is meant to create? If so wouldn't that defeat the point of building a factory in the first place? As the Injector would basically be doing all the work of the factory.

You are right!

Factory Patterns are the creation patterns - they are responsible for creating instances.

Dependency Injection patterns are about loose coupling and Dependency Inversion (Inversion of Control) - they inject instances that another instance need to do its job.

They address different problems and can be used in conjunction. An example (maybe not some great but I hope that it would do the job):

class Player {
    string name;
}

interface PlayerFactory {
    Person create();
}

class RealPlayerFactory : PlayerFactory {
    return GetPlayerFromDatabase();
}

class RandomPlayerFactory : PlayerFactory {
    Person result = new Person();
    result.name = GenerateRandomName();
    return result;
}

class Team {
    Team(PlayerFactory playerFactory) {
        for (int i=0; i < 11; ++i) {
            AddPlayer( playerFactory.create() );
        }
    }
}

Use Dependency Injection Patterns to introduce loose coupling.

Use Factory Patterns if you need to delegate the creation of objects.

  • Thank you for your answer. So best practice would be to create a factory with the pattern for creating concrete objects, then use IoC to pass into the factory object the classes it needs to generate concrete objects from? – Samuel Hawksby-Robinson Dec 7 '13 at 22:42
  • Welcome! Only if the class needs creating the dependent objects. In most cases it is not required. – Pellared Dec 7 '13 at 23:26
  • Was I the only one who didn't get the single first thing you tried to show with the code? – Rafael Eyng Mar 19 '15 at 16:39
8

When you make heavy use of dependency injection, you separate your code into parts with classes/objects holding features & functions, and code where the creating of the former takes place and the dependencies are resolved. The latter can be either done by

  • a DI container
  • Factory classes

So DI is not contrary to the use of Factories, in fact, when you do DI without a DI container you will typically need a lot of factories.

See this blog post for a more complete explanation.

  • Please a distinction between Dependency Injection and Depedency Inversion - they seam simillar but they are not the saome (Dependency Inversion is a more generic context). – Pellared Dec 9 '13 at 12:34
  • @Pellared: there is nothing to distinguish in my answer - I meant exactly dependency injection, nothing else, and I wrote it, as well as the OP. You alone interpreted "dependency inversion principle" into his question. – Doc Brown Dec 9 '13 at 12:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.