Thanks for your response. One more question about your answer: As you explained, the factory method avoids the direct construction of the products on the client side, but the client still have the responsibility to decide/construct the correct factory. Why is this a good solution for the client? I mean, from the point of view of the client, isn't the same problem (but now with more code to understand)? On the other hand, I understand that the code in charge of calling the "new" operator is cleaner, can be split apart so it's more independent and maintainable and at the same time is open-closed. Thanks you very much for your hard-work!
Служба підтримки клієнтів працює на UserEcho
I understand your point, I've worked with a production 20 year old legacy code of 2 or 3 million LOC, and I feel two-sided about it: on one hand is amazing how this code works and collaborate each class with each other, and on the other hand, I feel really bad for the implicit complexity it have (the churn rate was really high), in my POV this complexity was exacerbated by our ignorance of good patterns, dead-lines with clients, and somewhat a kind of fear to ask "what should be a good and clean way to implement this feature, or correct this bug?". In any case, and as more as I learn, the "ugly code" seems unavoidable, which talks really bad about our capacity as humans beings to control our creations (in this case, coding).
I do feel very appreciate for your work, I think that the project factoring.guru talks directly to the problem I've commented, and I'm sure it make the life of other programmers much easier.