如何优雅地将字节切片解码为不同的结构

问题描述

var response Response
switch wrapper.Domain {
case "":
    response = new(TypeA)
case "TypeB":
    response = new(TypeB)
case "TypeC":
    response = new(TypeC)
case "TypeD":
    response = new(TypeD)
}
_ = decoder.Decode(response)

代码片段所示,我从 Domainwrapper 字段中获得了足够的信息来确定响应的类型,并对每种类型执行以下操作:

  1. 使用 new 创建一个该类型的新实例
  2. 使用解码器将字节切片解码为步骤1中创建的实例 我想知道是否有办法使第一步更通用并摆脱 switch 语句。

解决方法

关于你的代码的一点

根据评论中的讨论,我想分享一些经验。

我看不出您的解决方案有什么不好,但改进它的选项很少,这取决于您想要做什么。

您的代码看起来像经典的 Factory。 Factory 是一种模式,它根据一些输入参数创建单个系列的对象。

在 Golang 中,这通常以更简单的方式用作 Factory Method,有时也称为 Factory function

示例:

type Vehicle interface {};
type Car struct {}

func NewCar() Vehicle {
   return &Car{}
}

但您可以轻松扩展它以执行类似您的操作:

package main

import (
    "fmt"
    "strings"
)

type Vehicle interface {}
type Car struct {}
type Bike struct {}
type Motorbike struct {}

// NewDrivingLicenseCar returns a car for a user,to perform 
// the driving license exam.
func NewDrivingLicenseCar(drivingLicense string) (Vehicle,error) {
    switch strings.ToLower(drivingLicense) {
    case "car":
        return &Car{},nil
    case "motorbike":
        return &Motorbike{},nil
    case "bike":
        return &Bike{},nil
    default:
        return nil,fmt.Errorf("Sorry,We are not allowed to make exam for your type of car: \"%s\"",drivingLicense)
    }
}

func main() {
    fmt.Println(NewDrivingLicenseCar("Car"))
    fmt.Println(NewDrivingLicenseCar("Tank"))
}

以上代码产生输出:

&{} <nil>
<nil> Sorry,We are not allowed to make exam for your type of car: "Tank"

因此,您可能可以通过以下方式改进代码:

  • 关闭为单个函数,该函数接受 string 并生成 Response object
  • 添加一些验证和错误处理
  • 给它取个合理的名字。

与Factory相关的模式很少,可以替代这个模式:

  • 责任链
  • 调度员
  • 访客
  • 依赖注入

反思?

@icza 也有关于 Reflection 的评论。我同意他的看法,这是常用的,我们无法避免代码中的反射,因为有时事情是如此动态。

但在您的情况下,这是一个糟糕的解决方案,因为:

  • 你失去了编译时类型检查
  • 添加新类型时必须修改代码,那么为什么不在这个工厂函数中添加新行呢?
  • 你让你的代码变慢(参见参考资料),它会增加 50%-100% 的性能损失。
  • 你让你的代码变得如此难以理解和复杂
  • 您必须添加更多错误处理,以涵盖反射引起的非微不足道的错误。

当然,您可以添加大量测试来覆盖大量场景。你可以在你的代码中支持 TypeA,TypeB,TypeC 并且你可以用测试来覆盖它,但是在生产代码中你有时可以通过 TypeXYZ 并且你会得到运行时错误如果你没有抓住它。


结论

您的 switch/case 方案没有什么不好,这可能是最易读、最简单的方式来做您想做的事情。

参考