1 回答
TA贡献1875条经验 获得超3个赞
关于您的代码的一些内容
根据评论中的讨论,我想分享一些经验。
我没有看到你的解决方案有什么不好的,但是改进它的选项很少,这取决于你想做什么。
你的代码看起来像经典的工厂。这是一种模式,它基于一些输入参数创建单个族的对象。Factory
在Golang中,这通常以更简单的方式用作,有时称为。Factory MethodFactory 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"
因此,也许您可以通过以下方式改进代码:
关闭到单个函数中,该函数采用 a 并生成
string
Response object
添加一些验证和错误处理
给它一些合理的名字。
与工厂相关的模式很少,可以替换此模式:
责任链
调度
游客
依赖注入
反射?
@icza也有关于反射的评论。我同意他的观点,这是常用的,我们无法避免代码中的反射,因为有时事情是如此动态。
但在你的场景中,这是一个糟糕的解决方案,因为:
您丢失了编译时类型检查
添加新类型时必须修改代码,那么为什么不在此 Factory 函数中添加新行呢?
你使代码变慢(参见参考),它增加了50%-100%的性能损失。
你让你的代码如此不可读和复杂
您必须添加更多的错误处理,以涵盖反射带来的不小错误。
当然,您可以添加大量测试来涵盖大量场景。您可以在代码中支持 、,并且可以使用测试来覆盖它,但是在生产代码中,有时您可以通过,如果不捕获它,您将收到运行时错误。TypeA
TypeB
TypeC
TypeXYZ
结论
你的方案没有什么不好的,这可能是做你想做的事情的最容易读和最简单的方法。switch/case
参考
工厂方法:https://www.sohamkamani.com/golang/2018-06-20-golang-factory-patterns/
关于编程模式的经典书籍:设计模式:可重用面向对象软件的元素,ISBN:978-0201633610
Erich Gamma and his band of four
反射基准:https://gist.github.com/crast/61779d00db7bfaa894c70d7693cee505
- 1 回答
- 0 关注
- 97 浏览
添加回答
举报