关于游戏对像样继承自CCSprite还是引用CCSprite的思考，想来想去，还是面向对象的思想的区别
游戏对象继承自CCSprite是很多游戏示例的写法，很多，但不是全部，毕竟谁也不想自找麻烦，去引用CCSprite让它负责游戏对象的输出但游戏对象此时往往不派生自CCNode（有人要泪奔！）了，那末继承自NSObject的游戏对象是要闹哪样？我想来想去，初步的答案是思路清晰,解耦（接口分离原则）和多态的方便。准备跟老师讨论这个问题,答案待定,不允许评论,以下只是个人想法,纯属个人观点.
引用CCsprite并继承自NSObject的游戏对象往往需要自己实现CCStandardTouchDelegate或者CCTargetedTouchDelegate。此外必须从CCTouchDispather注册和移除delegate、还要使用CCScheduler（这是一个没有说明文档的类！！好吧，英雄不问出处）。
1但是一个有着自己游戏数据逻辑的游戏对象是一个模型，它怎么能是一个精灵对象呢，不符合MVC原则。
2关于解耦：请问继承的弱点是什么？为什么C++的多继承被谨慎地使用？因为继承会让一个类变得过于繁杂，庞大。面对一个又能唱歌又能写论文又能编程又会美工又会技术又会销售又会修理机械的对象，我想不是这个对象逆天了，而是修改和使用这个类的人要升天了。所以要解耦，解耦让概念清晰，类之间分工明确，即便要实现协议和引用，那都是算对象通信，合情合理。
3多态的使用，有人要发问了，继承CCSprite一样可以多态啊，没错，但是，同一个对象明明我的游戏数据大部分没有改，只是带上了装备不一样，它弄了一个分身跟自己同屏出现，然后为了让别的玩家区分自己和分身，自己换了一顶帽子。这时你的程序在内存居然要把对象复制一遍，然后去实现多态。但这个对象仅仅是换了一顶帽子，这科学么？
如果这个游戏对象有多重影分身（难道我火影中毒？），那你的程序可能要崩溃了，因为你的对象是继承自CCSprite类的，要做区分，只能是重新copy，但是如果是引用的情况，则不是，我用CCSpriteNode和纹理图册把自己各个分身都画一下，对象数据只有一份，只是给自己画几十个精灵图像而已！这个差别随着这个对象的属性数据的庞大而愈加明显！！！！！