简单工厂模式适用于创建单一类型的不同对象，通过一个工厂函数根据参数返回具体实现，适合产品种类少且变化不频繁的场景；抽象工厂模式则用于创建一组相关或依赖的对象家族，通过定义抽象工厂接口和多个具体工厂来保证产品间的一致性，适合需要整体切换产品族的复杂系统。两者核心区别在于简单工厂关注单个对象创建，抽象工厂关注多个关联对象的批量创建与组合，选择时需权衡系统复杂度、扩展需求及维护成本，go语言中利用接口特性可简洁实现这两种模式，但应避免过度设计，优先选用最匹配当前场景的方案。
工厂模式在Go语言中，本质上是一种创建型设计模式，它将对象的创建过程封装起来，让调用者无需关心具体创建哪个类，只需通过一个统一的接口或函数来获取所需对象。简单工厂模式通常用于创建一系列同类型但不同配置的对象，而抽象工厂模式则更进一步，它负责创建一系列相关或相互依赖对象的家族，而无需指定它们具体的类。在我看来，这两种模式在Go里用起来都挺顺手，但它们解决的问题和适用的场景却大相径庭。
解决方案
在Go语言中实现工厂模式，我们通常会利用其强大的接口（interface）特性。
简单工厂模式（Simple Factory Pattern）
立即学习“go语言免费学习笔记（深入）”；
简单工厂模式的核心是一个工厂函数或方法，它根据传入的参数来决定创建并返回哪种具体的产品实例。
假设我们正在开发一个游戏，需要创建不同类型的角色（比如战士、法师）。
package mainimport "fmt"// Character 是产品接口type Character interface { Attack() string Defend() string}// Warrior 是具体产品type Warrior struct{}func (w *Warrior) Attack() string { return "战士挥舞大剑，造成物理伤害！"}func (w *Warrior) Defend() string { return "战士举起盾牌，格挡攻击！"}// Mage 是具体产品type Mage struct{}func (m *Mage) Attack() string { return "法师吟唱咒语，释放魔法攻击！"}func (m *Mage) Defend() string { return "法师施展护盾，抵御伤害！"}// SimpleCharacterFactory 是简单工厂，根据类型创建角色func SimpleCharacterFactory(charType string) Character { switch charType { case "warrior": return &Warrior{} case "mage": return &Mage{} default: fmt.Println("未知角色类型，返回默认战士") return &Warrior{} // 或者返回nil，或者报错 }}// func main() {// warrior := SimpleCharacterFactory("warrior")// fmt.Println(warrior.Attack())// fmt.Println(warrior.Defend())// mage := SimpleCharacterFactory("mage")// fmt.Println(mage.Attack())// fmt.Println(mage.Defend())// // 尝试创建不存在的类型// unknown := SimpleCharacterFactory("rogue")// fmt.Println(unknown.Attack())// }
抽象工厂模式（Abstract Factory Pattern）
抽象工厂模式则更复杂一些，它提供一个接口，用于创建一系列相关或相互依赖的对象，而无需指定它们具体的类。可以理解为“工厂的工厂”。
继续游戏开发的例子，现在我们不仅有角色，还有武器和防具，并且这些物品是分“阵营”的，比如“光明阵营”和“黑暗阵营”，每个阵营都有自己的战士、法师，以及对应的武器和防具。
package mainimport "fmt"// --- 产品接口 ---type Character interface { Info() string}type Weapon interface { Damage() string}type Armor interface { Defense() string}// --- 光明阵营具体产品 ---type LightWarrior struct{}func (lw *LightWarrior) Info() string { return "光明战士" }type LightMage struct{}func (lm *LightMage) Info() string { return "光明法师" }type LightSword struct{}func (ls *LightSword) Damage() string { return "光明之剑造成圣光伤害" }type LightRobe struct{}func (lr *LightRobe) Defense() string { return "光明法袍提供神圣防御" }// --- 黑暗阵营具体产品 ---type DarkWarrior struct{}func (dw *DarkWarrior) Info() string { return "黑暗战士" }type DarkMage struct{}func (dm *DarkMage) Info() string { return "黑暗法师" }type DarkAxe struct{}func (da *DarkAxe) Damage() string { return "黑暗战斧造成腐蚀伤害" }type DarkPlate struct{}func (dp *DarkPlate) Defense() string { return "黑暗板甲提供暗影防御" }// --- 抽象工厂接口 ---type GameFactory interface { CreateWarrior() Character CreateMage() Character CreateWeapon() Weapon CreateArmor() Armor}// --- 光明阵营具体工厂 ---type LightFactory struct{}func (lf *LightFactory) CreateWarrior() Character { return &LightWarrior{} }func (lf *LightFactory) CreateMage() Character { return &LightMage{} }func (lf *LightFactory) CreateWeapon() Weapon { return &LightSword{} }func (lf *LightFactory) CreateArmor() Armor { return &LightRobe{} }// --- 黑暗阵营具体工厂 ---type DarkFactory struct{}func (df *DarkFactory) CreateWarrior() Character { return &DarkWarrior{} }func (df *DarkFactory) CreateMage() Character { return &DarkMage{} }func (df *DarkFactory) CreateWeapon() Weapon { return &DarkAxe{} }func (df *DarkFactory) CreateArmor() Armor { return &DarkPlate{} }// func main() {// // 创建光明阵营的物品// lightFactory := &LightFactory{}// lightWarrior := lightFactory.CreateWarrior()// lightWeapon := lightFactory.CreateWeapon()// lightArmor := lightFactory.CreateArmor()// fmt.Printf("创建了: %s, 武器: %s, 防具: %sn", lightWarrior.Info(), lightWeapon.Damage(), lightArmor.Defense())// // 创建黑暗阵营的物品// darkFactory := &DarkFactory{}// darkMage := darkFactory.CreateMage()// darkWeapon := darkFactory.CreateWeapon()// darkArmor := darkFactory.CreateArmor()// fmt.Printf("创建了: %s, 武器: %s, 防具: %sn", darkMage.Info(), darkWeapon.Damage(), darkArmor.Defense())// }
简单工厂模式在Go语言中如何落地？它适用于哪些场景？
简单工厂模式在Go语言中落地非常直观，通常表现为一个返回接口类型的函数。这个函数内部包含一个
switch
语句或者一个
map
，根据传入的字符串或其他标识符来决定实例化哪个具体的结构体，然后将其作为接口类型返回。在我看来，这种方式非常符合Go语言的“小而美”哲学，因为它的实现成本很低。
实现要点：
产品接口（Product Interface）： 定义所有具体产品需要实现的共同行为。这是Go语言中实现多态的基础。具体产品（Concrete Products）： 实现产品接口的实际结构体。工厂函数（Factory Function）： 这是简单工厂的核心。它接收一个参数（通常是字符串），根据这个参数判断并创建对应的具体产品实例，然后以产品接口类型返回。
适用场景：
我个人觉得，简单工厂模式最适合那些创建逻辑相对简单，且产品种类不多的情况。
配置加载： 例如，根据配置文件类型（JSON, YAML, XML）加载不同的解析器。你只需要一个
LoadConfigParser(type string)
函数。数据库连接： 根据数据库类型（MySQL, PostgreSQL, SQLite）返回不同的数据库连接器实例。日志输出： 根据日志级别（info, warn, error）或输出目标（文件、控制台）创建不同的日志处理器。单点创建： 当你希望将所有对象的创建逻辑集中在一个地方，避免客户端代码直接使用
&Struct{}
来创建对象时。这有助于解耦客户端与具体实现。
优点：
封装创建逻辑： 将对象的创建细节从客户端代码中分离出来，客户端只需要知道如何向工厂请求对象。代码集中： 所有的创建逻辑都在一个地方，便于维护和修改。易于理解和实现： 模式本身非常简单，几乎没有额外的复杂性。
缺点：
违反开闭原则： 如果需要添加新的产品类型，你必须修改工厂函数，这可能导致工厂函数变得庞大且难以维护。这在我看来是它最大的痛点，因为随着业务发展，这种修改会越来越频繁。职责过重： 随着产品种类的增加，工厂函数可能会变得过于复杂，承担了过多的创建责任。
抽象工厂模式在Go语言中又该如何实现？它与简单工厂的主要区别是什么？
抽象工厂模式在Go语言中实现时，同样离不开接口。它比简单工厂更抽象一层，引入了“工厂的工厂”的概念。
实现要点：
抽象产品接口（Abstract Products）： 为每一类产品定义一个接口（如
Character
,
Weapon
,
Armor
）。具体产品（Concrete Products）： 实现这些抽象产品接口的具体结构体，并且它们通常是按“家族”划分的（如
LightWarrior
,
DarkWarrior
）。抽象工厂接口（Abstract Factory Interface）： 定义一个接口，其中包含创建所有抽象产品的方法（如
CreateWarrior()
,
CreateWeapon()
）。具体工厂（Concrete Factories）： 实现抽象工厂接口的结构体。每个具体工厂负责创建某个特定“家族”的所有具体产品（如
LightFactory
创建所有光明阵营的产品）。
与简单工厂的主要区别：
在我看来，最核心的区别在于它们关注的粒度和解决的问题：
简单工厂： 关注的是单个产品的创建。它是一个“万能的”生产线，能生产不同型号的汽车，但一次只生产一种。当你需要创建不同“类型”但功能类似的对象时，简单工厂很合适。它更像是对
new
操作的封装。抽象工厂： 关注的是产品家族的创建。它是一整套生产线，能同时生产某个品牌的所有车型（轿车、SUV、跑车），并且这些车型都带有该品牌的统一风格和特性。当你需要确保创建的对象属于同一个“家族”或“主题”，并且这些对象之间存在关联性时，抽象工厂就派上用场了。它确保了产品之间的一致性和互操作性。
举个例子，简单工厂可能帮你创建“一个”数据库连接（MySQL或PostgreSQL），而抽象工厂则可能帮你创建“一套”与数据库相关的对象（MySQL连接、MySQL查询构建器、MySQL事务管理器），并且这些对象都是为MySQL设计的。
优点：
隔离具体类： 客户端代码完全不依赖于具体的产品类和工厂类，只依赖于接口。这使得系统更具弹性。易于切换产品家族： 改变产品家族非常容易，只需更换一个具体工厂实例即可，而无需修改客户端代码。保证产品一致性： 确保客户端使用的产品都是来自同一个家族，避免了混淆不同家族的产品。
缺点：
增加复杂性： 引入了更多的接口和类，代码结构会变得更复杂。对于小型项目，这可能是过度设计。难以扩展新产品类型： 如果需要增加一种新的产品类型（比如在我们的例子中增加一个
Mount
坐骑），那么所有的抽象工厂接口和所有具体工厂都需要修改，这违反了开闭原则。这是我个人觉得它比较“重”的地方。
什么时候选择简单工厂，什么时候选择抽象工厂？两者间的取舍考量？
选择简单工厂还是抽象工厂，这真是一个“看菜下碟”的问题，没有绝对的答案。我通常会根据项目的规模、复杂性以及未来的可扩展性需求来权衡。
选择简单工厂的考量：
简单性优先： 如果你的项目规模不大，或者创建的对象种类有限且变化不频繁，那么简单工厂的低实现成本和易于理解的特性是巨大的优势。过早地引入复杂模式往往会带来不必要的负担。创建逻辑集中： 当你只是想把对象的创建逻辑从客户端代码中抽离出来，形成一个统一的入口时，简单工厂足够了。产品之间无强关联： 如果你创建的各个产品之间没有必然的“家族”关系，它们只是通过同一个工厂函数创建，那么简单工厂就够了。比如，创建不同类型的报告生成器，它们之间可能没有直接的关联。
选择抽象工厂的考量：
需要创建产品家族： 当你的系统需要创建一系列相互关联或依赖的产品，并且这些产品需要保持一致性时，抽象工厂是理想选择。比如，一个UI库可能需要创建一套与特定操作系统（Windows, macOS, Linux）风格一致的按钮、文本框、滚动条等组件。易于切换产品家族： 如果你预计未来可能需要轻松地切换整个产品家族（例如，从“光明阵营”切换到“黑暗阵营”），而不需要修改大量客户端代码，那么抽象工厂的优势就体现出来了。系统规模和复杂性： 在大型、复杂的系统中，抽象工厂能够有效地管理大量的具体产品类，并保持架构的清晰。它为未来的扩展（增加新的产品家族）提供了良好的基础。
两者间的取舍：
我通常是这样思考的：
灵活性 vs. 复杂性： 简单工厂简单，但扩展新产品类型时不够灵活（需要修改工厂）。抽象工厂复杂，但扩展新产品家族时非常灵活（只需添加新的具体工厂）。这是一个经典的“易变性”和“稳定性”的权衡。维护成本： 对于小项目，抽象工厂的维护成本可能高于简单工厂。但对于大项目，简单工厂的“巨型switch”可能变成维护噩梦，而抽象工厂通过接口隔离，反而降低了维护成本。Go语言的视角： 在Go语言中，接口的轻量级特性使得这两种模式的实现都相对简洁。但即便如此，抽象工厂带来的额外接口和具体实现结构体，仍然增加了概念上的负担。有时候，一个简单的函数或者一个
map[string]func() interface{}
就能解决问题，不必强行套用设计模式。我个人更倾向于先用最简单的方式解决问题，如果发现痛点（比如违反开闭原则导致频繁修改），再考虑升级到更复杂的模式。
最终，选择哪种模式，取决于你对当前和未来需求的判断。没有银弹，只有最适合你当前场景的工具。
以上就是怎样用Golang实现工厂模式 对比简单工厂与抽象工厂区别的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1399878.html
微信扫一扫 
支付宝扫一扫 
