golang设计模式之简单工厂模式

简单工厂模式

wiki: 简单工厂模式并不属于 GoF 23 个经典设计模式，但一般将它做为学习其余工厂模式的基础，它的设计思想很简单，其基本流程以下：

首先将须要建立的各类不一样对象（例如各类不一样的 Chart 对象）的相关代码封装到不一样的类中，这些类称为具体产品类，而将它们公共的代码进行抽象和提取后封装在一个抽象产品类中，每个具体产品类都是抽象产品类的子类；而后提供一个工厂类用于建立各类产品，在工厂类中提供一个建立产品的工厂方法，该方法能够根据所传入的参数不一样建立不一样的具体产品对象；客户端只需调用工厂类的工厂方法并传入相应的参数便可获得一个产品对象。

简单工厂模式定义以下：

简单工厂模式（Simple Factory Pattern）：定义一个工厂类，它能够根据参数的不一样返回不一样类的实例，被建立的实例一般都具备共同的父类。由于在简单工厂模式中用于建立实例的方法是静态（static）方法，所以简单工厂模式又被称为静态工厂方法（Static Factory Method）模式，它属于类建立型模式。

简单工厂模式的要点在于：当你须要什么，只须要传入一个正确的参数，就能够获取你所须要的对象，而无须知道其建立细节。简单工厂模式结构比较简单，其核心是工厂类的设计，其结构如图所示

上面都是我抄来的...

大概要作的事情就是，当咱们想要建立一个对象的时候，调用同一个方法，传入不一样的参数就能够返回给咱们不一样的对象了

固然，前提是这些对象对应的类都实现了相同的接口

例如：

咱们建立一个工厂结构体，而且建立一个产品接口，工厂能够建立产品，只要在工厂的某个方法中传入不一样的参数，就能够返回实现产品接口的不一样的对象，

1. 建立工厂结构体:

type Factory struct {
   }
复制代码

2. 建立产品接口，这里为了方便，只写了一个方法，请根据本身的须要扩展

type Product interface {
   	create()
   }
复制代码

3. 建立两个产品：产品1和产品2，它们实现了产品接口:

// 产品1，实现产品接口
type Product1 struct {
}

func (p1 Product1) create() {
  	fmt.Println("this is product 1")
}

// 产品2，实现产品接口
type Product2 struct {
}

func (p1 Product2) create() {
  	fmt.Println("this is product 2")
}

复制代码

2. 为工厂结构体添加一个方法用于生产产品（实例化对象）:

func (f Factory) Generate(name string) Product {
     switch name {
     case "product1":
  	   return Product1{}
     case "product2":
  	   return Product2{}
     default:
  	   return nil
     }
 }   
复制代码

3. 这样就能够经过传入不一样的方法获得不一样的产品实例了:

// 建立一个工厂类，在应用中能够将这个工厂类实例做为一个全局变量
    	factory := new(Factory)
    
    	// 在工厂类中传入不一样的参数，获取不一样的实例
    	p1 := factory.Generate("product1")
    	p1.create() // output: this is product 1
    
    	p2 := factory.Generate("product2")
    	p2.create() // output: this is product 2
复制代码

上面的例子只是为了解释工厂模式的思想而设置的最简单的例子，下面举一个在实际中应用的例子：

bingo-log 是一个go语言的日志包，能够自定义日志输出格式，这里就用到了简单工厂模式，全部实现了 Connector 接口的结构体均可以做为参数传入日志结构体中，达到自定义输出格式的目的

项目地址: bingo-log

思路解析: 基于go开发日志处理包

请直接去项目 README.md 中查看使用方法，去思路解析中查看总体的设计思路

下面说说工厂模式的优缺点:

• 优势: 工厂类是整个工厂模式的核心，咱们只须要传入给定的信息，就能够建立所需实例，在多人协做的时候，无需知道对象之间的内部依赖，能够直接建立，有利于整个软件体系结构的优化

• 缺点: 工厂类中包含了全部实例的建立逻辑，一旦这个工厂类出现问题，全部实例都会受到影响，而且，工厂类中生产的产品都基于一个共同的接口，一旦要添加不一样种类的产品，这就会增长工厂类的复杂度，将不一样种类的产品混合在一块儿，违背了单一职责，系统的灵活性和可维护性都会下降，而且当新增产品的时候，必需要修改工厂类，违背了『系统对扩展开放，对修改关闭』的原则

因此咱们还有更加复杂的设计模式去适应更加复杂的系统~

且听下回分解~ ~

此文章的源码都在这个仓库中： golang设计模式

打个广告，推荐一下本身写的 go web框架 bingo,求star，求PR ~