Golang常见设计模式如何组合使用_多模式协作设计思路

Factory 和 Strategy 应在需动态创建算法实例且算法内部依赖可替换行为时组合使用,如支付模块根据 payType 创建不同策略并注入签名器等依赖。

什么时候该把 Factory 和 Strategy 一起用

当你的业务逻辑需要根据运行时参数动态创建不同算法实现,且这些算法本身又需要封装可替换的行为时,Factory + Strategy 是最自然的组合。比如支付模块:用户选择微信支付或支付宝,系统要创建对应的支付策略实例,而每个策略内部还可能依赖不同的签名生成器、回调处理器。

  • Factory 负责根据 payType 字符串返回具体的 PaymentStrategy 实现
  • Strategy 接口定义 Pay()Refund(),但不关心如何序列化请求或验签
  • 真正解耦的关键在于:Factory 创建 Strategy 时,可以传入其他依赖(比如一个 Signer),而这个 Signer 本身也可以是另一个 Strategy 或由 Builder 构建
type PaymentStrategy interface {
    Pay(order *Order) error
}

type WechatPayStrategy struct {
    signer Signer // 可替换的签名策略
}

func NewWechatPayStrategy(signer Signer) *WechatPayStrategy {
    return &WechatPayStrategy{signer: signer}
}

func PaymentStrategyFactory(payType string) PaymentStrategy {
    switch payType {
    case "wechat":
        return NewWechatPayStrategy(&WechatSHA256Signer{})
    case "alipay":
        return NewAlipayStrategy(&AlipayRSA2Signer{})
    default:
        panic("unknown pay type")
    }
}

为什么 Observer 不该直接嵌套在 Singleton 里

常见错误是把事件监听器注册逻辑塞进单例的 GetInstance() 方法里,导致每次获取实例都重复绑定、内存泄漏、测试困难。Singleton 只应负责“唯一实例”的生命周期;Observer 关系必须可手动管理。

  • 单例对象(如 Logger)暴露 Subscribe()Unsubscribe() 方法,而不是自动绑定
  • 订阅者应在初始化阶段显式调用,比如在 main() 或模块 init() 中完成
  • 若用 sync.Once 初始化单例,切勿在其中调用任何可能阻塞或依赖外部状态的 Observer 注册逻辑
var loggerInstance *Logger
var loggerOnce sync.Once

func GetLogger() *Logger {
    loggerOnce.Do(func() {
        loggerInstance = &Logger{
            subscribers: make(map[int]func(string)),
        }
    })
    return loggerInstance
}

// 正确:由使用者决定何时订阅
func main() {
    log := GetLogger()
    log.Subscribe(1, func(msg string) { fmt.Println("[DEBUG]", msg) })
}

Decorator + Interface 嵌套容易踩的坑

Go 没有继承,靠接口组合实现 Decorator,但过度嵌套会导致方法爆炸和 nil panic。典型场景是给 HTTP handler 加日志、熔断、指标上报——每层 Decorator 都要完整实现 http.Handler 接口,哪怕只改一个方法。

  • 避免让 Decorator 实现整个接口;优先用函数包装器(func(http.Handler) http.Handler)而非结构体
  • 如果必须用结构体 Decorator,确保其字段(如 next http.Handler)在构造时非 nil,并在 ServeHTTP 开头加 if d.next == nil { panic(...) }
  • 多个 Decorator 组合时,顺序敏感:日志 Decorator 包裹熔断 Decorator,和反过来,行为完全不同
func WithMetrics(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 记录指标
        next.ServeHTTP(w, r) // 注意:这里假设 next 不为 nil
    })
}

func main() {
    h := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("ok"))
    })
    // 正确顺序:指标 → 熔断 → 日志 → 原始 handler
    http.ListenAndServe(":8080", WithMetrics(WithCircuitBreaker(With

Logging(h)))) }

Builder 在组合模式中不是万能的

Builder 适合构建复杂对象,但一旦和其他模式混用,容易变成“配置黑洞”。比如用 Builder 构建一个带多种 Strategy 的 Service 实例,最后却把所有策略类型、超时、重试次数全塞进 Builder 的链式调用里,导致可读性崩坏。

立即学习“go语言免费学习笔记(深入)”;

  • Builder 应只负责“组装”,不负责“决策”;策略选择逻辑(如根据环境变量选重试策略)应放在 Builder 外部
  • Builder 的 Build() 方法不应做 I/O 或阻塞操作(比如读配置文件、连数据库),否则单元测试无法 mock
  • 如果 Builder 返回的对象本身还要被 Decorator 包裹,那 Builder 最好返回接口而非具体类型,否则 Decorator 得知道底层结构

复杂点往往不在模式本身,而在谁持有控制权——是 Builder 决定用哪个 Strategy,还是上层代码传进去。后者更可控,也更容易测试。