在之前的小游戏项目中，处理websocket长连接请求的时候，需要根据传递数据包的不同类型，进行不同的处理。为了实现这个场景，比较简单的方法就是使用if-else或者switch-case语句，根据条件进行判断。但是这导致了项目代码复杂混乱，不利用项目后期的维护和扩展。
策略模式和观察者模式都可以解决这个大量条件判断的问题，相比之下，观察者模式比较复杂，适用于更加复杂的场景。而策略模式则比较轻便，简单易上手。
关于观察者模式，感兴趣的朋友可以看这一篇博客：
旧代码如下
//在信息中枢处根据消息类型进行特定的处理
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)
}通过这样改造之后，我们的代码就可以实现：
- 算法可以独立于客户端而变化，客户端可以更灵活地选择算法。
- 可以避免大量的条件语句，将算法的选择和使用分离开来，提高了代码的可维护性和扩展性。
- 可以方便地增加、删除或更改算法，不会影响到客户端的代码。
总的来说，策略模式可以帮助我们更好地组织和管理不同的算法，使系统更加灵活、可扩展和易于维护。
策略选择改进
读到这里，大家可以发现，其实还是没有办法解决我们代码里面出现的大量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("长连接请求类型不存在")
}
}
}更改后的代码整体结构：
总结
代码并不是能跑就可以了，如果可以的话，请尽可能地优化自己的代码，让自己的代码利于维护和扩展，可读性高。