一般情况下，工厂模式分为三种更为细分的类型：简单工厂、工厂方法和抽象工厂。其中，前两者的方法原理比较简单，在实际的项目里也比较常用；而抽象工厂的原理稍微复杂，在实际的项目中相对也不常用。所以，我们今天重点是前两种工厂模式，
简单工厂
在下面这段代码里，我们根据配置文件的后缀（json,xml,yaml, properties），选择不同的解析器(JsonRuleConfigParser, XmlRuleConfigParser)，将存在文件中的配置解析成内存对象RuleConfig
为了让代码逻辑更加清晰、可读性更好，我们要善于把功能独立的代码块封装成函数，按照这个设计思路，我们可以把代码中设计parse创建的部分逻辑剥离出来，抽象成createParse()函数。重构之后的代码如下所示：
为了让类的职责更加单一、代码更加清晰，我们还可以进一步将createParse()函数剥离到一个独立的类中，让这个类只负责对象的创建。而这个类就是简单工厂模式类。
大部分工厂类都是以Factory这个单词结尾的，但是也不是必须的；工厂类中创建对象的方法一般是create开头，比如代码里的createParser，但是也有的命名为getInstance()，createInstance()，newInstance，我们根据具体的场景和习惯来命名就好。
在上面的代码里，每次调用RuleConfigParserFactory的createParse的时候，都需要创建一个新的parser。实际上，如果parser可以复用，为了节省内存和对象创建的时间，我们可以把parser事先创建好缓存起来，类似单例模式和工厂模式的结合。
思考1：对于上面两种简单工厂模式的实现方法，如果我们要添加新的parser，那势必要改动到RuleConfigParserFactory的代码，那是不是违反开闭原则呢？
如果不是需要频繁地添加新的parser，只是偶尔修改RuleConfigParserFactory代码，稍微不符合开闭原则，也是可以接受的。
思考2：第一种实现里，有一组if分支判断逻辑，是否需要用多态或其他设计模式替代？
如果if分支不是很多，代码中有if分支也是可以接受的。
使用多态或设计模式替代if分支判断逻辑，虽然提高了代码的扩展性，但是也增加了类的个数，牺牲了代码的可读性。
工厂方法
思考3：如果必须将if分支逻辑去掉，那应该怎么办？
比较经典的方法就是利用多态 重构后的代码如下：
这就是工厂方法模式的典型代码实现，当新增一种parser的时候，只需要新增一个实现了IRuleConfigParserFactory接口的Factory类即可。所以，工厂方法模式比简单工厂更符合开闭原则。
但是实际上上述的方法存在很大的问题，在使用这些工厂类的时候，如何写load函数呢？
工厂类对象的创建逻辑又耦合进了load函数里，跟最初的代码版本很相似。那么怎么解决这个问题呢？
可以为工厂类再创建一个简单工厂，也就是工厂的工厂，用来创建工厂类对象。代码如下，其中RuleConfigParserFactoryMap类是创建工厂对象的工厂类，RuleConfigParserFactoryMap返回的是缓存好的单例工厂对象。
当我们需要添加新的规则配置解析器时，我们只需要创建新的parser类和parser factory类，并且在RuleConfigParserFactoryMap类里，将新的parser factory对象添加到cachedFactories里即可，代码的改动很少，基本上符合开闭原则。
实际上，对于规则配置文件解析这个应用场景来说，工厂模式需要额外创建诸多Factory类，也会增加代码的复杂性。而且，每个Factory类只是做简单的new操作，功能单薄，也没必要设计成独立的类。所以在这个应用场景下，简单工厂模式简单好用，比工厂方法模式更加合适。
思考：什么时候该用工厂方法模式，而非简单工厂模式？
当对象的创建逻辑比较复杂，不是简单的new一下就可以，而是要组装其他类对象，做各种初始化操作的时候，推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。
某些场景下，如果对象不可复用，工厂类每次都要返回不同的对象，如果用简单工厂模式实现，就只能选择第一种包含if分支逻辑的实现方式。如果我们还想避免烦人的if-else分支逻辑，就推荐使用工厂方法模式。
抽象工厂
在简单工厂和工厂方法中，类只有一种分类方法。比如在规则配置解析的例子里，解析器类只会根据配置文件格式(Json,xml,yaml)来分类。但是，如果类又两种分类方式。比如，我们既可以按照配置文件格式来分类，也可以按照解析的对象(Rule规则配置还是System系统配置)来分类，就会对应下面8个parser类。
针对这种特殊的场景，如果还是继续用工厂方法来实现的话，我们要针对每个parser都编写一个工厂类，也就是要编写8个工厂类。如果未来还要增加针对业务配置的解析器，比如IBizConfigParser，还需要再增加4个工厂类。
抽象工厂就是针对这种非常特殊的场景而诞生的，我们可以让一个工厂负责创建多个不同类型的对象（IRuleConfigParser、ISystemConfigParser 等），而不是只创建一种parser对象。
总结
当创建逻辑比较复杂，是一个大工程的时候，考虑使用工厂模式，封装对象的创建过程，将对象的创建和使用分离。
什么情况是创建逻辑比较复杂呢？
-
类似规则配置解析的例子，代码里存在if-else判断，动态的根据不同的类型创建不同的对象。
-
单个对象本身的创建过程比较复杂，比如要组合其他类对象，做各种初始化操作。
对于情况1，当每个对象的创建逻辑都比较简单，推荐使用简单工厂模式，将多个对象的创建逻辑放到一个工厂类里，当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个庞大的简单工厂类，推荐使用工厂方法模式，将创建逻辑拆分的更细，每个对象的创建逻辑独立到各自的工厂类里。
对于情况2， 因为单个对象本身的创建逻辑比较复杂，推荐使用工厂方法模式。
对于其他情况，如果创建对象的逻辑并不复杂，直接通过new来创建对象就可以了，不需要使用工厂模式。
现在，我们上升一个思维层面来看工厂模式，它的作用无外乎下面这四个。这也是判断要不要使用工厂模式的最本质的参考标准。
封装变化： 创建逻辑有可能变化，封装成工厂类之后，创建逻辑的变更对调用者透明。
代码复用： 创建代码抽离到独立的工厂类之后可以复用。
隔离复杂性： 封装复杂的创建逻辑，调用者无需了解如何创建对象。
控制复杂度： 将创建代码抽离出来，让原本的函数或类职责更单一，代码更简洁。
go代码示例
package _2_factory
import "fmt"
// 奶茶店
type MilkTeaShop interface {
GetMilkTea()
}
type HoneySnowIceCity struct{}
func (h *HoneySnowIceCity) GetMilkTea() {
fmt.Println("蜜雪冰城的柠檬水")
}
type ChaPanda struct{}
func (c *ChaPanda) GetMilkTea() {
fmt.Println("茶百道的芒芒生打椰")
}
func NewMilkTeaShop(name string) MilkTeaShop {
switch name {
case "mixue":
return &HoneySnowIceCity{}
case "cha":
return &ChaPanda{}
}
return nil
}
func Test_SimpleFactory(t *testing.T) {
NewMilkTeaShop("mixue").GetMilkTea()
NewMilkTeaShop("cha").GetMilkTea()
}
//=== RUN Test_SimpleFactory
//蜜雪冰城的柠檬水
//茶百道的芒芒生打椰
抽象工厂
package _2_factory
import "fmt"
type Lunch interface {
Cook()
}
type rise struct {
}
func (c *rise) Cook() {
fmt.Println("it is a rise.")
}
type Tomato struct {
}
func (c *Tomato) Cook() {
fmt.Println("it is Tomato.")
}
type LunchFactory interface {
CreateFood() Lunch
CreateVegetable() Lunch
}
type simpleLunchFactory struct {
}
func NewSimpleShapeFactory() LunchFactory {
return &simpleLunchFactory{}
}
func (s *simpleLunchFactory) CreateFood() Lunch {
return &rise{}
}
func (s *simpleLunchFactory) CreateVegetable() Lunch {
return &Tomato{}
}
func TestNewSimpleShapeFactory(t *testing.T) {
factory := NewSimpleShapeFactory()
food := factory.CreateFood()
food.Cook()
vegetable := factory.CreateVegetable()
vegetable.Cook()
}
//it is a rise.
//it is Tomato.