浅论unity3d的数据驱动

先大致介绍下个人理解的数据驱动（有些观点来之于网上）：
一套乐高积木，里面除了那些固定的方块外，还有许多其他的配件，比如齿轮、传动轴、轮胎、螺旋桨、传动带甚至电动机和开关、灯泡，那么就可以用这些配件，搭建出很不错的玩具飞机、汽车、甚至是机器人。这些乐高的配件，就是所谓的“组件”，搭建一个机械玩具所用到的方案，就是“数据”。你可以不去修改这些配件，仅仅是拼装，就是“数据驱动”编程。
回到编程领域，所谓的组件，一定是要自己本身具备一定功能的，并且和其他组件要有能配合的接口。而这一切，都需要组件本身具备完备的代码封装性，所以数据驱动中的组件，本身也是要编码实现的。然而，我们针对性去做的组件，只能解决某些特定的问题，一定会存在范围以外的需求，所以我们只能追加开发新类型的组件。所以数据驱动编程本身并不复杂，关键是要实现这种活动，背后要对需求领域有深刻理解和模型抽象的能力。能不能做出一套你的业务领域的乐高配件，正是你在业务领域和编程技巧上的能力体现。
回到unity，GameObject Compnent就是组件，配表、图像、声音等等asset就是数据。组件是代码驱动，整个游戏是数据驱动，换句话说是数据驱动代码。为了方便数据驱动，更好的管理组件，那第一步，就是要限制代码与对象的关系。 世界中的任何单体对象，都不应该拥有改变世界（游戏逻辑）的能力。它唯一能做的，就是操作它自己，同时，如果遇上了自己能力以外的事情，必须要向管理器报告。所以，为了实现数据驱动，我们的游戏大概有以下几种东西：
1、一个逻辑管理器，它决定了整个世界是如何运转，不同对象之间如何交互
2、事件管理器，它负责接收来自各个对象的报靠，比如（啊，有人踩到我了；咦，这是一个传送点耶；哎哟，你为什么点我。） 事件管理器起到事件队列缓存的作用，同时，游戏逻辑应该定时处理这些事件。 当然，这个事件管理器，也是逻辑管理器的一个小弟，如果逻辑管理器觉得不怕麻烦，也可以亲自操刀，负责事件收集。
3、若干对象相关的脚本，用于决定对象能力。 这些脚本不做别的，只做它们自己目标对象相关的事情。 比如，控制一个对象的动画切换，检查敌人是否进入攻击范围等等。 这些脚本，是做为脚本的一种能力挂上去的。当相应事件触发时，他们会将事件通知给事件管理器。 理论上，我们是可以完全避免这样做的， 就像早期的引擎中，对象只是资源，逻辑代码用来操作这些资源。 但是，既然U3D提供了如此便利的东西，我们为何不用呢。 因为有许多事件的检测，U3D已经为我们做好了，并且，也只有挂接在此对象上的脚本，才能够监听到这些事件，比如OnTriggerEnter。