组件(Component)这个概念最早是在2005年《Game Programming Gems 5》的《Component Based Object Management》中接触到的，当时感觉在设计上很实用。后来，发现Unreal Engine 3的一个重要的改进就是抛弃了以前的基于纯派生关系的对象 模型 ，而转为使用 基于组件 的对象 模型 。对于这种设计思想，Unity比Unreal贯彻的更彻底——一切皆Component。
那么到底什么是“基于组件”的对象 模型 ？它能够解决什么问题？
在传统的设计中，我们一般会使用“派生”来描述对象之间的关系。子类通过派生父类，来获得父类的功能。在设计游戏对象时，会根据游戏本身的需要而为游戏对象添加各种功能支持，比如渲染，碰撞，刚体，粒子系统等等。这些通用功能为了能够为各种派生类提供服务，都必须实现到基类中。这样就导致了游戏对象基类变得非常庞大臃肿，即难使用，又难维护。
”基于组件“的对象 模型 就是把所有需要提供给游戏对象的基础功能都独立成单独的”组件模块“(Component)，一个具体的游戏对象可以将它需要的功能模块组合到一起使用。所有”功能“不再是父类中的接口，而变成子对象实例，为游戏对象提供服务。这样既保证了功能代码的可重用性，又增加了整个对象体系的模块化和灵活度。
在Unity中，GameObject除了作为Component的容器之外，基本上没有其他功能。所有需要的功能都要通过组合Component来实现。脚本本身也是Component，用来在GameObject上通过控制其他Component来实现自定义的功能。虽然这些Component在物理上是完全并列的关系，但是他们之间还是会有一定的层次关系的。在设计一个游戏对象的具体功能时，组件一般会被分为三个层次。
引擎的基础组件
Unity本身提供的各种内部功能组件。比如渲染组件，物理组件，声音组件等等。这些组件实现了所有引擎提供的基础功能，会被脚本使用来组合高级功能。
模块功能脚本组件
通过脚本实现的一些相对独立的通用模块功能的组件。这类 组件的设计 是脚本可重用的关键，需要仔细分析游戏对象中哪些功能可以被独立出来成为一个可重用的功能模块组件，并且在实现上应该尽量降低与其他组件的耦合性。比如在设计一个角色游戏对象时，需要为他设计换装功能。换装功能其实就是对显示子对象进行分组管理，切换显示状态。这个功能相对独立，与其将他实现到角色中，不如独立成一个功能模块组件。角色游戏对象和其他所有需要换装功能的游戏对象都可以通过包含这个模块组件来实现换装功能。
模块功能组件之间还可能有依赖关系，也就是一个功能模块组件可能依赖与另一个功能模块组件，从而在这个组件层次上形成更多的子层次。
高层的胶水代码脚本
这些脚本用来真正将引擎基础组件和模块功能组件组合到一起实现最终游戏对象逻辑。用“胶水代码”来形容这些脚本非常的贴切，就是把所有这些子功能“粘”在一起。比如设计一个Player脚本，将所有需要的组件功能组合起来，实现一个玩家的具体游戏逻辑。因为这一层次代表的都是最高层的游戏行为控制对象，是具体的游戏逻辑的“胶水”代码，不会再为更上层提服务，所以本身的可重用性并不高。但是这些对象之间按照类型区分，往往会有一些功能上的重合，所以反而可以继续使用派生关系来实现功能的重用。比如在Character中实现所有的基础功能(这些功能又是通过组合基础组件来实现的），而Player和NPC都从Character派生，来继承所有Character的功能，并继续实现自己特殊的功能。一个功能到底应该用组件实现还是用派生实现并没有非常明确的界限，应该根据需要灵活运用。
在使用Unity的过程中，如果要实现的是demo级别的小工程，并不需要考虑很多，直接用脚本实现功能就可以了。但是如果要有效地组织复杂的工程，提高代码的重用性，充分理解和合理的利用“基于组件”的对象 模型 设计思想还是很重要的。