Okay, this question is not on which is better. It is more about when to use Dependency Injection vs Factory. I have done a bit of research and it goes like this.DIP:Provides loose coupling, through IoC. The class does not need to know how it got the dependencies. IoC Containers take the control of providing the dependencies.Factory:It is a creation pattern, used to generate the dependencies for a class. It also provides loose coupling since the class is no more directly creating its dependencies.To me it seems like DI can be used in most of the situations to inject the Dependencies and Factories can be left out altogether. I've been using Spring (for a year now) and most of the times a class needs 1 or 2 particular dependencies and Spring makes the stuff quite easy.Taking about Factories, one scenario I think of wherein DI would turn out to be a little cumbersome, is when a class needs certain dependency based on some condition.Something like this:class Bike {private Engine engine;private Model model;public initEngine() {  if(model == 'VINTAGE')    engine = new CaseIronEngine();  else if(model == 'MODERN')    engine = new AluminiumAlloyEngine(); .. ..}}In this case DI would not be that straightforward, and Factory should be an ideal solution.So kindly shed some thoughts over this. Many articles on the web mention that DI is kind of a replacement for Factory Patterns. But still there is no concrete article on which one would be better choice under which circumstance.Some articles mentioning DI as next big thing are as follows:http://tutorials.jenkov.com/dependency-injection/dependency-injection-replacing-factory-patterns.htmlhttp://tutorials.jenkov.com/dependency-injection/dependency-injection-replacing-factory-patterns.html
Usage - Factory Pattern vs Dependency Injection
design;dependency injection;spring;factory
You pretty much hit the nail on the head.Dependency injection is a great choice when you want to get dependencies that are known and unchanging at runtime or compile-time, depending on how you configure. Let's assume that you have a mailer in your application implemented by IMailer and you can use a TextBasedMailer or HtmlBasedMailer. You either build the application or use a configuration file to tell the DI framework what implementation to use.Now, let's say that the IMailer to use depends on a preference for a user. Some users want plaintext e-mails, other HTML. The moment you request the IMailer instance you need some kind of logic to determine what mailer to resolve to. This logic would probably be isolated in a class and at that point you are pretty much using the Factory pattern, even if you are not calling it that.Note that these two are not mutually exclusive. For example, let's say your application can mail attachments in a user-chosen format. You would implement different IAttachmentGenerators such as PdfAttachmentGenerator, HtmlAttachmentGenerator, WordAttachmentGenerator,... You could have an AttachmentFactory that gets the list of IAttachmentGenerators via DI and resolves the correct Generator to use based on the user preference. In this case, you are using DI AND a factory.