游戏后端开发中的设计模式（2）结构模式

文章会分成三篇，分别从创建型模式，结构型模式和行为模式三种划分，简单回顾下游戏开发的工作过程中对设计模式的使用。有纰漏之处，欢迎交流指正。

例子代码使用Golang实现，设计模式部分参考了refactoringguru.cn

结构型模式：是关于程序中对象之间结构关系的设计模式。游戏中的对象通过组合等方式关联起来，例如玩家对象会持有装备对象，怪物对象之间会遵循同样的行为模式等。

1. 适配器模式

简介

重点在于“兼容”。当对象的使用场景发生改变的时候，原有的对象可能无法按照预期工作。就像手机的充电头，如果出国旅行的话，会发现插座的接口形状不一样。本质上是并行的两套充电“标准”发生了冲突，如果我们根据新场景的“标准”为使用的对象增加“适配器”，将自己的对象转换为新场景可用的标准形式（比如购买符合当地标准的充电头），我们的对象在这套“标准”之下就能如期进行工作了。这也是适配器模式的本质。

适配器模式有两个前提条件：

1. 有两套并行的交互标准A和B，每一套标准都能独立实现相同的功能。
2. 两套标准存在可以转换的前提。

实现

1. 声明客户端接口，描述客户端如何与服务器交互。现有的服务对象遵循该接口。
2. 创建适配器（Adapter）类，实现客户端接口。类里面添加一个成员变量保存对服务对象的引用，并将实际工作委派给该对象。
3. 客户端根据客户端接口调用适配器类，就像调用原服务对象一样。

游戏开发中的应用

在游戏后端开发里，并没有太多的“标准”，遇到不兼容的部分往往可以直接修改（就比如把直自己的充电头插脚改了），如果套用适配器模式，引入额外的适配器对象，可能会造成代码冗余的问题。

要使用适配器模式的话，对于一些对象转换的问题，例如普通物品（NormalItem）和掉落物品（DropItem）的转换，就可以通过适配器模式解决。

package main

//玩家结构，里面有道具Map
type player struct {
   
	item map[int32]int32
}

//普通道具
type normalItem struct {
   
	id  int32
	num int32
}

//掉落道具
type dropItem struct {
   
	id     int32
	num    int32
	weight int32
}

//客户端（玩家）与服务（道具）交互的协议，是两套并行的标准
type normalItemI interface {
   
	addNormalItem(p *player)
}

type dropItemI interface {
   
	addDropItem(p *player)
}

//接口（标准）的实现
func (i *normalItem) addNormalItem(p *player) {
   
	p.item[i.id] += i.num
}

func (i *dropItem) addDropItem(player *player) {
   
	player.item[i.id] += i.num
}

//适配器，将dropItem转换为能使用normalItem标准的形式
type itemAdapter struct {
   
	dropItem *dropItem
}

//实现和normalItem相同的接口，里面有具体的转换工作
func (i *itemAdapter) addNormalItem(player *player) {
   
	i.dropItem.addDropItem(player)
}

func main() {
   
	p := &player{
   }

	nItem := &normalItem{
   id: 1, num: 1}
	dItem := &dropItem{
   id: 2, num: 2}

	nItem.addNormalItem(p)
	dItem.addDropItem(p)
	adapter := &itemAdapter{
   dropItem: dItem}
	adapter.addNormalItem(p)