Unity客户端框架笔记二（组件实体开发模式的思考）

        Unity的Entity-Component-System实现的非常漂亮，非常灵活。很多文章也对这种组件实体的开发模式倍加推崇。因为它契合这么一条规则：优先使用组合而不是继承。

        但是实际开发过程中，限制于我的个人能力，想实现一个同样漂亮的基于组件的MMO框架是非常困难的一件事情。

        这篇文章是个人开发过程中的一些思考，实际上，所谓漂亮的框架是因人而异的，并且不一定是必须的，能够用自己熟悉的方式快速的完成项目的开发就足够了。只要开发过程不会感觉别扭，代码也不会把自己或其他人恶心到，策划修改需求的时候不会骂娘，后期不会出现各种难以调试的Bug，那么就是漂亮的框架。

        从理论上说，所谓ECS就是一个Entity，持有一组Component，然后通过一系列的System来维护调度组件之间的逻辑。组件之间是相对独立的，最理想的方式是通过Event来进行消息传递。从这点来说Unity已经实现的非常漂亮了，GameObject可以绑定任意的MonoBehaviour，脚本组件有统一的入口，并且可以通过SendMessage发送消息，也可以通过GetComponent来获取一个具体的组件，直接调用其函数。

        我反编译了一大堆线上手游的源代码，几乎没有完全依赖组件模式进行开发的，更多的还是依赖一套继承体系来完成。这里我自己的感觉就是偏底层或者逻辑独立性非常强的功能适合组件模式，而逻辑交互非常复杂的情况，过分依赖组件模式想要达到“理想”的效果，反而会适得其反。

        比如，理论上ECS中，Entity应该像GameObject一样，只维护组件，不包含任何其他逻辑或者代码，所有需要调度的逻辑都应