2024年安卓最全如何使用高阶函数编程提升代码的简洁性，美团社招三面

本文链接：https://blog.csdn.net/2301_82241983/article/details/138908857

总结

**其实上面说了这么多，钱是永远赚不完的，在这个知识付费的时代，知识技能提升才是是根本！我作为一名8年的高级工程师，知识技能已经学习的差不多。**在看这篇文章的可能有刚刚入门，刚刚开始工作，或者大佬级人物。

像刚刚开始学Android开发小白想要快速提升自己，最快捷的方式，就是有人可以带着你一起分析，这样学习起来最为高效，所以这里分享一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

这么重要的事情说三遍啦！点赞+点赞+点赞！

【Android高级架构师系统学习资料】高级架构师进阶必备——设计思想解读开源框架

第一章、热修复设计
第二章、插件化框架设计
第三章、组件化框架设计
第四章、图片加载框架
第五章、网络访问框架设计
第六章、RXJava 响应式编程框架设计
第七章、IOC 架构设计
第八章、Android 架构组件 Jetpack

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

解决这种问题，一种比较常见的方案是，新建一个结构体，把各种查询的字段都放在这个结构体中，然后把这个结构体作为入参传入到 dao 层的查询方法中。而在调用 dao 方法的地方，根据各自的需要，构建包含不同字段的结构体。在这个例子中，我们可以构建一个 UserInfo 的结构体如下：

type UserInfo struct {

UserID int64

Name string

Role int32

Status int32

}

把 UserInfo 作为入参传给 GetUserInfo 方法，于是 GetUserInfo 方法变成了这样：

func GetUserInfo(ctx context.Context, info *UserInfo) ([]*resource.UserInfo) {

db := GetDB(ctx)

db = db.Table(resource.UserInfo{}.TableName())

var infos []*resource.UserInfo

if info.UserID > 0 {

db = db.Where(“user_id = ?”, info.UserID)

}

if info.Name != “” {

db = db.Where(“user_name = ?”, info.Name)

}

if info.Role > 0 {

db = db.Where(“role = ?”, info.Role)

}

if info.Status > 0 {

db = db.Where(“status = ?”, info.Status)

}

db.Find(&infos)

return infos

}

相应地，调用该方法的代码也需要变动：

//只根据userD查询

info := &UserInfo{

UserID: userID,

}

infos := GetUserInfo(ctx, info)

//只根据name查询

info := &UserInfo{

Name: name,

}

infos := GetUserInfo(ctx, info)

这个代码写到这里，相比最开始的方法其实已经好了不少，至少 dao 层的方法从很多个入参变成了一个，调用方的代码也可以根据自己的需要构建参数，不需要很多空占位符。但是存在的问题也比较明显：仍然有很多判空不说，还引入了一个多余的结构体。如果我们就到此结束的话，多少有点遗憾。

另外，如果我们再扩展一下业务场景，我们使用的不是等值查询，而是多值查询或者区间查询，比如查询 status in (a, b)，那上面的代码又怎么扩展呢？是不是又要引入一个方法，方法繁琐暂且不说，方法名叫啥都会让我们纠结很久；或许可以尝试把每个参数都从单值扩展成数组，然后赋值的地方从 = 改为 in()的方式，所有参数查询都使用 in 显然对性能不是那么友好。

黄金

接下来我们看看黄金的解法。在上面的方法中，我们引入了一个多余的结构体，并且无法避免在 dao 层的方法中做了很多判空赋值。那么我们能不能不引入 UserInfo 这个多余的结构体，并且也避免这些丑陋的判空？答案是可以的，函数式编程可以很好地解决这个问题，首先我们需要定义一个函数类型：

type Option func(*gorm.DB)

定义 Option 是一个函数，这个函数的入参类型是*gorm.DB，返回值为空。

然后针对 DB 表中每个需要筛选查询的字段定义一个函数，为这个字段赋值，像下面这样：

func UserID(userID int64) Option {

return func(db *gorm.DB) {

db.Where(“user_id = ?”, userID)

}

func UserName(name string) Option {

return func(db *gorm.DB) {

db.Where(“user_name = ?”, name)

}

func Role(role int32) Option {

return func(db *gorm.DB) {

db.Where(“role = ?”, role)

}

func Status(status int32) Option {

return func(db *gorm.DB) {

db.Where(“status = ?”, status)

}

上面这组代码中，入参是一个字段的筛选值，返回的是一个 Option 函数，而这个函数的功能是把入参赋值给当前的【db *gorm.DB】对象。这也就是我们在文章一开始就提到的高阶函数，跟我们普通的函数不太一样，普通的函数返回的是一个简单类型的值或者一个封装类型的结构体，而这种高阶函数返回的是一个具备某种功能的函数。这里多说一句，虽然 go 语言很好地支持了函数式编程，但是由于其目前缺少对泛型的支持，导致高阶函数编程的使用并没有给开发者带来更多的便利，因此在平时业务代码中写高阶函数还是略为少见。而熟悉 JAVA 的同学都知道，JAVA 中的 Map、Reduce、Filter 等高阶函数使用起来非常的舒服。

好，有了这一组函数之后，我们来看看 dao 层的查询方法怎么写：

func GetUserInfo(ctx context.Context, options …func(option *gorm.DB)) ([]*resource.UserInfo) {

db := GetDB(ctx)

db = db.Table(resource.UserInfo{}.TableName())

for _, option := range options {

option(db)

}

var infos []*resource.UserInfo

db.Find(&infos)

return infos

}

没有对比就没有伤害，通过和最开始的方法比较，可以看到方法的入参由多个不同类型的参数变成了一组相同类型的函数，因此在处理这些参数的时候，也无需一个一个的判空，而是直接使用一个 for 循环就搞定，相比之前已经简洁了很多。

那么调用该方法的代码怎么写呢，这里直接给出来：

//只使用userID查询

infos := GetUserInfo(ctx, UserID(userID))

//只使用userName查询

infos := GetUserInfo(ctx, UserName(name))

//使用role和status同时查询

infos := GetUserInfo(ctx, Role(role), Status(status))

无论是使用任意的单个参数还是使用多个参数组合查询，我们都随便写，不用关注参数顺序，简洁又清晰，可读性也是非常好。

再来考虑上面提到的扩展场景，如果我们需要多值查询，比如查询多个 status，那么我们只需要在 Option 中增加一个小小的函数即可：

func StatusIn(status []int32) Option {

return func(db *gorm.DB) {

db.Where(“status in ?”, status)

}

对于其他字段或者等值查询也是同理，代码的简洁不言而喻。

王者

能优化到上面黄金的阶段，其实已经很简洁了，如果止步于此的话，也是完全可以的。但是如果还想进一步追求极致，那么请继续往下看！

在上面方法中，我们通过高阶函数已经很好地解决了对于一张表中多字段组合查询的代码繁琐问题，但是对于不同的表查询，仍然要针对每个表都写一个查询方法，那么还有没有进一步优化的空间呢？我们发现，在 Option 中定义的这一组高阶函数，压根与某张表没关系，他只是简单地给 gorm.DB 赋值。因此，如果我们有多张表，每个表里都有 user_id、is_deleted、create_time、update_time 这些公共的字段，那么我们完全不用再重复定义一次，只需要在 Option 中定义一个就够了，每张表的查询都可以复用这些函数。进一步思考，我们发现，Option 中维护的是一些傻瓜式的代码，根本不需要我们每次手动去写，可以使用脚本生成，扫描一遍 DB 的表，为每个不重复的字段生成一个 Equal 方法、In 方法、Greater 方法、Less 方法，就可以解决所有表中按照不同字段做等值查询、多值查询、区间查询。

解决了 Option 的问题之后，对于每个表的各种组合查询，就只需要写一个很简单的 Get 方法了，为了方便看，我们在这里再贴一次：

func GetUserInfo(ctx context.Context, options …func(option *gorm.DB)) ([]*resource.UserInfo) {

db := GetDB(ctx)

db = db.Table(resource.UserInfo{}.TableName())

for _, option := range options {

option(db)

}

var infos []*resource.UserInfo

db.Find(&infos)

return infos

}

上面这个查询方法是针对 user_info 这个表写的，如果还有其他表，我们还需要为每个表都写一个和这个类似的 Get 方法。如果我们仔细观察每个表的 Get 方法，会发现这些方法其实就有两点不同：

返回值类型不一样；
TableName 不一样。

如果我们能解决这两个问题，那我们就能够使用一个方法解决所有表的查询。首先对于第一点返回值不一致的问题，可以参考 json.unmarshal 的做法，把返回类型以一个参数的形式传进来，因为传入的是指针类型，所以就不用再给返回值了；而对于 tableName 不一致的问题，其实可以和上面处理不同参数的方式一样，增加一个 Option 方法来解决：

func TableName(tableName string) Option {

return func(db *gorm.DB) {

db.Table(tableName)

}

这样改造之后，我们的 dao 层查询方法就变成了这样：

func GetRecord(ctx context.Context, in interface{}, options …func(option *gorm.DB)) {

db := GetDB(ctx)

for _, option := range options {

option(db)

}

db.Find(in)

return