Timeline for Abstract Factory with Pure DI
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 22, 2022 at 15:40 | vote | accept | Rob L | ||
| Feb 17, 2021 at 18:24 | history | edited | Robert Harvey | CC BY-SA 4.0 | deleted 856 characters in body |
| Sep 21, 2019 at 22:05 | answer | added | candied_orange | timeline score: 1 | |
| Sep 21, 2019 at 0:52 | answer | added | Vector Zita | timeline score: 2 | |
| Sep 21, 2019 at 0:42 | answer | added | John Wu | timeline score: 1 | |
| Sep 20, 2019 at 23:08 | comment | added | John Wu | The single responsibility of a factory is exactly to construct the objects you need with the dependencies they need. As such, it is conceptually a extension of the composition root, and it is totally appropriate to pass it a reference to the DI container so it can resolve all of the dependencies, just as the DI container itself would. To me, that sort of approach introduces less developer effort/risk/complexity than coming up with a bespoke solution to get around the "rule" that the DI container shouldn't be injected anywhere. | |
| Sep 20, 2019 at 19:48 | history | edited | Doc Brown | CC BY-SA 4.0 | added 178 characters in body |
| Sep 20, 2019 at 19:46 | comment | added | Doc Brown | Related: Should I use Dependency Injection or static factories? | |
| Sep 20, 2019 at 19:45 | history | reopened | Euphoric Doc Brown c# Users with the c# badge or a synonym can single-handedly close c# questions as duplicates and reopen them as needed. | ||
| Sep 20, 2019 at 18:10 | comment | added | Rob L | @Euphoric That coffee maker paper was a good read, but I don't think abstracting physical objects is really the crux of my problem. True, I am abstracting the hardware of speakers and microphone. But the problem would exist any time there are shared services. So my real problem is how (and where) to build a composite task from smaller tasks when those tasks themselves have to share dependencies. | |
| Sep 20, 2019 at 18:09 | history | edited | Rob L | CC BY-SA 4.0 | added 682 characters in body |
| Sep 20, 2019 at 16:40 | review | Reopen votes | |||
| Sep 20, 2019 at 19:50 | |||||
| Sep 20, 2019 at 16:25 | comment | added | Euphoric | @DocBrown This is not duplicate. This question is not asking about one or the other. It is asking about handling lots of dependencies when using DI factory. Rob is only using the non-DI approach as an example. | |
| Sep 20, 2019 at 16:23 | comment | added | Euphoric | Maybe read cs.unibo.it/~cianca/wwwpages/ids/esempi/coffee.pdf to find out why creating abstraction around physical objects might not be best approach. | |
| Sep 20, 2019 at 16:23 | history | closed | Doc Brown c# Users with the c# badge or a synonym can single-handedly close c# questions as duplicates and reopen them as needed. | Duplicate of Should I use Dependency Injection or static factories? | |
| Sep 20, 2019 at 15:58 | comment | added | Rob L | I would welcome another way to do it. The login task is composed is multiple steps - obtaining phone extensions, starting the microphone, sending socket messages. Some place in the code has to know enough about them all to put them into a single point of execution. | |
| Sep 20, 2019 at 15:48 | comment | added | Euphoric | Are you really sure so many dependencies is really best design you can create? When I hear "lots of dependencies", my immediate reaction is "design smell". | |
| Sep 20, 2019 at 15:33 | history | asked | Rob L | CC BY-SA 4.0 |