组件模式让不同功能模块耦合性更低

        当你掌握一门编程语言时，你会发现编写代码实现你想要实现的功能是一件相当容易的事情。难的是编写能够容易应对需求变更的代码。刚入行时曾经维护过一个游戏项目，项目挺赚钱的，流水月月过亿。可以说外表很光鲜，第一次看到那代码时我傻眼了，那代码写的那叫一团糟。游戏主逻辑全写在一个类中，导致那个文件累计了10000多行的代码，一个帧循环里面竟然写了1000多行的业务逻辑。重要的功能逻辑几乎全部耦合在了一起，每次增加新的业务都是痛苦的过程，就算对于熟悉它的程序员也难保不出BUG，对于新手来说就如同炼狱了，微不足道的修改都会产生深远的影响，产生BUG的速度就远远超过了其实现功能的速度。 对一个正在线上运行的赚钱项目，重构是很冒险也太讨好的事情，最后无奈只好离职了。

        说这么多废话只是突生感慨。设计模式对于我们开发工作来说是多么重要。在程序设计中如果我们能更好的保证不同模块充分解耦，让一个模块的变化尽量不会影响到另一个模块，那么你在更改游戏的一些功能时，代码更改的就会越少，也会越简单。设计模式用的好，编码开心下班早。

       跑题了，这次要说组件模式的。 

        所谓组件模式就是为了解决单一实体跨越了多个域产生耦合的问题。为了能够保持域之间的相互隔离，每个域的代码都独立存放在自己的组件类中。实体本身则可以简化为这些组件的容器。

        在使用cocos2dx进行开发时，游戏中的实体基本都是继承自Node类。游戏中需要的渲染，物理特性等都集成在Node类中，这样通过继承的方式能够保证继承自它的子类充分的复用渲染，物理的功能，而且针对渲染和物理的耦合只限制在基类中。但是我们的子类有的可能仅仅需要渲染的功能，有的仅仅需要物理的功能。使用继承，那么就会让仅仅需要渲染的子类实例内存中存在物理相关的一些状态，同时也使仅仅需要物理特性的子类实例内存中存在渲染相关的状态。这样就导致了代码的重复。

        如果我们把物理，渲染先关的功能独立成一个单独的对象。一个实例需要渲染，那么就给他传入一个渲染的实例，如果它还需要物理的实例，那么就给他传入一个物理的实例。这种基于组合的方式构建一个实体，正是组件模式的核心。

        现在我们使用的unity，cocoscreator都是基于组件模式的。我们的Node只拥有一些位置等相关的状态，如果你想要一个精灵，那么给这个Node添加一个Sprite组件，他就成为了一个精灵，可以渲染一张图片。如果它还需要碰撞的功能，那么就给他添加一个碰撞组件，它便有了碰撞的属性。如果你需要编写代码操控这个节点，那么这个脚本文件也可以是一个组件添加到这个Node上。你也可以很方便的通过添加组件的方式把这个脚本复用到一个新的Node中。当你习惯了基于组件的编程模式之后，你会发现它把不同代码模块的耦合降到了最低。

        这种设计模式与GoF中的策略模式很类似。都是将对象的行为委托给一个独立的从对象。不同的是策略模式的“策略”对象通常都是无状态的，它封装了一个算法，但是没有数据。它定义了一个对象的行为方式，而不是对象本身。组件本身具有一定的功能性。它们经常会持有描述对象以及定义对象实际标识的状态。然而，这个界限可能有点模糊。你可能有一些不需要任何状态的组件。在这种情况下，你可以在跨多个容器对象的情况下使用相同的组件实例。在这一点上，它的确表现得像是一个策略对象。

参考:http://gameprogrammingpatterns.com/component.html