游戏中人物跟物品的一个疑惑

简单的话 接口应该放在人物上，不过，人物使用某种物品，和其当时扮演的角色有关，包括当时的场景，所以，不能僵化地直接耦合到人物中。

见DCI架构。

这个来说，首先角色与物品在项目开发中应是两个不同模块，甚至是两个不同的PROJECT
然后物品的对象在角色身上存在引用，最好是接口的形式
然后在这个物品接口上，加入一些必要的操作物品用方法，比如增加，删除，修改，查询等等。

我在游戏公司，我们的游戏采用的方式是，用配置文件来配置物品，然后物品的使用是用脚本来控制。

物品用什么来配置并不重要。在游戏中物品应至少分为两部分数据：系统数据与角色数据，你说的配置文件与脚本只是系统数据相关部分。而你开楼中的用意应该是角色数据部分。并不存在直接冲突。

物品会有角色数据？不知道你们的游戏是如何设计的。物品与角色本来就该是两个完全隔离的系统。暴露给人物的接口根本就不该是物品的接口。使用物品无外乎还是对人物自身造成影响。归结到底，操作的始终是角色本身，而不是物品。涉及物品的操作无外乎就是使用失败或者无法使用。

人与物都是相互独立的。内聚是体现结构，并不是行为相关。正如banq所说到的DCI思维，可以很好地分析：人成为物品使用者而进入物品使用场景，进而使用物品。而这里使用物品是一个场景行为，若果一个人无论在什么状态下都可以使用物品，则可以当作共性归到人中。

我也是做游戏的 既然character和item分开了 那这个时候应该把使用item的行为归结到service中建立一个CuIservice

呵呵，这个是面向对象过不去的坎儿。

我的回答是，既不是人物的方法，也不是物品的方法，而是一个同时关联到人物和物品的方法，调用依靠模式匹配找到对应的处理。

如果有场景，这个调用还应加上场景，在prolog中可以直接写为：

Character use Item in Scene

非常简单，没有乱七八糟的耦合，也不用苦思冥想各个对象应该到底如何安排。

也许会有人觉得是退回到了过程式，但实际上不是，过程式不会依靠模式匹配来调用方法。
[该贴被uda1341于2011-04-06 17:02修改过]

这个案例是典型的用户使用什么物品的场景，试验想想，计算机软件系统中的所有功能都是用户人物操作的，是不是要把这些功能都写到用户人物这个类中呢？

面向对象可以以类为边界划分，也可以以功能为划分边界，也可以在设计时分开，运行时合并动态划分边界，这个案例中，套用“人在某个戏中演某个角色，然后执行该角色应有的功能”这个思路，又比如：你在家是儿子，在单位是经理，那么是不是把你孝顺的动作封装在你这个人物类中呢？那么你到单位扮演经理角色时，孝顺这个动作用不到了怎么办呢？

所以，动作其实是和角色有直接关系，而不是和具体人物，但是当作不适合直接封装在角色中，而是通过具体一个场景Context，将人物 角色和动作在这个场景运行时动态合成，编程时，三者都是分开的，这是DCI原理。