组件模式

在设计模式中有一个原则叫做合成复用。

在游戏编程领域中，常常需要让一个对象实现热插拔的功能。但是不能从代码处进行热插拔，因为这违反了开闭原则。

所以渐渐的基类的体量越来越大，形成了所谓的胖球。

当然我们也可以用装饰者模式，来扩展对象的功能。

为什么要实现热插拔，因为对于同样的一个player实体，我们希望他有背包功能，也希望他有宠物功能。我们希望在特定的时候，禁止甚至没有背包功能。

这个时候，就得掏出我们的组件模式了。

典型的组件模式就ECS。unity和ue的组件。

组件可以随时随地取消和挂载。

组件与组件之间完全可以独立运行，但是通常有需要导致某个组件依赖于另一个组件

比如一个移动组件，往往依赖对象的transform组件

我们的技能组件也会依赖于数值组件。这种依赖是无法避免的。

我仿照着unity的组件，构建了一个组件系统。

Entity和Component

entity只具备一个功能，保存Component的索引，并开放出组件的添加和获得的接口。

Component的功能就更简单的，如果不考虑生命周期，那么Component只需要持有entity的索引，以便获得entity上挂载的其他Component来执行来的逻辑即可。在子类中实现具体的逻辑。

ECS又怎么做呢？

将原有的Component拆分为Component和system。Component只具备数据，system只处理数据，这样就可以把Component放在栈上去处理了。但是这需要特殊处理。目前我只能把Component放在堆上。

entity只具备一个id。在创建entity的时候，是通过entitymanager给与一个id。

entitymanager再通过这个ID来查询对应的Component。

由于system和Component分离，因此system大量的使用了this的语法糖，从代码侧为为Component添加功能。每个Component都有一个对应的system。

从而让ecs代码，在调用上与以往一样。只是代码结构有所变化

大功告成。没有做数据整理的ecs框架。