c++ - 减少实体组件系统中的 Duck-typing 劣势

Question

如何减少实体组件系统中的 Duck-typing 现象？

例子

这是一个 coliru demo .

我的 ECS 中有 2 个系统:-

System_Projectile : 管理所有弹丸和子弹方面。
<强> System_Physic : 管理物理组件。

有 2 个组件类型: Com_Projectile , Physics .

有时，我发现在某些组件中缓存指向另一个实体的指针是很好的:-

class Com_Projectile : public Component{
    public:
    Entity* physic;
    Entity* physicSecondary; //just to show that it is possible to have >1 physic
};

如果我想改变 Com_Projectile 的位置，我会调用manage(Com_Projectile::physic) .

class System_Projectile{
    public: static void manage(Entity* projectile){
        Com_Projectile* comP = getComponent<Com_Projectile>(projectile);
        //suffer duck-typing at "comP->physic"
        System_Physic::setVelocity(comP->physic,Vec3(1,0,0));
    }
};

问题

基于上述代码片段的真实程序运行正常。
但是，编码时，Com_Projectile::physic遭受鸭子类型(duck typing)。

• 我没有得到关于 physic 的 C++ 语义线索的类型。
  (变量名和注释除外)

• 因此，我必须对此有意识。
  编码人员对类型的误解只能在运行时检测到。
  在实践中，这种错误很少发生。

• 我必须记住可以做我想做的事情的系统名称 ( System_Physic::)，
  然后记忆函数的名称(在本例中为 System_Physic::setVelocity())。

• 总而言之，我的大脑有很多间接作用。

在我以前，当我使用大量(深度)继承时，它会容易得多，就像这样:-

    physic->setVelocity(Vec3(1,0,0));

我真的很怀念列出所有与物理相关的函数的可爱内容帮助。

问题

如何减少ECS系统某部分的duck-typing？
更具体地说，什么是再次启用可爱内容辅助的设计模式？

我目前的解决方法

让Com_Projectile缓存 Physic* physic而不是 Entity* :-

class Com_Projectile{
    public: Physics* physic; //edited from "Entity* physic"
};

缺点:-

• 它会促进不需要的(？)耦合。
• 我必须转发声明Physics里面Com_Projectile.h .
• 我必须将复杂功能(例如 setVelocity() )从系统(例如 Sys_Physic:: )移动到组件(例如 Physics:: )中。
• 总的来说，我打破了实体-组件-系统的宗教信仰
  -> 我可能会在某些方面受到惩罚(？)。

Answer 1

How to reduce duck-typing in some certain part of ECS system?
More specifically, what is a design pattern to enable the cute content-assist again?

一个想法是将您的组件实现视为您与系统交互的管道。无论如何，这就是他们的意图，成为一种影响行为的数据驱动方式。

class Physics : public Component<Physics> {
public:
  Vector3 GetVelocity() const;
  void SetVelocity(const Vector3& velocity);
private:
  Vector3 velocity_;
}

现在为了设置速度，它是一个简单的调用:

Physics* physics = getComponent<Physics>( projectile->physic );
if ( physics ) 
  physics->SetVelocity( Vector3( 1, 0, 0 ) );

然后物理系统的工作是获取物理组件上的速度，并将其与任何其他数据属性一起应用于内部物理模拟。

换句话说，将系统的输入状态视为当前组件值和先前系统发出的任何其他可变状态的组合。

除了避免您提到的 duck-typing 之外，您最终得到的代码更容易理解，也更容易流动。它还打开了一扇门，很容易被脚本系统和其他外部影响者通过操纵组件上的 getter/setter 来改变。