ECS 使用组件的组合代替 Actor 的继承，就是出于简化系统复杂度的考虑
我在网上看到的示例是说，系统要遍历他使用到的组件，我想的是，其实也可以是，要交互的时候就访问实体是否有这个组件，有的话这个事件才能被实体的组件处理。感觉应该也是这个结构的意思。
示例：
我需要玩家和敌人都被视为一个角色，他们作为角色都有相同的逻辑，比如受到伤害，做出决策
一开始我是先新建了一个 BP_RoleBase 然后新建 BP_Role0000 继承这个 BP_RoleBase 表示主角
但是后来我发现，当一些角色需要访问主角的时候，现成的方法中，他们只能拿到 Player Pawn，要拿到 BP_RoleBase 还需要查找。这样就平白多出来一步操作。总览，就是，有两个蓝图可以表示主角，一个是 Pawn，一个是 BP_RoleBase，这样就显得有点多余
实际上，把一些小功能做成组件，然后把组件放到 Actor 中才是更好的
一个优点是便于访问，你只需要对一个 Actor 用 GetComponent 就行，不需要 Cast to
一个优点是便于管理，有这个 Component 的就是角色，没有的就不是，这样，任何 Actor 都可以是角色，而不需要都继承一个角色父类蓝图，还可以动态切换角色身份，只需要动态添加组件就好了，这也是继承父类蓝图做不到的
1.基于 BluePrint 继承的逻辑需要判断 Actor 的蓝图父类
2.基于 Component BluePrint 的逻辑只需要获取 Actor 是否有指定组件
3.带来的优点例如，不需要在初始化加载一些引用，比如玩家引用
本来我是希望 Widget 的基类获得玩家的指定父类的引用，发现 Widget 不能继承之后，我就感觉好像这个逻辑根本就是多此一举
