OO的应用~~~对游戏中涉及到的人,事,物进行抽象和分类

6spring

补充一下，原来之所以那么考虑，主要出于往往对原有东西的修改，会引出很多莫名的的问题，还不如模块化，模块简单且只专注于一方面的逻辑。

nwin9x2

6spring的意思是:把对象的所有特性,所有对象间的交互都用数据来配置?
这相当于:设计一个大而全的类支持游戏中所有的对象特性,做一个"终极抽象".
显然,这是不现实的.几乎所有的C++/JAVA等OO语言的教科书上都会告诫读者不要这样干.

6spring

-____-|||

不是这个意思。

我意思是，属性以模块化方式加入容器，是一个扩充过程。
而属性模块不是单单一个数据元素，而是一种功能的模块。
例如移动模块，他只管移动的相关操作，我给一个对象添加上这个模块，那么该对象就拥有移动操作。虽然继承也能实现类似功能，但是多继承可能出现的二义性很麻烦，单继承层次会很深。

继承带来最麻烦的一点，是有一天想添加什么进去，发现，他需要的东西恰好是在树的几个分支上。。。

再说直白一点，做很多的组件，然后用组件堆砌出一个完整的功能对象，而组件也是这种功能对象，也可以由其他组件堆砌出来。

就比如说操作系统，就是由各种大大小小的组件构成。

nwin9x2

to 6spring:
我认为你的想法理论上可以实现.不过每个对象都要"挂"一串的模块,其中每个模块都含有一组虚函数.鉴于虚函数的开销,恐怕在这种方法在性能上达不到实用的要求,因为游戏世界里有数十万个的各种对象哪.

shengkz

6spring 的意思是？  类似 java 里面的 implements 还有 extends ？

类似——可以拥有多重继承的衍生类，不知道怎么弄来着，忘了

shengkz

extends 继承类；implements 实现接口。

类和接口是不同的：类里是有程序实现的；而接口无程序实现，只可以预定义方法 extends 继承类。


implements 实现接口：
Java也提供继承机制?但还另外提供一个叫interface的概念。由于Java的继承机制只能提供单一继承（就是只能继承一种父类别）?所以就以Java的interface来代替C++的多重继承。interface就是一种介面?规定欲沟通的两物件?其通讯该有的规范有哪些。如以Java程式语言的角度来看?Java的interface则表示：一些函数或资料成员?为另一些属于不同类别的物件所需共同拥有?则将这些函数与资料成员?定义在一个interface中?然后让所有不同类别的Java物件可以共同操作使用之。
Java的class只能继承一个父类别（用extends关键字）?但可以拥有（或称实作）许多interface（用implements关键字）。


extends和implements有什么不同？
对于class而言，extends用于（单）继承一个类（class），而implements用于实现
一个接口（interface）。
interface的引入是为了部分地提供多继承的功能。
在interface中只需声明方法头，而将方法体留给实现的class来做。
这些实现的class的实例完全可以当作interface的实例来对待。
在interface之间也可以声明为extends（多继承）的关系。
注意一个interface可以extends多个其他interface。
====================
看看这段资料

zfscnu

恩~~~~ 好象这些不太适合在策划版块讨论的把、、、、、

6spring提到的“基本思路是 逻辑对象，全部看作容器，容器里放上某种属性对象，他就具有这种属性，移除某种属性对象，就失去该属性。”

其实用 GOF 23模式中的Decorator 装饰模式来组织会更好，比如 移动操作，不同的对象的移动需求都不一样把，怎么去写 移动操作的模块呢？

而 Decorator 装饰模式也常用来避免出现“继承带来最麻烦的一点，是有一天想添加什么进去，发现，他需要的东西恰好是在树的几个分支上”

6spring

大家讨论都很激烈嘛，呵呵

我原本所想，这种模型，仅仅用在那种需要大量改变，需要不停添加新元素的地方。

往往这种多变的元素部分，大多是同时只出现有限个，在效率上可能反而不如扩展性来得重要（例如逻辑部分很多人喜欢使用脚本系统来完成，而不是硬编码，也是类似考虑吧）。
比如说NPC对象，需要同时处理的数量也不会大到哪里去，但是其所带有的功能属性怕是反而需要多变性

To zfscnu : 我说的差不多就是Decorator，当然了，把它用在逻辑对象（注意是是逻辑对象），具体合适不合适另外一说，只是有感于继承树庞大后带来的各种很难把握的问题，有类似考虑而已。

当然，对设计模式有好感的人，都很容易犯“为了模式而模式”的错误，我肯定也不能免俗了，这只是说个自己的想法，大家看看就好。

nwin9x2

decorator(装饰)模式适合给对象动态的添加功能.不过在游戏中,貌似一个对象的功能很少在运行时需要添加,改变的.例如,一件装备--匕首.在它创建的时候就可以确定它不需要具备走路的功能.一个角色对象,在它创建的时候就可以确定他需要走路的功能.
decorator是很灵活,不过我认为如果要把游戏里的所有对象用decorator模式实现,似乎不太合适.举例:每个角色对象都需要"挂"很多个decorator,开销比较大.并且在使用一个对象时,总是需要先查询它是否已经拥有了某个"decorator",编码也不方便.
另注:我说的NPC是指所有的由AI控制的角色,它们的数量在游戏世界里面可是很可观的.

6spring

似乎nwin9x2有些误解了，任何设计都有个度，不是说哪里都用，只用于合适的地方而已。我这里也只随便说说，只是个在一时不好很好的归纳抽象出基层类树时（一般基层类的改动，往往是灾难性的），不失为一个解决方案而已。

倒是对于技术难度上，也不是很难实现，基本上一个hash_map和良好的消息映射大致可以解决一些问题了。

而且既然是挂接，那甚至可以部分抽象到类似 pCaller-> 的操作，也就是一个控制对象去操作调用对象，也就是1 VS N 模型。而这些控制对象即使不好1 VS N，但只要粒度合适，还可以使用对象池等技术，使得重用性加强，使其可反复用在不同类型的对象身上。

不过还是说一句，这仅仅是随意的一个思路，也仅仅适用于合适的地方，比如说用到道具、比较固定的物体上，完全不合适。但是假设这个是类似网络共享镜像对象，那可就有些用处了，可以在完全不改动原有逻辑功能的前提下，开发新的功能模块，而模块的装卸控制也可以由服务器动态管理。

什么用法都有个度，单纯追求效率与单纯追求构架都是浮云，大家还是打住，再往下就不合适了，大家都有钻牛角尖的趋势  ^___^