Go的设计模式之工厂模式

简介

设计模式是面向对象软件的设计经验，是解决特定问题的一系列套路。它不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。每一种设计模式系统的命名、解释和评价了面向对象中一个重要的和重复出现的设计。

创建模式是用来帮助我们创建对象的，具体有如下几种：

工厂模式 （Factory Pattern）
抽象工厂模式 （Abstract Factory Pattern）
单例模式 （Singleton Pattern）
建造者模式 （Builder Pattern）
原型模式 （Prototype Pattern）

工厂模式

通俗解释
追 MM 少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是 MM 爱吃的东西，虽然口味有所不同，但不管你带 MM 去麦当劳或肯德基，只管向服务员说「来四个鸡翅」就行了。麦当劳和肯德基就是生产鸡翅的 Factory 工厂模式：客户类和工厂类分开。

消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。

简单工厂模式

简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同类的实例。

优点

工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。 客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。 通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

缺点

由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。 使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。 系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。 简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

代码编写

由于 Go 本身是没有构造函数的，一般而言我们采用 NewName 的方式创建对象/接口，当它返回的是接口的时候，其实就是简单工厂模式

package factory

// IRuleConfigParser IRuleConfigParser

type IRuleConfigParser interface {
	Parse(data []byte)
}

// jsonRuleConfigParser jsonRuleConfigParser
type jsonRuleConfigParser struct {
}

// Parse Parse
func (J jsonRuleConfigParser) Parse(data []byte) {
	panic("implement me")
}

// yamlRuleConfigParser yamlRuleConfigParser
type yamlRuleConfigParser struct {
}

// Parse Parse
func (Y yamlRuleConfigParser) Parse(data []byte) {
	panic("implement me")
}

// NewIRuleConfigParser NewIRuleConfigParser

func NewIRuleConfigParser(t string) IRuleConfigParser {
	switch t {
	case "json":
		return jsonRuleConfigParser{}
	case "yaml":
		return yamlRuleConfigParser{}
	}
	return nil
}

测试

package factory

import (
	"reflect"
	"testing"
)

func TestNewIRuleConfigParser(t *testing.T) {
	type args struct {
		t string
	}
	tests := []struct {
		name string
		args args
		want IRuleConfigParser
	}{
		{
			name: "json",
			args: args{t: "json"},
			want: jsonRuleConfigParser{},
		},
		{
			name: "yaml",
			args: args{t: "yaml"},
			want: yamlRuleConfigParser{},
		},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			if got := NewIRuleConfigParser(tt.args.t); !reflect.DeepEqual(got, tt.want) {
				t.Errorf("NewIRuleConfigParser() = %v, want %v", got, tt.want)
			}
		})
	}
}

工厂模式

在工厂方法模式中，我们执行单个函数，传入一个参数(提供信息表明我们想要什么)，但 并不要求知道任何关于对象如何实现以及对象来自哪里的细节

适用场景

创建对象需要大量重复的代码 客户端(应用层)不依赖于产品实例，如何被创建、实现等细节 一个类通过其子类来指定创建哪个对象

优点

用户只需要关心所需产品对应的工厂，无须关心创建细节 加入新产品符合开闭原则，提高可扩展性

缺点

在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。 由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。

代码编写

当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂

// IRuleConfigParserFactory 工厂方法接口
type IRuleConfigParserFactory interface {
	CreateParser() IRuleConfigParser
}

// yamlRuleConfigParserFactory yamlRuleConfigParser 的工厂类
type yamlRuleConfigParserFactory struct {
}

// CreateParser CreateParser
func (y yamlRuleConfigParserFactory) CreateParser() IRuleConfigParser {
	return yamlRuleConfigParser{}
}

// jsonRuleConfigParserFactory jsonRuleConfigParser 的工厂类
type jsonRuleConfigParserFactory struct {
}

// CreateParser CreateParser
func (j jsonRuleConfigParserFactory) CreateParser() IRuleConfigParser {
	return jsonRuleConfigParser{}
}

// NewIRuleConfigParserFactory 用一个简单工厂封装工厂方法
func NewIRuleConfigParserFactory(t string) IRuleConfigParserFactory {
	switch t {
	case "json":
		return jsonRuleConfigParserFactory{}
	case "yaml":
		return yamlRuleConfigParserFactory{}
	}
	return nil
}

测试

package factory

import (
	"reflect"
	"testing"
)

func TestNewIRuleConfigParserFactory(t *testing.T) {
	type args struct {
		t string
	}
	tests := []struct {
		name string
		args args
		want IRuleConfigParserFactory
	}{
		{
			name: "json",
			args: args{t: "json"},
			want: jsonRuleConfigParserFactory{},
		},
		{
			name: "yaml",
			args: args{t: "yaml"},
			want: yamlRuleConfigParserFactory{},
		},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			if got := NewIRuleConfigParserFactory(tt.args.t); !reflect.DeepEqual(got, tt.want) {
				t.Errorf("NewIRuleConfigParserFactory() = %v, want %v", got, tt.want)
			}
		})
	}
}

抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，属于对象创建型模式。一个抽象工厂是一些工厂方法的（逻辑）集合，其中每一个工厂方法负责生成不同的对象。

通俗解释

请 MM 去麦当劳吃汉堡，不同的 MM 有不同的口味，要每个都记住是一件烦人的事情，我一般采用 Factory Method 模式，带着 MM 到服务员那儿，说「要一个汉堡」，具体要什么样的汉堡呢，让 MM 直接跟服务员说就行了。

工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

应用环境

使用工厂模式还是抽象工厂模式？

通常先从简单的工厂模式开始，后面发现应用程序需要许多的工厂方法，且将这些工厂方法组合起来创建一系列的对象是有意义的，这样的话就应该使用抽象工厂。

优点

抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易。所有的具体工厂都实现了抽象工厂中定义的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。另外，应用抽象工厂模式可以实现高内聚低耦合的设计目的，因此抽象工厂模式得到了广泛的应用。 当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。这对一些需要根据当前环境来决定其行为的软件系统来说，是一种非常实用的设计模式。 增加新的具体工厂和产品族很方便，无须修改已有系统，符合“开闭原则”。

缺点

在添加新的产品对象时，难以扩展抽象工厂来生产新种类的产品，这是因为在抽象工厂角色中规定了所有可能被创建的产品集合，要支持新种类的产品就意味着要对该接口进行扩展，而这将涉及到对抽象工厂角色及其所有子类的修改，显然会带来较大的不便。 开闭原则的倾斜性（增加新的工厂和产品族容易，增加新的产品等级结构麻烦）。

代码实现

该示例来自《Mastering Python Design Patterns，Second Edition》，模拟一个游戏。

游戏的实现需要三个接口：Hero、Obstacle、World

Hero 的实现：青蛙、巫师
Obstacle 的实现：虫子、邪恶兽人
World 的实现：青蛙世界、巫师世界

package abstractfactory

import (
	"fmt"
)

// Hero 英雄
type Hero interface {
	// InteractWith 和 xx 交互
	InteractWith(Obstacle)
	String() string
}

var _ Hero = (*Frog)(nil)

// Frog 青蛙🐸
type Frog struct {
	Name string
}

func (f *Frog) InteractWith(o Obstacle) {
	act := o.Action()

	fmt.Printf("%s the Frog encounters %s and %s！\n", f, o, act)
}

func (f *Frog) String() string {
	return f.Name
}

var _ Hero = (*Wizard)(nil)

// Wizard 巫师💂
type Wizard struct {
	Name string
}

func (w *Wizard) InteractWith(o Obstacle) {
	act := o.Action()

	fmt.Printf("%s the Wizard battles against %s and %s!\n", w, o, act)
}

func (w *Wizard) String() string {
	return w.Name
}

// Obstacle 障碍物
type Obstacle interface {
	// Action 动作
	Action() string
	String() string
}

var _ Obstacle = (*Bug)(nil)

// Bug 虫子🐛
type Bug struct{}

func (b *Bug) Action() string {
	return "eat it"
}

func (b *Bug) String() string {
	return "a bug"
}

var _ Obstacle = (*Ork)(nil)

// Ork 兽人👹
type Ork struct{}

func (o *Ork) Action() string {
	return "kills it"
}

func (o *Ork) String() string {
	return "an evil ork"
}

// World  世界
type World interface {
	// MakeCharacter 初始化角色
	MakeCharacter() Hero
	// MakeObstacle 初始化障碍物
	MakeObstacle() Obstacle
	String() string
}

var _ World = (*FrogWorld)(nil)

// FrogWorld 青蛙的世界
type FrogWorld struct {
	PlayerName string
}

func (fw *FrogWorld) MakeCharacter() Hero {
	return &Frog{
		Name: fw.PlayerName,
	}
}

func (fw *FrogWorld) MakeObstacle() Obstacle {
	return &Bug{}
}

func (fw *FrogWorld) String() string {
	return "\n\n\t------ Frog World ------"
}

var _ World = (*WizardWorld)(nil)

// WizardWorld 巫师世界
type WizardWorld struct {
	PlayerName string
}

func (ww *WizardWorld) MakeCharacter() Hero {
	return &Wizard{
		Name: ww.PlayerName,
	}
}

func (ww *WizardWorld) MakeObstacle() Obstacle {
	return &Ork{}
}

func (ww *WizardWorld) String() string {
	return "\n\n\t------ Wizard World ------"
}

// GameEnvironment 游戏入口 🕹
type GameEnvironment struct {
	hero     Hero
	obstacle Obstacle
}

func NewGame(world World) GameEnvironment {
	fmt.Println(world)
	return GameEnvironment{
		hero:     world.MakeCharacter(),
		obstacle: world.MakeObstacle(),
	}
}

// Play 开始游戏
func (g GameEnvironment) Play() {
	g.hero.InteractWith(g.obstacle)
}

测试

package abstractfactory

import "testing"

func TestFrogWorld(t *testing.T) {
	var world World = &FrogWorld{PlayerName: "Billy"}

	var game GameEnvironment = NewGame(world)

	game.Play()
}

func TestWizardWorld(t *testing.T) {
	var world World = &WizardWorld{PlayerName: "Charles"}

	var game GameEnvironment = NewGame(world)

	game.Play()
}