工厂模式也是一种创建型模式，它与简单工厂不同的是将实例的创建推迟到具体的工厂类方法中实现，每一种产品生成一个对应的工厂，从而替换掉简单工厂方法模式中那个静态工厂方法。所以在工厂模式中，不同产品就由不同的工厂生产，每次增加产品时，我们就不需要在类似在简单工厂中，在统一的工厂类方法中修改，而是通过直接新建产品类，新建生产该产品的工厂类，通过这种模式，我们就可以解决简单工厂中的违背 OCP 的问题，对后期的代码扩展有利。
我们在应用工厂模式时，主要的结构设计包括如下：
- 1.定义产品接口，声明相关方法
- 2.定义具体产品，实现产品接口
- 3.定义工厂接口，声明工厂通用方法
- 4.定义不同产品的工厂类，实现工厂接口，工厂类和产品类往往依次对应
- 5.客户端需要生成哪种实例，就去请求对应的产品工厂生成实例
当然工厂模式也不是万能的，也有优缺点。
优缺点
- 优点：不直接在客户端创建具体产品的实例，降低了耦合性
1.不关心创建细节: 用户只需要关心所需产品对应的工厂, 无需关心创建细节;
2.符合开闭原则: 加入新产品,符合开闭原则, 提高可扩展性;
- 缺点：每增加一种产品就要相应的增加一个工厂类，类增多了。
1.增加复杂性 : 类的个数容易过多, 增加系统复杂度 ;
在添加新产品时, 除了编写新的产品类之外, 还要编写该产品类对应的工厂类 ;
2.增加难度: 增加了系统抽象性和理解难度 ;
工厂方法本身利用了抽象, 该模式中会引入抽象层, 如果要动态创建产品类, 还要引入反射技术;
适用场景
- 1.重复代码: 创建对象需要使用大量重复的代码;
- 2.不关心创建过程: 客户端不依赖产品类, 不关心实例如何被创建, 实现等细节;
- 3.创建对象: 一个类通过其子类来指定创建哪个对象。
代码实现
package main
import "fmt"
// 1.product interface
type iProduct interface {
show()
}
// 2.product struct
type iphoneProduct struct {
}
func (r *iphoneProduct) show() {
fmt.Println("This is iphone.")
}
type ipadProduct struct {
}
func (r *ipadProduct) show() {
fmt.Println("This is ipad.")
}
// 3.factory interface
type factory interface {
produce() iProduct
}
// 4.concrete factory
type iphoneFactory struct {
}
func (r *iphoneFactory) produce() iProduct {
return &iphoneProduct{}
}
type ipadFactory struct {
}
func (r *ipadFactory) produce() iProduct {
return &ipadProduct{}
}
func main() {
f1 := &iphoneFactory{}
f1.produce().show()
f2 := &ipadFactory{}
f2.produce().show()
}
参考：