authoropen in new window

第7节工厂模式（创建型模式）

❤️💕💕Java和Golang的设计模式，设计模式介绍、创建者模式、结构型模式、行为型模式。Myblog:http://nsddd.topopen in new window

[TOC]

创建形模式

模式名称	模式名称	作用
创建型模式 Creational Pattern	单例模式★★★★☆	是保证一个类仅有一个实例，并提供一个访问它的全局访问点。
简单工厂模式★★★☆☆	通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。
工厂方法模式★★★★★	定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。
抽象工厂模式★★★★★	提供一个创建一系列相关或者相互依赖的接口，而无需指定它们具体的类。
原型模式★★★☆☆	用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
建造者模式★★☆☆☆	将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。

提示

目前标准的创建型设计模式共有6种（注：设计模式种类并非仅仅局限于此，设计模式实则是一种编程思想，开发者可以根据自身经验来总结出很多种设计模式思想，这6中创建型设计模式为早期官方认可的标准模式）

简单工厂模式

一般逻辑💡简单的一个案例如下：

// Factory mode
package main

import "fmt"

//Define a fruit structure
type Fruit struct {
	//................................................................

}

//Define a method of obtaining fruit
func (f *Fruit) GetFruit() string {
	return "fruit"
}

func (f *Fruit) String(name string) string {
	switch name {
	case "apple":
		fmt.Println("我是苹果")
		return "apple"
	case "orange":
		fmt.Println("我是橘子")
		return "orange"
	default:
		fmt.Println("我是水果")
		return "fruit"
	}
}

//Define a fruit method (create a fruit)
func NewFruit(name string) *Fruit {
	fruit := &Fruit{}
	switch name {
	case "apple":
		//Create an apple
	case "orange":
		//Create an orange
	case "banana":
		//Create a banana
	case "pear":
		//Create a pear
	default:
		fmt.Println("没有这个水果")
	}
	return fruit
}

//Business logic
func main() {
	//Create a fruit
	fruit := NewFruit("apple")
	//Get fruit
	fruit.GetFruit()
	//Get the name of the fruit
	fruit.String("apple")

	fruit = NewFruit("orange")
	fruit.GetFruit()
	fruit.String("orange")

	fruit = NewFruit("banana")
	fruit.GetFruit()
	fruit.String("banana")

}

🚀 编译结果如下：

[Running] go run "d:\文档\最近的\awesome-golang\docs\code\go-super\84-main.go"
我是苹果
我是橘子
我是水果

问题

不难看出，Fruit类是一个“巨大的”类，在该类的设计中存在如下几个问题：

(1) 在Fruit类中包含很多“if…else…” （或者 switch）代码块，整个类的代码相当冗长，代码越长，阅读难度、维护难度和测试难度也越大；而且大量条件语句的存在还将影响系统的性能，程序在执行过程中需要做大量的条件判断。

(2) Fruit类的职责过重，它负责初始化和显示所有的水果对象，将各种水果对象的初始化代码和显示代码集中在一个类中实现，违反了“单一职责原则”，不利于类的重用和维护；

(3) 当需要增加新类型的水果时，必须修改Fruit类的构造函数NewFruit()和其他相关方法源代码，违反了“开闭原则”。

关键是来观察 main() 函数，main() 函数与 Fruit 类是两个模块。当业务层希望创建一个对象的时候，将直接依赖Fruit类型的构造方法 NewFruit()，这样随着Fruit的越来越复杂，那么业务层的开发逻辑也需要依赖Fruit模块的更新，且随之改变，这样将导致业务层开发需要观察Fruit模块做改动，影响业务层的开发效率和稳定性。整体的依赖关系为。

业务逻辑层 ---> 基础类模块

那么如何将业务层创建对象与基础类模块做解耦呢，这里即可以在中间加一层工厂模块层，来降低业务逻辑层对基础模块层的直接依赖和耦合关联。

业务逻辑层 ---> 工厂模块 ---> 基础类模块

这样就引出了需要对工厂模块的一些设计和加工生成基础模块对象的模式。

简单工厂模式设计

简单工厂模式并不属于GoF的23种设计模式。他是开发者自发认为的一种非常简易的设计模式，其角色和职责如下：

工厂（Factory）角色：简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。

抽象产品（AbstractProduct）角色：简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。

具体产品（Concrete Product）角色：简单工厂模式所创建的具体实例对象。

改进类图：

工厂作为交际，我们不需要针对具体的水果，工厂返回就好了

package main

import "fmt"

//------抽象层------
type Fruit interface {
	String(name string) string
}

//------实现层------
type Apple struct {
}

func (apple *Apple) String(name string) string {
	fmt.Println("apple")
	return "apple"
}

type Orange struct {
}

func (orange *Orange) String(name string) string {
	fmt.Println("orange")
	return "orange"
}

type Banana struct {
}

func (banana *Banana) String(name string) string {
	fmt.Println("banana")
	return "banana"
}

type Pear struct {
}

func (pear *Pear) String(name string) string {
	fmt.Println("pear")
	return "pear"
}

//------工厂层------
type Factory struct {
}

func (factory *Factory) GetFruit(name string) Fruit {
	var fruit Fruit
	switch name {
	case "apple":
		fruit = &Apple{}
	case "orange":
		fruit = &Orange{}
	case "banana":
		fruit = &Banana{}
	case "pear":
		fruit = &Pear{}
	}
	return fruit
}

//------业务逻辑层------
func main() {
	Factory := &Factory{}
	apple := Factory.GetFruit("apple")
	apple.String("apple")

	orange := Factory.GetFruit("orange")
	orange.String("orange")

	banana := Factory.GetFruit("banana")
	banana.String("banana")
}

🚀 编译结果如下：

[Running] go run "d:\文档\最近的\awesome-golang\docs\code\go-super\85-main.go"
apple
orange
banana

简单工厂方法模式的优缺点

优点：

实现了对象创建和使用的分离。
不需要记住具体类名，记住参数即可，减少使用者记忆量。

缺点：

对工厂类职责过重，一旦不能工作，系统受到影响。
增加系统中类的个数，复杂度和理解度增加。
违反“开闭原则”，添加新产品需要修改工厂逻辑，工厂越来越复杂。

适用场景：

工厂类负责创建的对象比较少，由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象并不关心。

END 链接

Ⓜ️回到目录🏠
🫵参与贡献💞❤️‍🔥💖open in new window)

# 第7节 工厂模式（创建型模式）

# 创建形模式

# 简单工厂模式

# 简单工厂模式设计