抽象物品这个词汇是我为了说明方便生造出来的，用于指代游戏系统中任意可以附加于玩家的东西，比如金币、宝石、经验、道具、英雄、宠物、装备、积分、体力等等，都可以用通用抽象物品接口来替代。其实抽象物品几乎所有游戏项目都在用(至少我接触过的项目都有)，只是没人去正经的归纳。
数据结构
这个东西说白了其实就是一个union，里面包含了可能的各种数值和数据，当然了因为是unoin嘛，其中只有一部分会起作用。这里给出我们项目中使用protocol buffer定义的数据结构。
嗯，看上去还是挺复杂的。CommonItem包含了一个type字段指明了该抽象物品的具体类型，后面是各种具体物品携带的数据，可能是玩家的某个属性值，可能是背包、英雄等，注意我们使用了optional选项。 当然了，也可以直接记录几个数字，第一个数字代表类型，后面几个数字的意义由类型来决定。也有直接用带分隔符的字符串来表示的。原理上来说都是类似的，我觉得使用protocol buffer进行结构化的表示更加直观一些。
为什么做抽象
上面也说了，这个结构是比较复杂的，而且构建和解析也会比较费劲，那么我们为什么折腾出这么个东西呢。主要有下面几个原因：
1. 解耦各个模块
当系统中一个模块调用另一个模块时，就产生了依赖，依赖无疑是需要我们竭力减至最小的。注意到两个模块间调用时大部时候都是在修改彼此的数据，更进一步，大部分的数据修改都在添加或消耗某些东西。比如副本掉落道具添加进背包，打副本时消耗体力，完成任务时添加经验和金币。
假如副本能同时掉落金币、经验、体力、背包物品，那么副本就同时依赖这些模块，也就是说这些模块中任意一个的接口发生变化时，我们就不得不修改副本模块的代码。再来看背包，副本、任务、宝箱、商店都会改动背包的数据，所以这些模块同时依赖于背包模块，所以如果我们改动了背包的接口，这些模块的代码都要修改。
很显然，这里是一个很不合适的M*N的关系。所以我们需要加一个分发模块作为“中介”，抽象物品作为“载体”。所有的调用模块都只依赖分发模块，它们只需要知道需要添加或消耗抽象物品，而不关心具体维护对应数据的模块。分发模块负责将抽象物品分发到不同的数据模块。这样一来M*N的关系就变成了M+N。
2. 配表更加灵活
就拿副本掉落举例子。如果没有抽象物品，当策划想让副本掉落金币时，可能会在表里加一列，定义为金币。等过了几天想换成掉经验，于是通知程序修改代码……又过了几天觉得还是换成背包物品比较好，于是又多加了几列，再通知程序修改代码……更杯具的是，如果到后期新开放了积分系统，好多配表都需要添加积分这一列。这样显然不是很灵活。
如果有设计恰当的抽象物品，很多产出和消耗都可以配成抽象的物品，策划可以很灵活自由地修改数值。程序这边也很方便，只需要写一次解析抽象物品配置的代码。
3. 方便交换数据
例如抽卡功能，服务器需要把抽出的结果返回给客户端显示，这时直接使用抽象物品这个数据结构来交换数据，定义消息接口时不用关心具体产出物品的类型。 另一方面，不管抽象物品实际是金币还是背包物品或是能量，客户端总是要以相似的形式在界面上显示出来：常见的一个图标、图标下方有物品的名字、图标的右下角是数量。有了抽象物品这个结构后，只需要正确处理好对抽象物品的显示，所有系统的界面都可以直接调用了，而不关心那个系统所要展现的具体是个什么东西。
分发模块设计
分发模块上文已经大略介绍过了，可以简单地理解为一个代理，其功能是把对抽象物品的操作映射到对实际数据的操作。
分发模块主要定义这三个接口：
Add(CommonItem) 添加一项抽象物品
Remove(CommonItem)删除一项抽象物品
Has(CommonItem) 判断玩家是否拥有一份抽象物品
另外一个要解决的问题是，有的数据不是直接附加于玩家本身的，比如英雄经验应该附加于某个英雄上，技能经验应该附加于某个技能上，等等。所以我们在添加一项抽象物品时，可能还需要一些额外的上下文数据(英雄id，技能id，宠物id等)，这些上下文数据应该是触发操作的环境中可以获取的。例如对于打副本，上下文数据中就应该包含当前出战的英雄，副本模块应该负责将自己的上下文数据告知分发模块，以供其正确分发。
所以最后分发模块的接口这样定义：
Add(CommonItem, Context) 添加一项抽象物品
Remove(CommonItem, Context)删除一项抽象物品
Has(CommonItem, Context) 判断玩家是否拥有一份抽象物品
其中Context中包含由调用者感知的上下文数据。可能的问题是：如果数据配置有总是，当发现要添加的抽象物品是英雄经验时，上下文数据中并不包含英雄id(可能是开宝箱触发的)，那么此时无法正确添加。坦率地说，这种问题现在想不到好的解决办法，这也是抽象统一接口所带来的代价吧!
