17370845950

外观模式在Go中是通过struct+interface+显式组合实现的接口封装策略，用于隐藏子系统复杂性，需依赖注入、错误映射、业务语义命名，并避免过度封装。

外观模式在 Go 中不是语言特性，而是接口封装策略

Go 没有 class、继承或“外观模式”标准实现，所谓“外观模式”在 Go 里本质是用 struct + interface + 显式组合来隐藏子系统复杂性。它不靠设计模式标签驱动，而靠开发者主动收敛调用入口。

典型场景：你有一组分散的模块——auth.Service、payment.Client、notification.Sender，外部每次调用都要导入三四个包、初始化多个实例、处理各自错误。这时你就该考虑加一层薄薄的门面。

• 不要把门面做成单例全局变量（比如 var Facade = NewFacade()），这会破坏可测试性和依赖显性化
• 门面结构体应只持有接口字段，而非具体实现类型，例如：auth auth.Service 而非 auth *auth.JWTService
• 门面方法应返回业务语义明确的结果，而不是把底层错误原样透传；需做错误映射，比如把 payment.ErrInsufficientBalance 转为 ErrPaymentFailed

如何定义一个可测试的门面结构体

关键不是“怎么写”，而是“怎么让它的依赖能被替换”。Go 的依赖注入靠构造函数参数传递，不是反射或容器。

type OrderFacade struct {
	auth      auth.Service
	payment   payment.Client
	notify    notification.Sender
}

func NewOrderFacade(
	a auth.Service,
	p payment.Client,
	n notification.Sender,
) *OrderFacade {
	return &OrderFacade{
		auth:    a,
		payment: p,
		notify:  n,
	}
}

这样写之后，单元测试就能传入 mock 实现：

• 用 gomock 或手写 mockAuth 实现 auth.Service 接口
• 避免在 NewOrderFacade 内部 new 出具体类型（如 &auth.JWTService{...}）
• 如果某子系统暂时没抽象出接口，先自己定义一个最小契约接口，比直接依赖具体类型更可持续

门面方法命名要反映业务动作，而非拼接子系统名

别写 facade.AuthAndChargeAndNotify() 这种方法。它暴露了内部流程，且一旦流程变更（比如加风控校验），方法签名或语义就得改。

应该按用户/调用方视角命名：

• facade.PlaceOrder(ctx, req) —— 隐藏鉴权、扣款、发通知等步骤
• facade.RefundOrder(ctx, orde

  

  rID) —— 内部可能调 payment.Refund() + notify.Send()
• 每个方法只做一件事，哪怕背后调了 4 个子系统；职责不清的门面会快速腐化成“上帝对象”

注意：若某个操作存在多种路径（如支付支持余额+微信+支付宝），门面不应在内部 if-else 分支选择实现，而应把策略交给调用方传入，或通过组合不同门面实例来隔离。

什么时候不该加外观？警惕过度封装

外观模式的价值在于降低**高频、跨模块、语义聚合型**调用的认知成本。但它不是银弹。

• 两个模块只在一处耦合（比如仅在 CLI 命令里一起用），直接调用更清晰
• 子系统本身已足够简单（如只有一个函数 cache.Get(key)），再包一层 facade.GetCache(key) 属于噪声
• 团队对模块边界已有共识、文档完善、错误码统一，此时外观可能只是增加间接层
• 性能敏感路径（如高频日志上报），额外 struct 字段访问和接口动态调度有微小开销，需实测确认是否可接受

最常被忽略的一点：门面一旦建立，就承担了向后兼容责任。后续修改接口或行为时，必须考虑所有已使用该门面的调用方——它不再是内部封装，而成了隐性 API 边界。