0

I've been working on a legacy system and we want to cut the cord and modernize everything. For that purpose I have started researching patterns that solve some of the problems we had in the old system. There are plenty of threads here on the topic of factory pattern vs dependency injection but the answer don't always make sense to me.

Answers tend to either suggest that DI is more modern or flexible or that factory pattern still has its place, it is just used for different situations. Or even that both aren't mutually exclusive and can be implemented at the same time. Either way DI is usally made out to be more flexible. If you want to make changes you have more work to do with the factory pattern. I guess that depends on the kind of change you want to make, but to the typical scenarios I can think of it is the opposite.

Assume I'm looking for a solution for making phone calls. We might test different telephone systems and within those telephone systems different APIs. Now let's say phone functionality is integrated in several different projects and modules. If we want to switch to a different API or a new phone system with DI we have to find each project that uses the phone interface and instantiate it with a different object. So I have to find all the projects that use the interface and change at least one line code in each. If I use a factory however I can just change the Method that gets me an instance to get me an instance of the new class. One line for every single project.

In short, with DI each project would have to be updated every time a new interface is to be used but with a factory only one method needs to change. Moreover, if i want a different instance for a specific project I could just use an optional parameter. Like "GetPhoneApi("StarfaceTest")"

I never see this cited as an advantage in all the discussions, which makes me wonder if I am missing something? What exactly makes DI more flexible then?

user2696330
  • 143
  • 11
  • 1
    Does this answer your question? [Dependency Injection vs Factory Pattern](https://stackoverflow.com/questions/557742/dependency-injection-vs-factory-pattern) – Ian Kemp Sep 29 '20 at 09:35
  • Changing the implementation in the factory case only requires the factory itself to be modified, yes. But how are the applications depending on said factory going to know to use the new version? Magic? No, you are going to have to explicitly update them to use that version. So it's either changing a line of code in every project, or updating a NuGet package in every project... much of a muchness. – Ian Kemp Sep 29 '20 at 09:39
  • `I've been working on a legacy system and we want to cut the cord and modernize everything.` When you say "cut the cord" do you mean a big bang rewrite, or are you talking about gradual evolution? – John H Sep 29 '20 at 09:42
  • @IanKemp At first I was gonna say no, but then I read an answer about manual DI being as much of a rework as factory pattern. So could that be the answer? That manual DI would actually be at least as much work if the implementation changes? But who then decides what implementation to use in automatic DI? Wouldn't automatic DI be more like a combination of factory and DI because there is some component that chooses which objects are actually injected? – user2696330 Sep 29 '20 at 11:31
  • @JohnH I guess cut the cord wasn't the best phrasing. We will have to rewrite some moduls and migrate (at least at first) others. It depends on how large and efficient the existing moduls are and how well they can be implemented in the new architecture. – user2696330 Sep 29 '20 at 11:34
  • `who then decides what implementation to use in automatic DI` You the programmer still have to specify how an interface maps to an implementation. The "automatic" part is merely the instantiation of an implementation (and providing its dependencies) based on a requested interface. – Ian Kemp Sep 29 '20 at 12:02
  • @IanKemp I think (hope) I get it now. So if my projects use the factory pattern and my factory is in an external DLL and versioning isn't forced, I really just do need to change the code at a single place and then just replace the DLL that all projects use. Then the GetInstance Method would simply now return an instance from a different class and nothing else would have to be changed. But since most developers do not have such a setup they assume changing the implementation requires more changes. Is that correct? – user2696330 Sep 29 '20 at 12:56
  • 1
    If your developers aren't thinking far enough, yes. It is a relatively simple step from "have the DI mapping registration for the same interface->implementation in 20 different projects" to "have the DI mapping registration for the same interface->implementation in a single project, and make all 20 projects reference that project". – Ian Kemp Sep 29 '20 at 13:11
  • And please avoid having your reference as direct DLLs with a never-changing version unless absolutely necessary, because it means that all your projects will automatically reference the latest version of that DLL, whatever that may be - which means all your projects implicitly get whatever bugs are in that latest version. If such a bug is show-stopping, all your projects are now broken. Explicitly versioned NuGet packages that your projects have to explicitly opt into allow for an update to the shared package to be tested in isolation, and rolled out when it's confirmed bug-free. – Ian Kemp Sep 29 '20 at 13:19
  • I've added an [answer](https://stackoverflow.com/a/64144159/1371329) to the dupe target. – jaco0646 Sep 30 '20 at 19:11

0 Answers0