我的刷怪系统在只有一个精灵预设的时候是正常的。但是现在有三个敌人类型和一个子弹池，刷怪逻辑变成了一个知道太多细节的switch语句。每次我添加一个新的敌人，池管理器都需要一个新的枚举项，一个新的预载计数，和一个新的分支来决定应该加载哪个预设。虽然它能工作，但感觉很臭。 我研究了泛型池的实现，传入一个预设引用，返回一个实例。这种接口更干净，但我会失去预载的优势和根据类型调整池大小的能力，而这些配置却需要散落在一堆脚本中。作为后端开发人员，我想构建一个工厂模式的工厂，使用一个注册表。但是，这感觉对于可能只会发布六种敌人类型的游戏来说太重了。另一方面，我知道当前的方法一旦需要动态切换变体或让设计师调整池大小而不修改代码，就会破裂。 有人在发布时使用多个池类型：你们是使用硬编码的配置，还是构建一个通用版本？通用版本是否实际上节省了时间，还是只是添加了多余的抽象？