工厂方法模式（Factory Method）在 Go 语言中的应用能够有效分离对象的创建与业务逻辑，特别适用于需要扩展和动态生成对象的场景。在本篇文章中，我们将详细解读工厂方法模式的概念、适用场景，并结合具体的支付业务案例来展示其实现与优势。
👉 点击查看《Go语言设计模式实战》系列文章目录
《Go语言设计模式实战》以 Go 语言为示例，详细解读编程开发中常见设计模式的实现，涵盖创建型、结构型和行为型设计模式。每篇文章通过具体的 Go 代码展示模式的实际应用，帮助读者深入理解设计模式的核心原理及其在软件开发中的最佳实践。以下是该系列文章的全部内容：
- Go语言设计模式实战：单例模式详解
- Go语言设计模式实战：原型模式详解
- Go语言设计模式实战：工厂方法模式详解
- Go语言设计模式实战：建造者模式详解
- Go语言设计模式实战：建造者模式详解
- Go语言设计模式实战：抽象工厂模式详解
- Go语言设计模式实战：享元模式详解
- Go语言设计模式实战：代理模式详解
- Go语言设计模式实战：外观模式详解
- Go语言设计模式实战：桥接模式详解
- Go语言设计模式实战：组合模式详解
- Go语言设计模式实战：装饰模式详解
- Go语言设计模式实战：适配器模式详解
- Go语言设计模式实战：责任链模式详解
- Go语言设计模式实战：中介者模式详解
- Go语言设计模式实战：命令模式详解
- Go语言设计模式实战：迭代器模式详解
- Go语言设计模式实战：备忘录模式详解
- Go语言设计模式实战：状态模式详解
- Go语言设计模式实战：观察者模式详解
- Go语言设计模式实战：模板方法模式详解
- Go语言设计模式实战：策略模式详解
- Go语言设计模式实战：访问者模式详解
工厂方法模式的适用场景
工厂方法模式适用于以下情况：
- 当对象的具体类型和依赖关系不确定时：工厂方法模式可以提供动态的实例生成机制，避免在创建对象时直接绑定类型。
- 为用户提供扩展能力：如果用户可能需要在不修改原代码的情况下扩展软件库或框架的组件，工厂方法模式是理想选择。
- 复用对象以节省资源：通过工厂方法集中管理对象生成，可以在适当情况下复用对象，从而提高系统效率。
问题背景：实现灵活的支付渠道
假设我们需要使用 Golang 实现一个支付系统，初始设计是通过 Pay 方法进行支付，如下代码所示：
package main
import "fmt"
type Pay interface {
Pay() string
}
type PayReq struct {
OrderId string
}
func (p *PayReq) Pay() string {
fmt.Println(p.OrderId)
return "支付成功"
}
func main() {
p := PayReq{OrderId: "12345678"}
fmt.Println(p.Pay())
}
当前设计中，接口 Pay 中包含一个支付方法 Pay()，通过实现该方法即可执行支付操作。然而，随着业务发展，我们可能需要支持多种支付方式，例如 APay 和 BPay。每种支付方式的参数不同，APay 只需订单号 OrderId，而 BPay 则需订单号和用户 ID Uid。
不理想的初步解决方案
一种直观的做法是在接口中直接添加多种支付方式，但这会导致代码冗余。以下代码为接口 Pay 添加了 APay() 和 BPay() 方法：
package main
import "fmt"
type Pay interface {
APay() string
BPay() string
}
type PayReq struct {
OrderId string
Uid int64
}
func (p *PayReq) APay() string {
fmt.Println(p.OrderId)
return "APay支付成功"
}
func (p *PayReq) BPay() string {
fmt.Println(p.OrderId)
fmt.Println(p.Uid)
return "BPay支付成功"
}
func main() {
a := &PayReq{OrderId: "A12345678"}
fmt.Println(a.APay())
b := &PayReq{OrderId: "B12345678", Uid: 888}
fmt.Println(b.BPay())
}
这种设计虽然解决了需求，但缺点在于 PayReq 的结构体过于冗杂，容易导致参数不一致，扩展性较差。如果业务增加新的支付方式（如 CPay、DPay），代码复杂性和维护成本将显著提升。
工厂方法模式的优化解决方案
要实现更灵活、可扩展的支付方式，可以通过工厂方法模式来解决。通过定义一个工厂类，使之能够根据支付类型动态生成对应的支付对象，将不同支付方式的实现下放到子类。
以下代码展示了使用工厂方法模式的优化实现：
package main
import "fmt"
// Pay接口定义
type Pay interface {
Pay() string
}
// PayReq结构体定义，包含OrderId
type PayReq struct {
OrderId string
}
// APayReq和BPayReq结构体分别实现Pay接口
type APayReq struct {
PayReq
}
func (p *APayReq) Pay() string {
fmt.Println(p.OrderId)
return "APay支付成功"
}
type BPayReq struct {
PayReq
Uid int64
}
func (p *BPayReq) Pay() string {
fmt.Println(p.OrderId)
fmt.Println(p.Uid)
return "BPay支付成功"
}
func main() {
var pay Pay
pay = &APayReq{PayReq{"A12345678"}}
fmt.Println(pay.Pay())
pay = &BPayReq{PayReq: PayReq{"B12345678"}, Uid: 888}
fmt.Println(pay.Pay())
}
在该设计中，APayReq 和 BPayReq 分别实现了 Pay() 方法，并各自包含必要的参数（如 BPay 包含 Uid）。通过工厂方法，创建不同支付对象的逻辑从调用处解耦，这使得添加新的支付方式更加简洁。未来如果需要 CPay、DPay，可以简单地实现新的子类并定义其 Pay() 方法。
工厂方法模式的优势总结
- 解耦创建与使用：工厂方法模式将对象的创建过程独立出来，使得调用者无需关心具体的实例类型和创建细节。
- 高扩展性：新支付方式的增加无需修改现有代码，只需添加对应子类，符合开放封闭原则。
- 简化代码结构：避免了在主结构体中定义多余的字段，使得代码更加清晰、结构紧凑。
FAQ
1. 工厂方法模式适用于哪些开发场景？
工厂方法模式适合在不确定具体对象类型、需要高扩展性或希望解耦创建逻辑的场景。它允许开发者在代码中延迟确定实例化类型，从而提升代码的复用性和扩展性。
2. 工厂方法模式在 Go 语言中有什么优势？
在 Go 语言中，工厂方法模式可以通过接口和结构体组合来实现对象的动态创建，使代码结构更清晰，并减少模块间的耦合。在多支付渠道的系统设计中，工厂方法模式尤为适用，因为它支持创建不同支付方式对象的灵活性。
3. 使用工厂方法模式如何应对业务需求变化？
工厂方法模式通过分离创建逻辑，允许开发者仅通过添加新的子类来扩展新功能，而不需要修改现有代码。这种设计能显著降低维护成本，并提高代码的灵活性和扩展性。
4. Go 语言中如何实现工厂方法模式？
可以通过接口和结构体组合实现。在本文中，我们将接口 Pay 作为工厂，针对不同支付类型定义实现结构体，例如 APayReq 和 BPayReq。每个实现都可重写接口方法，满足不同的支付参数需求。
5. 工厂方法模式与简单工厂模式有何不同？
工厂方法模式提供更灵活的对象创建方式，将实例化的控制权交给子类，而简单工厂模式则由工厂类本身决定对象创建的细节。工厂方法模式适用于复杂场景，便于扩展，简单工厂则更适合静态且单一类型的对象生成。
总结
在 Go 语言中，工厂方法模式作为设计模式的一种，提供了模块间低耦合、易扩展的解决方案，特别是在多渠道支付系统中更显其优越性。本文通过支付系统实例详细解析了工厂方法的使用方法与实现步骤，希望您对该模式的原理与应用有了深入了解。在实际开发中，通过灵活运用工厂方法模式，您可以更高效地管理对象生成、提升代码的扩展性，从而为系统后期的维护和升级奠定坚实的基础。
