标题:
ET当前设计：单独的类，比如 public class xxxComponentUpdateSystem : UpdateSystem<xxxComponent>
public class xxxComponentUpdateSystem : UpdateSystem<xxxComponent>
为了调用这些System，ET用了一套较为复杂的机制：反射筛选，缓存实例化对象，调用时组件对象注入 如果和System里其他方法一样，用扩展方法，不就可以直接通过组件对象调用了？此时只需要在AddCompoent时缓存对象，移除组件时移除缓存就可以。这样实现方式上更简单，也更好理解。 最近看代码的疑惑，求教🙏
我理解的是 Update、Awake 等方法属于 实体类的生命周期方法，是否需要实现这些方法 则取决于 实体类 上是否有对应的 接口声明，这些接口声明会作为框架 调度的参考依据，同时这些接口声明 也会被 代码规范工具检测和使用。 既然使用了接口，那就需要引入实现类，如果直接把Update、Awake 放到扩展方法里（扩展方法 本质是个静态方法，不属于 类方法），那接口实现类里 就识别不到 方法是否被实现了。又因为ECS架构的原因，所以对于 实体类 生命周期 方法 需要 额外 设计成单独的类，如果你仔细观察，你就会发现，对于实体类 非生命周期 方法，则可以直接 放到 扩展方法里，这里为了方便，直接就放到了 xxxxSystem 里了。正因为 实体类 生命周期 方法的特殊性，所以拆出了 xxxxSystem 来对应接口识别，为了框架自动调度，所以框架启动的时候会使用 反射把对应的类加载进容器里，然后进一步处理。 总体上是因为架构设计，所以才会引出 所谓的复杂机制。
AddCompoent 缓存对象，那不得手动去搞，不然怎么知道该缓存哪个静态方法。如果是自动的，那不是要在静态方法中加标签，让框架自动扫描，那跟现在有啥区别
感谢两位大佬的解答，我理解了🙏 为了【统一管理】生命周期方法，需要一个【识别手段或机制】，此时需要借助继承或标签或手动传参。
假设使用扩展方法：
前者由框架层实现，更优雅（既然谈到优雅了，那么单独的类更优雅）；
后者由程序员每次手动传参，理解上简单，但是繁琐、容易出错，而且不优雅