只要逻辑跟数据分离，数据不使用继承结构，基本上就不会写出不可维护的代码。
面向对象数据跟逻辑是耦合的，为了解决这种问题，搞出很多没用的技术。问题来了，一个类要用到另外一个类，为了解决两个类耦合，一个类要继承接口，另一个类构造时传入这个接口，这就是所谓的依赖接口。这造成了严重的代码阅读困难，看到这个接口看不到具体实现。而且问题又来了，一个类依赖多个类，可能要传入好几个接口，个个不知道具体实现，经常看到很多项目构造函数传78个参数。为了解决这种问题，又造出了依赖注入的技术。整个项目代码变得没有了可读性，到处是接口，找不到具体逻辑
阿中大人这个例子真的是普遍现象，可能开发人员刚开始想每个类型的人使用不同的死法所以高了个ondead的虚函数。写着写着就维护不了了，结果全写到了一个方法中。那么问题来了，ET中怎么实现虚函数的功能？不能在数据中写逻辑，意味着不能用虚函数，但是开发中又需要实现不同的unit有不同的死法。本质上虚函数不过是一个函数指针，那么我们可以根据不同的unit类型id分发到不同的逻辑中即可，跟消息分发完全一样
只要坚持两点，游戏开发就不会写得很乱。1.逻辑层去掉任何继承。2.逻辑与数据分离。逻辑由事件驱动，例如死亡事件，根据id分发到逻辑层，消息事件，数值改变事件等等。
什么纯不纯ecs，其实不太重要，ec是解决继承问题，s是解决逻辑跟数据分离问题。
什么纯不纯ecs，其实不太重要，ec是解决继承问题，s是解决逻辑跟数据分离问题。
只要坚持两点，游戏开发就不会写得很乱。1.逻辑层去掉任何继承。2.逻辑与数据分离。逻辑由事件驱动，例如死亡事件，根据id分发到逻辑层，消息事件，数值改变事件等等。
什么纯不纯ecs，其实不太重要，ec是解决继承问题，s是解决逻辑跟数据分离问题。
我是说逻辑层去掉任何继承，框架层是稳定的结构（框架层用的继承），不会有复杂的变化，用继承问题不大，面向对象的缺陷是无法应对复杂多变的逻辑