当前位置：首页 > news >正文

装饰模式（Decorator Pattern）在 Go 语言中的应用

news 2025/8/21 10:49:17

文章目录

- 引言
- 什么是装饰模式？
- 在Go语言中的应用
- - 定义接口
  - 实现具体逻辑
  - 创建装饰器
  - 使用装饰器
- 装饰模式 vs 中间件
- - 装饰模式
  - 中间件
  - 区别
- 总结

引言

在软件开发中，设计模式是解决常见问题的模板。装饰模式（Decorator Pattern）是一种结构型设计模式，它允许你在运行时动态地给对象添加职责。本文将详细介绍装饰模式在 Go 语言中的应用，并通过一个具体的例子来展示其使用方法。此外，我们还将探讨装饰模式与中间件的区别，帮助你更好地理解这两种模式的应用场景。

什么是装饰模式？

装饰模式的核心思想是通过创建一个包装类（装饰器）来动态地给对象添加新的功能。这种方式比继承更灵活，因为它不会改变原始类的结构，同时还能在运行时动态地添加或移除功能。

在Go语言中的应用

假设我们有一个权限校验接口 RightsChecker，它负责检查用户的权限。我们希望在权限校验的过程中添加一些额外的行为，比如日志记录、权限检查等。下面是一个具体的实现示例：

定义接口

首先，定义 RightsChecker 接口：

type CheckRightsRequest struct {Authorization string `header:"authorization" validate:"required"`User          string `form:"user"`OpenKfID      string `json:"open_kf_id" validate:"required"`ChildrenId    int64  `json:"children_id,optional"` // 档案id
}type CheckRightsResponse struct {RemainTimes int64 `json:"remain_times"`Enabled     int64 `json:"enabled"`
}type RightsChecker interface {CheckRights(req *CheckRightsRequest) (resp *CheckRightsResponse, err error)
}

实现具体逻辑

接下来，实现具体的权限校验逻辑 CheckRightsLogic：

type CheckRightsLogic struct {ctx    context.ContextsvcCtx context.Context
}func (l *CheckRightsLogic) CheckRights(req *CheckRightsRequest) (resp *CheckRightsResponse, err error) {// 原始的权限校验逻辑riskService := risk.NewRisk()enable, times, err := riskService.Check()if err != nil {return nil, err}resp = &CheckRightsResponse{RemainTimes: times,Enabled:     enable,}return resp, nil
}

创建装饰器

然后，创建一个装饰器 RightsCheckerDecorator，在其中添加额外的行为：

type RightsCheckerDecorator struct {checker RightsChecker
}func (d *RightsCheckerDecorator) CheckRights(req *CheckRightsRequest) (resp *CheckRightsResponse, err error) {// 在这里可以添加额外的行为，例如日志记录、权限检查等fmt.Println("Logging request:", req)// 调用嵌入的 checker 的 CheckRights 方法resp, err = d.checker.CheckRights(req)if err != nil {fmt.Println("Error occurred during rights check:", err)return}// 在这里可以添加额外的行为，例如日志记录、结果处理等fmt.Println("Logging response:", resp)return
}

使用装饰器

最后，创建装饰器并使用它：

func NewRightsCheckerDecorator(checker RightsChecker) RightsChecker {return &RightsCheckerDecorator{checker: checker,}
}func main() {logic := &CheckRightsLogic{ctx: context.Background(), svcCtx: context.Background()}decoratedChecker := NewRightsCheckerDecorator(logic)// 使用装饰后的 checker 进行权限校验req := &CheckRightsRequest{Authorization: "Bearer token123",User:          "user456",OpenKfID:      "kf123",ChildrenId:    12345,}resp, err := decoratedChecker.CheckRights(req)if err != nil {// 处理错误fmt.Println(err)}// 处理响应fmt.Println(resp)
}

装饰模式 vs 中间件

装饰模式

定义：装饰模式通过创建一个包装类（装饰器）来动态地给对象添加新的功能。
应用场景：适用于需要在运行时动态地给对象添加职责的情况，特别是在不改变原有对象结构的前提下。
特点：
- 灵活性高，可以在运行时动态地添加或移除功能。
- 不改变原有对象的结构。
- 适合复杂的业务逻辑，可以逐步添加功能。

中间件

定义：中间件是一种位于请求处理链中的组件，通常用于处理请求和响应的通用任务，如日志记录、认证、错误处理等。
应用场景：适用于 Web 框架、API 服务器等需要处理大量请求的场景。
特点：
- 通常用于处理请求和响应的通用任务。
- 可以在请求处理链中按顺序执行多个中间件。
- 适合处理跨切面的通用逻辑，如日志记录、认证等。

区别

目的：
- 装饰模式主要用于给对象动态地添加职责，而不改变原有对象的结构。
- 中间件主要用于处理请求和响应的通用任务，通常用于 Web 框架和 API 服务器。
使用场景：
- 装饰模式适用于需要在运行时动态地给对象添加功能的场景。
- 中间件适用于需要处理大量请求的场景，特别是在 Web 开发中。
实现方式：
- 装饰模式通过创建包装类来实现。
- 中间件通过在请求处理链中按顺序执行多个中间件来实现。