Timeline for Abstract Factory with Pure DI
Current License: CC BY-SA 4.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 21, 2019 at 18:24 | comment | added | Vector Zita | Yes, so you probably only need it for lazy instantiation, plus at-will instantiation from within your other classes, during run-time. If this is only part of the composition root, having some more parameters in the construction might not hurt that much if it keeps things clear as to what depends on what. You have to pass these dependencies somehow to the factory anyway. | |
| Sep 21, 2019 at 15:32 | comment | added | Rob L | "if you want to re-combine component construction methods you have to create a new factory that uses the new methods each time" I guess I see the factory as part of the composition root. If I change the steps of the login process, I have to change it somewhere in the composition root regardless. It doesn't seem any different to me whether I change it in this factory or in any other composition root class. | |
| Sep 21, 2019 at 15:19 | history | edited | Vector Zita | CC BY-SA 4.0 | Updated answer to take new comment into account. |
| Sep 21, 2019 at 14:42 | comment | added | Vector Zita | @RobL "Isn't that the point of putting the factory in the composition root? Knowing that it will never be reused, so it isn't part of an API that other programmers would be calling into?" - Yes, I am sorry, I was referring to your coworkers (especially newcomers) who will be co-maintaining the code base. In your case, of course you may not even have an API, besides, you are building an application, not a library, if I got that right. | |
| Sep 21, 2019 at 11:58 | comment | added | Rob L | To answer the questions of your last paragraph, in the actual application, there are several factories in the real application. Every factory might not use every shared service, but for example, there will be factory that creates the login session when the user clicks a button. Let's say kicking off the login session requires a composite action made up of 10 other smaller actions. Then the factory that creates the session would create 10 actions and compose them together. Are you saying that each of the 10 actions should have its own factory? That seems like a lot of factories. | |
| Sep 21, 2019 at 11:49 | comment | added | Rob L | "Many programmers ... reading your API would not appreciate having to visit the source code". Isn't that the point of putting the factory in the composition root? Knowing that it will never be reused, so it isn't part of an API that other programmers would be calling into? | |
| Sep 21, 2019 at 1:26 | history | edited | Vector Zita | CC BY-SA 4.0 | Minor syntactic improvement. |
| Sep 21, 2019 at 0:52 | history | answered | Vector Zita | CC BY-SA 4.0 |