在之前的小游戏项目中，处理websocket长连接请求的时候，需要根据传递数据包的不同类型，进行不同的处理。为了实现这个场景，比较简单的方法就是使用if-else或者switch-case语句，根据条件进行判断。但是这导致了项目代码复杂混乱，不利用项目后期的维护和扩展。

策略模式和观察者模式都可以解决这个大量条件判断的问题，相比之下，观察者模式比较复杂，适用于更加复杂的场景。而策略模式则比较轻便，简单易上手。

关于观察者模式，感兴趣的朋友可以看这一篇博客：

观察者模式的理解和引用-CSDN博客

旧代码如下

		//在信息中枢处根据消息类型进行特定的处理
		
		switch requestPkg.Type {
		case pojo.CertificationType:
			//用户认证
			client.CertificationProcess(requestPkg)
 
		case pojo.CreateRoomType:
			//创建房间号,并将创建者加入房间
			client.CreateRoomProcess()
 
		case pojo.JoinRoomType:
			//1.加入房间的前提,先建立连接
			//2.完成用户认证
			//3.发送消息类型和房间号 Type uuid
			//只有完成上述步骤,才可以加入房间
			var data map[string]interface{}
			err = json.Unmarshal([]byte(requestPkg.Data), &data)
			if err != nil {
				fmt.Println("解析 JSON 失败：", err)
				return
			}
			uuidValue, ok := data["uuid"].(string)
			if !ok {
				fmt.Println("uuid 字段不存在或不是字符串类型")
				return
			}
			client.JoinRoomProcess(uuidValue)
 
		case pojo.RefreshScoreType:
			//什么是否进行分数更新，前端判断 type:RefreshScoreType, data:step、step、score
			//当用户的行为触发前端游戏机制的更新时，前端调用此接口，后端进行分数的转发 不需要做业务处理，直接转发即可
			fmt.Println("游戏交换中数据", client)
			client.RefreshScoreProcess(requestPkg)
 
		case pojo.DiscontinueQuitType:
			client.DiscontinueQuitProcess()
 
		case pojo.GameOverType:
			//游戏结束类型好像没有太大用，游戏结束的时候的提醒，通过分数更新就可以实现了
			fmt.Println("GameOverType")
 
		case pojo.HeartCheckType:
			//开启一个协程遍历hub中的Client，进行健康检测，生命时间是否会过期，如果过期进行逻辑删除和关闭连接
			if requestPkg.Data == "PING" {
				client.HeartCheckProcess()
			}
		}

策略模式介绍

策略模式是一种软件设计模式，它允许在运行时选择算法的行为。策略模式定义了一系列算法，并使它们能够相互替换，从而使算法可以独立于其使用者而变化。这意味着在实际使用中，可以在不修改其结构的情况下轻松地切换或替换算法。在我们的场景下，我们通过websocket连接获取到的数据包有很多的类型：CertificationType、CreateRoomType、JoinRoomType、RefreshScoreType、DiscontinueQuitType、GameOverType、HeartCheckType等类型，我们需要根据不同的类型对数据进行不同的处理。即在运行时，根据传入的Type值，选择不同的行为进行处理，使得我们可以在运行的过程中轻松切换行为。【这里可以将算法理解成对同样结构的输入，进行不同的处理。】

Context上下文对象类：该对象持有对策略接口的引用，可以根据需要动态地改变所使用的具体策略。这样，客户端调用上下文对象的方法时，就可以根据所设置的具体策略来执行相应的算法。

//将Strategy策略作为Context上下文对象的一个字段
//封装get、set、execStrategy(执行方法)
type Context struct {
	Strategy handler.Strategy 
}

func (c *Context) SetStrategy(strategy handler.Strategy) {
	c.Strategy = strategy
}

func (c *Context) GetStrategy() handler.Strategy {
	return c.Strategy
}

func (c *Context) ExecStrategy(client *pojo.Client, request req.WsReq) {
	c.Strategy.StrategyMethod(client, request)
}

Strategy策略接口：定义接口，接口里面是StrategyMethod（）方法，在Context对象的ExecStrategy（）方法中被调用。

type Strategy interface {
	StrategyMethod(client *pojo.Client, request req.WsReq)
}

ConcreteStrategy具体策略类：该类实现Strategy接口，并且根据自身的需要定义StrategyMethod（）方法具体的业务代码。

type LifetimeCheck struct {
}

func (c *LifetimeCheck) StrategyMethod(client *pojo.Client, req req.WsReq) {
	if string(req.Data) == `"PING"` {
		client.User.Lifetime = client.User.Lifetime.Add(10 * time.Second)
	}

	wsResp := resp.WsResp{Type: req.Type, Data: "PONG"}
	if err := wsResp.WsResponseSuccess(client); err != nil {
		zap.L().Error("PING 返回出现错误")
		return
	}
}

客户端代码：创建上下文对象，根据需求，去调用SetStrategy（）方法，并执行所设置策略的行为。我们的选择可以通过Map进行，根据map的key获取对应的具体策略对象。

func WsController(client *pojo.Client) {
	//map初始化之后就没有写入操作了,所以不存在线程安全的问题!!! 只会进行读取操作
	context := new(Context)
	
	//1.执行认证行为
	context.SetStrategy(new(specificHandler.CertificationStrategy))
	context.ExecStrategy(client, request)

	//2.执行心跳检测
	context.SetStrategy(new(specificHandler.LifetimeCheck))
	context.ExecStrategy(client, request)

	//1.执行聊天信息
	context.SetStrategy(new(specificHandler.ChatStrategy))
	context.ExecStrategy(client, request)
}

通过这样改造之后，我们的代码就可以实现：

1. 算法可以独立于客户端而变化，客户端可以更灵活地选择算法。
2. 可以避免大量的条件语句，将算法的选择和使用分离开来，提高了代码的可维护性和扩展性。
3. 可以方便地增加、删除或更改算法，不会影响到客户端的代码。

总的来说，策略模式可以帮助我们更好地组织和管理不同的算法，使系统更加灵活、可扩展和易于维护。

策略选择改进

读到这里，大家可以发现，其实还是没有办法解决我们代码里面出现的大量if - else语句，我们需要通过if - else来做判断，帮助我们选择对应的行为。其实，这里可以引入map帮助我们来做选择，如果命中map中的key,就返回对应的算法对象。
代码如下：

func WsController(client *pojo.Client) {
	//map初始化之后就没有写入操作了,所以不存在线程安全的问题!!! 只会进行读取操作
	context := new(Context)
	handlerMap := map[string]handler.Strategy{}

	//对客户端发送过来的对应请求类型,进行注册操作
	handlerMap[CertificationType] = new(specificHandler.CertificationStrategy)
	handlerMap[ChatType] = new(specificHandler.ChatStrategy)
	handlerMap[CommentNotificationType] = new(specificHandler.CommentNotification)
	handlerMap[FansNotificationType] = new(specificHandler.FansNotification)
	handlerMap[CloseType] = new(specificHandler.CloseConnection)
	handlerMap[LifetimeCheckType] = new(specificHandler.LifetimeCheck)

	for {
		request := req.WsReq{}
		//循环读取对应的类型，并进行反序列化
		client.Conn.ReadJSON(&request)
		//通过定义的map,通过对应的数据类型获取算法对象。如果能够获取到更改上下文，并执行匹配到的策略，处理数据
		if strategy, ok := handlerMap[request.Type]; ok {
			context.SetStrategy(strategy)
			context.ExecStrategy(client, request)
		} else {
			zap.L().Error("长连接请求类型不存在")
		}
	}
}

更改后的代码整体结构：

总结

代码并不是能跑就可以了，如果可以的话，请尽可能地优化自己的代码，让自己的代码利于维护和扩展，可读性高。