Go语言外观模式实现，简化子系统调用

本文深入探讨了在 Go 语言中正确实现外观模式（Facade）的关键实践与常见陷阱，强调 Facade 的核心价值在于通过业务语义清晰的单一入口简化复杂子系统调用，而非简单罗列底层能力；它指出结构体是否导出应严格依据依赖情况——有外部依赖时必须通过工厂函数封装初始化，无依赖时也需提供带校验的构造函数并隐藏字段；方法命名须聚焦动宾式业务动作（如 ProcessPayment、PlaceOrder），避免泄露实现细节；所有子系统依赖必须抽象为接口以保障可测试性与可替换性；同时明确划清职责边界——重试、熔断、日志等横切关注点应由装饰器等中间件承担，Facade 仅专注编排逻辑与错误转换，不越界处理分布式事务或一致性问题，真正回归“简化”本质。

Facade 结构体该不该导出？

Go 里实现 Facade，核心是封装多个子系统接口，对外只暴露一个干净的入口。但别一上来就把 Facade 类型大写导出——它是否导出，取决于你是否允许调用方直接初始化它。

常见错误：定义了 type Facade struct{...}，又在包外 new 出来，结果子系统依赖（比如数据库连接、HTTP 客户端）全得由使用者传入，反而更麻烦。

• 如果 Facade 依赖具体实现（如 *sql.DB、*http.Client），建议用工厂函数返回，比如 NewOrderService()，内部完成依赖组装
• 如果 Facade 只做纯逻辑编排、无外部依赖，可导出结构体，但务必提供带校验的构造函数，避免零值误用
• 导出结构体 + 导出字段 = 调用方可能绕过 Facade 直接操作子系统，违背模式本意；字段一律小写，仅通过方法暴露能力

方法命名要避开子系统原名，比如别叫 PayWithAlipay()

Facade 的价值不是“把三个支付方法列一遍”，而是抽象出业务语义。叫 ProcessPayment() 比 PayWithAlipay() 或 PayWithWechat() 更符合外观模式意图——使用者不该关心底层用了哪家支付，只关心“付款成功”这个结果。

容易踩的坑：方法名泄露实现细节后，一旦切换支付渠道，所有调用点都要改名，Facade 就白做了。

• 优先用动宾短语表达业务动作：PlaceOrder()、CancelSubscription()、VerifyUser()
• 若需保留多渠道选择，用参数控制，而不是拆成多个方法：PlaceOrder(&OrderRequest{PaymentMethod: "alipay"})
• 子系统错误要转换：把 alipay.ErrInvalidSign 包装成 ErrPaymentFailed，否则上层还得 import 支付 SDK

依赖注入时，接口比具体类型更安全

Facade 内部依赖的子系统，必须用接口而非具体类型声明。否则一换数据库驱动或 mock 测试，就得改 Facade 源码。

典型反例：db *sql.DB —— 这会让 Facade 和 database/sql 强绑定，没法替换成内存 mock 或其他 ORM。

• 定义清晰接口，如 type OrderRepository interface { Create(*Order) error }，Facade 只依赖这个
• 生产环境传入 &postgresRepo{db: realDB}，测试时传 &mockOrderRepo{}，完全无感
• 别为了“省事”在 Facade 里 new 子系统实例（比如 redis.NewClient()），这会让单元测试无法控制边界

别在 Facade 里做重试、熔断、日志——那是中间件的事

外观模式只负责“简化调用”，不是兜底层。加重试逻辑看似方便，实则污染职责：下次要换重试策略，就得动 Facade；要加链路追踪，又得改它；最后 Facade 变成胶水代码集合。

真实场景中，这些横切关注点应该剥离到独立层，比如用装饰器包装 Facade 实例：

service := NewOrderService(db, payment)
service = WithRetry(service, 3)
service = WithTracing(service, tracer)

• Facade 方法保持简单：输入 → 编排子系统 → 输出，不处理超时、重试、监控埋点
• 错误返回统一用自定义 error 类型（如 ErrOrderNotFound），但不要在里面打日志——日志由调用方或 middleware 决定何时打、打多少
• 性能影响明显：在 Facade 里加延迟重试，会拖慢所有走这个入口的请求；而装饰器可按需启用

Facade 最容易被忽略的一点：它不解决分布式事务或最终一致性问题。别指望靠它把订单、库存、积分扣减变成原子操作——那得靠 Saga 或消息队列，Facade 只管把这几个步骤串起来调用而已。

今天关于《Go语言外观模式实现，简化子系统调用》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！