今天我们讨论的主题是设计模式，以及如何在cocos2d里面实现它。来自波兰的Bartek Wilczyński写了一系列的文章来介绍这个模式，同时说明了为什么要使用mvc，以及如何在cocos2d里面使用mvc。

    这个波兰人写的文章已经被我全部翻译过来了，请点击查看。

    当我在读他写的这些文章的时候，我记得Jeremy Flores在github上面有一个cocos2d里面实现mvc的版本库。他把它取名为，全名是Model-Node-Controller。并且代码是开源的，MIT许可。

    这个MVC模式和游戏实体组件系统差不多，我在里面就有介绍过了。对于这两个系统来说，它的思想都是统一的，那就是不要继承CCSprite并把游戏logic全部塞到sprite里面去。CCSprite应该只负责渲染显示。而且有时候，你可能需要创建很多sprite，我们最好是创建一个CCNode类，然后里面聚合许多sprites。这样CCNode成为了Controller，控制view。当view（比如sprite，effect，gL drawings等等）在屏幕上面移动的时候，controller结点会轮询所有它包含的结点来查询一些游戏相关的状态信息，并且做一些游戏逻辑，然后反过来再更新view。

    对于小游戏来说，mvc模式确实可以运行地很好。它比起直接继承CCSprite，并把一大堆处理逻辑放到CCSprite里面要强多了。如果你发现，你还是不停地继承ccsprite，然后把一大堆处理逻辑塞到一个ccsprite的子类里面，那么你就应该考虑一下mvc设计模式了。

     当我们在cocos2d论坛里面提到“？”这样的问题的时候，我还是要再强调一点，多用组合，少用继承！如果一味地使用继承，那么当游戏世界里面的对象种类变多，功能变复杂以后，会导致整个继承树“头重脚轻”，严重破坏了良好的面向对象设计原则---我们设计的类层次结构应该是扁平结构的，而不是一个头很大的树。

    那么，我们需要使用怎样的架构来处理游戏里面的对象呢？答案就是使用组合。现在已经有一些非常好的引擎，比如、、Unity3D等，它们都是基于组合的实体组件系统。

    你可以从里面得到有关实体组件系统的介绍。同时，可以读一读《》这篇文章来加深对实体组件系统的理解。

     你还可以从上获得更多的信息。实际上，objc语言本身就是被设计为一种可重用的软件组件。

    Scott Bilas在2002的GDC大会上提出了一种，同时使用了这个新理念，它指出了为什么继承对于游戏开发者来说非常不好，还说明了基于对象组合的组件系统的优点。事实上，在2002年，我开始与一起工作的时候，我们已经有一个组件系统了，我们把它叫做Aspects、Abilities和Spells。它可以帮助我们把所有的游戏数据都存储到数据库里面，程序员只需要写一些泛型代码来统一处理这些数据就行了。

    在2009年的GDC大会上面，Radical Entertainment’s Marcin Chady也做了一个类似的ppt，大家可以。

    Mick West还写了一篇文章，《》，在这篇文章里面，它很好地描述了，为什么要更改以前的继承模型，转而投向组件系统的怀抱。

    还有一些更高级的读物，比如一些paper《》 ，它基于讨论了组件系统，而且引入了基于规则的NPC行为系统。

   在Game Architect 博客里面把它称之为，并且指出了基于继承的类设计的一些缺点，同时展示了使用组合如何来解决这些问题。

 

  后记：《如何在cocos2d里面实现mvc》这一系统的文章到此就全部结束了，非常感谢大家的耐心阅读。mvc在cocoa开发中被广泛使用，几乎没有哪一个ios开发者不知道mvc。但是，mvc不是银弹，没有银弹！我个人觉得基于组件的实体系统和fsm更适合现在游戏架构。由于本人水平和经验有限，故只能翻译这么多。这篇博文提到了其它许多没有翻译过的文章，建议大家都读一读。我也不打算翻译了。有兴趣的同学可以翻译出来，为开发者社区贡献一点力量。

 

   全剧终！

 

参考文献：