从链式调用谈构造器模式与柯里化

前段时间，使用构造器模式重构了http 工具类库，顺带优化一下AuditLog 模块的代码，然后很意外地被领导发现，他跟我说：这就是链式调用。这句话勾起我多年前的回忆

type LogLevel = string 
const (
    Debug LogLevel = "Debug" 
    Info LogLevel = "Info" 
    Warn LogLevel = "Warn" 
    Error LogLevel = "Error"
)

struct AuditLog {
    User string
    Operation string
    Level LogLevel
    Result string
    Timestamp time.Date
}

// 重构前 
sendAuditLog({
    User: "admin",
    Operation: "delete user",
    Result: "failed",
    Level: "Error",
    Timestamp: "2022-10-13"
})

// 重构后 
Builder().User("admin").Operation("delete user").Error("Failed")

早在十多年前，也就是2012年左右的光景，那时候前端还是jQuery的天下，大家非常熟悉的React、Angular和Vue三剑客还没兴起。我作为一个刚入学的大学生接触前端的第一个框架就是jQuery，那时候IE浏览器的份额还很高，jQuery抹平IE、Chrome和FireFox之间的差异，而且它特有的链式调用 更是操作DOM的一把利器。

$("selector").html("abcd")

但随着技术的演进，尤其是V8引擎的强大性能改进，使得Javascript从一个玩具语言逐渐成为最受欢迎的编程语言，像React、Angular和Vue这样的MVVM类库框架逐渐兴起，jQuery逐渐退出舞台。

const eventNumbers = \[1,2,3,4,5,6\].filter(num => num % 2 == 0)
    .map(item => \`${item} is event number\`)

虽然像Array、Map这样的数据结构还支持map、filter等链式操作，但很少人再提起链式调用，反而是隔壁Java用一个全新的词汇 Stream API，但Java的实现是通过Stream的抽象接口，局限于实现Collection接口的数据结构。

直到后来专门去学习函数式编程，接触柯里化 等概念。可惜Go 对函数式编程的支持非常一般，连最基本的箭头函数都不支持，所以不打算像Rust那样使用宏实现自动柯里化，退而求其次，选择中规中矩的OOP 常见的构造器模式，笨是笨点，但至少容易理解和维护。

type LogLevel = string
const (
    Debug LogLevel = "Debug"
    Info LogLevel = "Info"
    Warn LogLevel = "Warn"
    Error LogLevel = "Error"
)

struct AuditLog {
    User string
    Operation string
    Result string
    Level LogLevel
    Timestamp Date
}

func (log *AuditLog) User(user string) OperationInterface {
    log.User = user
    return log
}

func (log *AuditLog) Operation(op string) LevelInterface {
    log.Operation = op
    return log
}

func (log *AuditLog) Debug(result string) *AuditLog {
    log.Level = Debug
    log.Result = result
    return log
}

func (log *AuditLog) Info(result string) *AuditLog {
    log.Level = Info
    log.Result = result
    return log
}

func (log *AuditLog) Warn(result string) *AuditLog {
    log.Level = Warn
    log.Result = result
    return log
}

func (log *AuditLog) Error(result string) *AuditLog {
    log.Level = Error
    log.Result = result
    return log
}

// 构造函数
func NewAuditLog() *AuditLog {
    return &AuditLog{
        User: "",
        Operation: "",
        Result: "",
        Level: Error,
        Timestamp: time.Now()
    }
}

// 构造器模式 
func Builder() UserInterface {
    return NewAuditLog()
}

// 针对User字段封装的setter函数 
interface UserInterface {
    User(string) OperationInterface
}

// 针对Operation字段封装的setter函数
interface OperationInterface {
    Operation(string)
}

// 针对Level字段封装的setter函数，对枚举进行特殊处理 
interface LevelInterface {
    Debug(string) *AuditLog
    Info(string) *AuditLog
    Warn(string) *AuditLog
    Error(string) *AuditLog
}

重构后的代码看起来更简洁且条理清晰，最重要的是看起来像符合自然语言的阅读习惯，这被称之为代码的 语义化

// 重构后 
Builder().User("admin").Operation("delete user").Error("Failed")

以上的重构过程需要遵守哪些规则或者诀窍，我列出来以下5点供大家参考：

每个字段都抽取出一个 interface ，interface 包裹着 setter 方法
通过控制 interface 内部的 setter 方法返回值类型来控制方法的调用顺序，比如 UserInterface 的返回值是 OperationInterface
对于类型是枚举的字段，比如说 Level 字段的类型就是只有 Debug、Info等有限个数的，可以分别创建别名方法，比如 Debug()、Info()
每个枚举类型的 setter 方法都可以额外设置一个非枚举的字段，比如说 Debug(string) 能够同时设置 Level 和 Result 两个字段的值。
最后一个字段的 setter 方法要返回完整的结构体，或者被特定interface包裹起来的结构体，目的是隐藏实现细节。

以上过程非常公式化，完全可以通过代码自动生成，然后再后期人为调整一下顺序，使得方法调用顺序更适合阅读习惯。

我认为比较值得讨论的点，就是使用 interface 代替原来的 枚举，让代码看起来更简洁易懂且语义化。

围绕着 使用 interface 代替 枚举 的话题，我想进一步探讨 Go 语言中如何实现复杂类型枚举

由于Go语言的限制，Go语言中的枚举都是通过数字、字符串等基本类型来模拟的，不存在真正意义上的枚举。

要实现复杂结构的枚举，往往需要借助全局变量，但是全局变量并不是只读，在运行过程中容易被篡改，存在数据竞争的风险。

struct ResponseEnum {
    Code int
    MsgEn string
    MsgCn string
    Extra Extra
}

struct Extra {
    StatusCode string
    Message string
}

var Succeed = ResponseEnum {
    Code: 200,
    MsgEn: "request succeed",
    MsgCn: "请求成功"
}
var BadRequest = ResponseEnum {
    Code: 400,
    MsgEn: "invalid request",
    MsgCn: "请求参数有误"
}
var Unauthorized = ResponseEnum {
    Code: 401,
    MsgEn: "needs login",
    MsgCn: "需要登陆"
}
var NotFound = ResponseEnum {
    Code: 404,
    MsgEn: "the requested resource is not existed",
    MsgCn: "资源不存在"
}

使用 interface 替换 枚举 重构：

interface Response {
    Code() int
    MsgEn() string
    MsgCn() string
    Extra() *Extra
}

struct httpResponse {
    Code int `json: "code"`
    MsgEn string `json: "msgEn"`
    MsgCn string `json: "msgCn"`
    Extra Extra `json: "extra"`
}

func (resp *httpResponse) Code() int {
    return resp.Code
}

func (resp *httpResponse) MsgEn() string {
    return resp.MsgEn
}

func (resp *httpResponse) MsgCn() string {
    return resp.MsgCn
}

func (resp *httpResponse) Extra() Extra {
    return resp.Extra
}

func Succeed(extra Extra) Response {
    return &httpResponse {
        Code: 200,
        MsgEn: "request succeed",
        MsgCn: "请求成功", 
        Extra: extra
    }
}

func BadRequest(extra Extra) Response {
    return &httpResponse {
        Code: 400,
        MsgEn: "invalid request",
        MsgCn: "请求参数有误" 
        Extra: extra
    }
}

func Unauthorized(extra Extra) Response {
    return &httpResponse {
        Code: 401,
        MsgEn: "needs login",
        MsgCn: "需要登陆" 
        Extra: extra
    }
}

func NotFound(extra Extra) Response {
    return &httpResponse {
        Code: 401,
        MsgEn: "the requested resource is not existed",
        MsgCn: "资源不存在" 
        Extra: extra
    }
}

重构完后，原本的全局变量都变成公开函数，每次调用函数都会返回一个全新结构体示例，自然就不会存在数据竞争的场景。

而且返回的结果类型都是 interface ，只提供读取操作屏蔽修改操作，消除运行中篡改数据的可能，提高代码的健壮性。

并且可以通过创建 函数别名 的方式自定义枚举：


// DuplicatedName 所有场景都通用的自定义重名资源错误枚举
func DuplicatedName() Response {
    return BadRequest(Extra{StatusCode: "CustomizedCode001", Message: "资源名称已存在"})
}

// ImageError 跟镜像相关的错误枚举
func ImageError(code string, msg string) Response {
    // 状态码统一加上IMG前缀
    return BadRequest(Extra{StatusCode: "IMG" + code, Message: msg})
}

总结

链式调用 Chain Call 更像是一种俗称，它常见的实现方式有两种：CPS(Continuation Passing Style) 和 State Machine两种，前者是函数式的柯里化 Currying ，一般都是延迟求值 lazy evaluation，具体做法是把中间状态保存到函数栈帧中，默认是线程安全的；后者是面向对象的状态机 State Machine ，也可以做到延迟求值，具体做法是把中间状态保存到结构体中，但因为函数栈帧的大小有限，最终都会逃逸到堆上，因此性能不是最佳，默认也不是线程安全的，优点是易于理解。

zaoying blog

总结