17｜设计原则和模式：功能持续迭代，如何减少改动？

徐逸

你好，我是徐逸。
上节课我们学习了如何构建一个规范的目录，不过对于一个快速迭代的项目，即便有了清晰的目录结构，但如果写代码不讲究一定的方法，后续修改和扩展也会非常困难。针对写代码过程中面临的一些场景，业界早就总结归纳出了一些通用解决方案，而这些场景和对应的解决方案，正是我们所熟知的设计原则和设计模式。
今天我就以一个个需求的形式，带你体会在做需求的过程中，代码设计原则和设计模式是如何在 Golang 项目中应用的。
在上节课的案例中，我们的商品 service 有个 GetProduct 方法，用于从 Redis 缓存读商品信息。
// product_service.go
// GetProduct 获取商品信息
func GetProduct(ctx context.Context, productID string) (*model.Product, error) {
    product, err := redis.GetProduct(ctx, productID)
    if err != nil {
        return nil, err
    }
    if product != nil {
        return product, nil
    }
    product, err = mysql.GetProduct(ctx, productID)
    if err != nil {
        return nil, err
    }
    redis.SetProduct(ctx, product)
    return product, nil
}

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结

1. 依赖反转原则是指高层模块不应该直接依赖于低层模块的具体实现，而是应该依赖于接口，以提高代码的可维护性和稳定性。 2. 使用Golang接口和依赖反转原则可以实现mock外部依赖的能力，方便测试service层逻辑的方法。 3. 通过定义接口和结构体，使service层不直接依赖dal层的实现，而是依赖dal层的接口，并通过NewProductService方法注入接口的实现，符合依赖反转原则。 4. 在测试文件中，实现dal层的接口，如MockProductCache和MockProductDB结构体，并通过NewProductService方法注入service层，以实现mock外部依赖返回，方便进行单元测试。 5. 策略模式和简单工厂方法可以帮助解决handler层中重复的if else逻辑，提高代码的简洁性和可维护性。 6. 建造者模式和函数选项模式可以帮助实现对复杂对象的构建与表示分离，提高代码的灵活性和可维护性。 7. 责任链模式允许将请求沿着处理者链进行发送，实现给所有接口加上统一的处理逻辑，提高代码的复用性和可扩展性。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Go 服务开发高手课》，新⼈⾸单¥59

立即购买

登录后留言

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。

收起评论