我是一只可爱的土拨鼠,专注于分享 Go 职场、招聘和求职,解 Gopher 之忧!欢迎关注我。欢迎大家加入[Go招聘交流群] ,来这里找志同道合的小伙伴!跟土拨鼠们一起交流学习。
今天土拨鼠带大家来一段代码的变换之旅,代码篇幅较多,主要参考自one-way-to-do-it-six-variations
,土拨鼠在这里加了一些自己的理解。
文章: https://phlatphrog.medium.com/one-way-to-do-it-six-variations-cd58602ac06d
代码仓库: https://github.com/pdk/oneway
我们先来模拟一段开车去商场购物的代码。主要经历三个阶段:开车去商店、到商店购物、然后购物完成开车回家。每个过程都需要去check
其中返回的err
错误并返回shopper
对象。
// 开车去商店
shopper, err := shopper.Drive(FuelNeededToGetToStore)
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
// 买鸡蛋
shopper, err = shopper.BuyEggs(EggsRequired)
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
// 买完鸡蛋开车回家
shopper, err = shopper.Drive(FuelNeededToGetHome)
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
针对这段代码,错误处理代码较多,可以将三个重复代码块抽离成一个代码块。代码如下:
func main(){
shopper, err := shopper.Drive(FuelNeededToGetToStore)
FatalIfErrNotNil(err)
shopper, err = shopper.BuyEggs(EggsRequired)
FatalIfErrNotNil(err)
shopper, err = shopper.Drive(FuelNeededToGetHome)
FatalIfErrNotNil(err)
}
func FatalIfErrNotNil(err error) {
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
}
不过在生产项目中,正常业务我们一般不会使用fatal
去对非nil
的err
处理,fatal
会以非0状态退出程序。而是使用https://github.com/pkg/errors对err
进行wrap
和cause
或者使用定义的业务相关的err
并返回上一层做处理。这里也可以尝试使用bool
判断来对err
处理(不过之前土拨鼠之前群里也提出这样的想法,大家都说多此一举,尴尬)。
func main(){
shopper, err := shopper.Drive(FuelNeededToGetToStore)
if ErrorHandled(err) {
return ...
}
}
func ErrorHandled(err) bool {
if nil != err {
return true
}
// 也可以对error进行其他判断操作
...
return false
}
是不是觉得上面的err
处理还是不够优雅,所以咱们这里考虑把err
的处理移出到主线之外。每个方法里都包含了对err
的非nil判断和返回。每个操作也只有在err
为nil
的情况下正常执行 。只有在三个操作都结束后才真正对err
进行处理。
func main(){
shopper, err := shopper.Drive(FuelNeededToGetToStore, nil)
shopper, err = shopper.BuyEggs(EggsRequired, err)
shopper, err = shopper.Drive(FuelNeededToGetHome, err)
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
}
func (s Shopper) Drive(fuelRequired int, err error) (Shopper, error) {
if nil != err {
return s, err
}
// 业务逻辑处理
...
}
下面这个变换,抛弃了之前Shopper
作为receiver
的做法,而是将Shopper
作为函数的参数。其实跟变换2很相似。这儿是单独抽离出一个公共的函数ErrCheckFunc
进行err
处理和函数执行。
func main(){
drive := ErrCheckFunc(Drive)
buy := ErrCheckFunc(BuyEggs)
err, shopper := drive(nil, shopper, FuelNeededToGetToStore)
err, shopper = buy(err, shopper, EggsRequired)
err, shopper = drive(err, shopper, FuelNeededToGetHome)
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
}
func Drive(s Shopper, fuelRequired int) (Shopper, error) {
if nil != err {
return s, err
}
...
}
func ErrCheckFunc(f func(Shopper, int) (Shopper, error)) func(error, Shopper, int) (error, Shopper) {
return func(err error, s Shopper, arg int) (error, Shopper) {
if nil != err {
return err, s
}
s, err = f(s, arg)
return err, s
}
}
这次改进是采用了装饰器模式的思想把err
的check
逻辑和函数的执行操作都封装在了ErrCheckFunc
一个方法中。相比变换3,是将ErrCheckFunc
中的返回值中的函数入参arg
转移到了ErrCheckFunc
入参中的arg
参数。
func main(){
driveToStore := ErrCheckFunc(Drive, FuelNeededToGetToStore)
buyEggs := ErrCheckFunc(BuyEggs, EggsRequired)
driveHome := ErrCheckFunc(Drive, FuelNeededToGetHome)
err, shopper := driveHome(buyEggs(driveToStore(nil, shopper)))
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
}
func ErrCheckFunc(f func(Shopper, int) (Shopper, error), arg int) func(error, Shopper) (error, Shopper) {
return func(err error, s Shopper) (error, Shopper) {
if nil != err {
return err, s
}
s, err = f(s, arg)
return err, s
}
}
终极变换来了,这次变换采用了迭代的思想。ProcessSteps
这里使用的是一个可变的函数参数。
func main(){
driveToStore := Flavorize(Drive, FuelNeededToGetToStore)
buyEggs := Flavorize(BuyEggs, EggsRequired)
driveHome := Flavorize(Drive, FuelNeededToGetHome)
shopper, err := ProcessSteps(shopper,
driveToStore,
buyEggs,
driveHome,
)
if nil != err {
log.Fatalf("could not complete shopping: %s", err)
}
}
func ProcessSteps(s Shopper, steps ...func(Shopper) (Shopper, error)) (Shopper, error) {
for _, step := range steps {
var err error
s, err = step(s)
if nil != err {
return s, err
}
}
return s, nil
}
func Flavorize(f func(Shopper, int) (Shopper, error), arg int) func(Shopper) (Shopper, error) {
return func(s Shopper) (Shopper, error) {
return f(s, arg)
}
}
土拨鼠今天拿这个例子来展示给大家,主要是因为在项目中也会经常遇到这样的代码逻辑场景,就想着看看别人是怎么去重构改进的,学习怎么去优化重构,使代码变得更好维护、易于扩展、复用性高、可读性高。希望大家也可以借鉴学习,如果你有更好的变换和想法欢迎大家留言讨论。
Copyright© 2013-2020
All Rights Reserved 京ICP备2023019179号-8