我正在 Symfony 中开发一个非常大的游戏项目，并且不断遇到相同问题的变体。
我有一项服务需要分成多个“子服务”，因为一个类中包含太多代码。例如，自定义 JSON 序列化程序处理程序需要为每种序列化方法提供单独的处理程序服务。
我在制定在“服务系列”之间传递依赖关系的最佳实践时遇到了麻烦。我最好将所有定义保留在 services.yml 中，这样将来就不会出现问题，但我假设这可能无法实现。
这是一个更好的示例 - 我有一个“ActionQueueService”，它从用户那里获取相当长的操作队列。我想做的是创建一个单独的类来处理每种类型的动作，所以 -
- ActionQueueService // 处理动作队列 JSON 并委托给子服务
- 抽象动作
- PurchaseAction 扩展 AbstractAction
- SellAction 扩展了 AbstractAction
- HarvestAction 扩展了 AbstractAction
现在，如果这三个“动作”被定义为服务，它们就可以拥有自己的依赖关系。然而，它们都必须被注入到 ActionQueueService 中——如果它们中有 38 个会发生什么（会有一天）。
对我来说，下一个合乎逻辑的步骤是创建 ActionFactory。现在我只将一个依赖项传递给 ActionQueueService，它可以调用任何操作服务，只需调用 -
$this->actionFactory->get('Harvest');
我遇到的问题是每个孩子都有自己单独的依赖项列表。购买或销售操作需要 Character 服务和 ShopStock 服务，HarvestAction 需要 HarvestService。因为我决定使用工厂方法，所以我必须在工厂类中实例化子服务。我不想将每个依赖项都传递给工厂，只是为了让 a) 将每个依赖项注入每个子节点或 b) 处理一些疯狂的子构造函数逻辑。
一种解决方案是将服务容器传递到工厂并提出一个命名约定，使我可以动态创建服务。我听说这是相当糟糕的做法。也许是服务容器的包装器，它限制了可以用它完成的坏东西的数量。
如果有人对如何使用 Symfony 解决此问题有任何想法，我将不胜感激。那里有类似的答案，但不幸的是，除了 PHP/Symfony 之外，我不知道任何语言。