关于您的代码的一些信息
根据cmets中的讨论，我想分享一些经验。
我认为您的解决方案没有什么不好的，但是几乎没有改进它的选项，这取决于您想要做什么。
您的代码看起来像经典的工厂。 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 也有关于反射的评论。我同意他的观点，这是常用的，我们无法避免代码中的反射，因为有时事情是如此动态。
但在您的情况下，这是一个糟糕的解决方案，因为：
- 您失去了编译时类型检查
- 添加新类型时必须修改代码，为什么不在这个Factory函数中添加新行呢？
- 您让您的代码变慢（参见参考资料），它会增加 50%-100% 的性能损失。
- 你让你的代码变得如此难以阅读和复杂
- 您必须添加更多错误处理以涵盖反射中的重要错误。
当然，您可以添加大量测试来覆盖大量场景。您可以在代码中支持TypeA、TypeB、TypeC，并且可以通过测试对其进行覆盖，但在生产代码中，有时您可以通过TypeXYZ，如果不捕获它，您将收到运行时错误。
结论
您的switch/case 场景没有什么不好，可能这是最易读、最简单的方式来做您想做的事情。
参考