This post teaches us to separate object graph construction from the application logic into two different classes and the end goal is to have either: classes with logic OR classes with “new” operators. Sounds really nice, as coming from this post you can understand that if you have started to do DI you should do it completely and not partially to not break Law of Demeter. Thus you should use factories, where all the objects are created and then delegated to others by reference to create the object graph.
But what if I need to change the graph structure runtime? What if some object in the lower hierarchy is making this critical decision? (For example, I have 2 game scenes, and I want to switch from "InGame" scene to "MainMenu" scene if player hits to some object and that collision is detected below in the hierarchy.)
When I was reading this one I hoped that it will explain the solution. But actually, it didn't. So please tell me how to create new objects that change the software configuration and need lots of Injectables for changing it when they are in lower hierarchy.
One way to do this, is to pass the Factory, which creates the new config, down by the hierarchy, but this breaks the low of Demeter.
Other way is to use Observer Pattern and dispatch an event to the Factory, so that it can change the object graph structure, as it has all injectables and can build objects easily. After all, this is the work it does. But I am not sure, this is the right thing to do.
Please share your experience.