[PetraAI] - Use more robust dependency injection.

[Freagarach]

E.g. currently gameState.ai.HQ is called by plenty of "managers". It would increase modularity of the systems if upon creation the manager would receive its commanding HQ and use that. The same can be said of e.g. plans that originate from a manager (e.g. transportPlan querying gameState.ai.HQ.navalManager).

This way, it might be possible (for modders) to have more than one manager of a kind. And at least it is more modular.

[Stan]

Sounds okay. Are there other design alternatives (Other design patterns maybe)? Dependency injection is apretty common thing.

[Freagarach]

Well, the current state is also some kind of dependency injection, since the gameState is passed along. One could even argue the current state is a more pure dependency injection. However, our current state of PetraAI is something in between, we save the config at creation but query the gameState later on.

So another approach -- which may be even more DI-like -- would be to save nothing at manager/plan creation time, but always just pass gameState and manager when calling a function. (gameState for querying the current state of affairs and the manager to get e.g. config data).

Since a manager highly depends on the HQ which instantiated it and has a persistent state, I would prefer the approach of saving the HQ on creation/init.

[Stan]

Unlikely to get done for A26

[Freagarach]

Pushing back.