Hello, first-time poster here. I hope I'm posting to the right subreddit. I don't think my question qualifies as /r/phphelp since it's more of a philosophical design question. Anyway, my situation is that I'm still trying to get the hang of the dependency injection pattern. I'm practicing with PHP DI (http://php-di.org/). The other day I was considering writing a simple console game where the player is repeatedly asked to select choices for random scenarios (sort of like choose your own adventure, except events would be purely random). There would be player status variables (health, etc.) that get modified depending on their choices. I was thinking about how I might implement this in DI in a way that's scalable and am a bit stumped. It seems to me that every scenario (or event, if you prefer) should be handled by a separate class. But then the application controller class needs to somehow be aware of all these event classes so that it can pick from them at random and generate event objects.

Although I don't intend to actually create a large-scale game, I want the code to be scalable so that I could if I wanted to. That would require support for many event classes. Declaring every event class as a dependency in the app controller constructor would be overkill. Besides, I don't want to instantiate all the events up-front, only on demand. I know you can configure the PHP DI container to lazy-load class objects, but I'm stumped as to how to trigger that in a random fashion. Having the app controller directly request a random event object from the container would violate the principle of IoC.

I was thinking I could have a "registerEvent" method in the controller that takes a class as a parameter, and the controller would store the classes in an array. So when I instantiate the controller I would call this method repeatedly for each class (I would call the method from outside the object by iterating over an array of event classes that would come from an included config file). That way when it's time to generate a new event the controller knows what classes are available. But of course, to have the app controller instantiate the objects also violates IoC. I suppose I could delegate event instantiation to a factory that gets injected into the app controller. The event factory would have a "create" method that would take a class name as a parameter, and it would check to ensure that the class exists and is a sub-class of the base event class before creating an object. The app controller would still need to have the "registerEvent" method and store the event classes, though. Besides, now I'm relying on the factory pattern and not using a pure DI solution.

Another possibility is that I could configure the DI container to associate the base event class (call it "GameEvent") with a factory callback that actually generates the random events on the fly. But then I would have to put GameEvent as a dependency in the constructor of some other class that gets instantiated every time a new event is needed. Aw geez, scrap that idea, that's terrible. Anyway, you see the mental block I'm up against.

I'm getting the sneaking suspicion that what I'm asking for is just impossible purely with DI and I need to use a factory at some point. I would greatly appreciate any thoughts, suggestions, etc. Thank you.