Golang常见设计模式如何组合使用_多模式协作设计思路-Golang-PHP中文网

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

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

什么时候该把 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(WithLogging(h))))
}