简单工厂模式¶

工厂模式是最常用的一类创建型设计模式，通常我们所说的工厂模式是指工厂方法模式，它也是使用频率最高的工厂模式。简单工厂模式是工厂方法模式的“小弟”，它不属于GoF 23种设计模式，但在软件开发中应用也较为频繁，工厂方法模式还有一位“大哥”——抽象工厂模式。这三种工厂模式各具特色，难度也逐个加大，在软件开发中它们都得到了广泛的应用。

问题¶

Sunny软件公司欲开发一套图表库，该图表库可以为应用系统提供各种不同外观的图表，例如柱状图、饼状图、折线图等。初始设计方案，将所有图表的实现代码封装在一个 Chart类中：

class Chart
{
	string type_;

public:
	Chart(string type)
	{
		this->type_ = type;
		if (type == "histogram") {
			//@ 初始化柱状图
		}
		else if (type == "pie") {
			//@ 初始化饼状图
		}
		else if (type == "line") {
			//@ 初始化折线图
		}
	}

	void display()
	{
		if (this->type_ == "histogram") {
			//@ 显示柱状图
		}
		else if (this->type_ == "pie") {
			//@ 显示饼状图
		}
		else if (this->type_ == "line") {
			//@ 显示折线图
		}
	}
};

客户端代码通过调用Chart类的构造函数来创建图表对象，根据参数type的不同可以得到不同类型的图表，然后再调用display()方法来显示相应的图表。

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

在Chart类中包含很多“if…else…”代码块，整个类的代码相当冗长，代码越长，阅读难度、维护难度和测试难度也越大；而且大量条件语句的存在还将影响系统的性能，程序在执行过程中需要做大量的条件判断。
Chart类的职责过重，它负责初始化和显示所有的图表对象，将各种图表对象的初始化代码和显示代码集中在一个类中实现，违反了“单一职责原则”，不利于类的重用和维护；而且将大量的对象初始化代码都写在构造函数中将导致构造函数非常庞大，对象在创建时需要进行条件判断，降低了对象创建的效率。
当需要增加新类型的图表时，必须修改Chart类的源代码，违反了“开闭原则”。
客户端只能通过new关键字来直接创建Chart对象，Chart类与客户端类耦合度较高，对象的创建和使用无法分离。
客户端在创建Chart对象之前可能还需要进行大量初始化设置，例如设置柱状图的颜色、高度等，如果在Chart类的构造函数中没有提供一个默认设置，那就只能由客户端来完成初始设置，这些代码在每次创建Chart对象时都会出现，导致代码的重复。

简单工厂模式结构¶

简单工厂模式(Simple Factory Pattern)：定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态(static)方法，因此简单工厂模式又被称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。

Factory（工厂角色）：工厂角色即工厂类，它是简单工厂模式的核心，负责实现创建所有产品实例的内部逻辑；工厂类可以被外界直接调用，创建所需的产品对象；在工厂类中提供了静态的工厂方法factoryMethod()，它的返回类型为抽象产品类型Product。
Product（抽象产品角色）：它是工厂类所创建的所有对象的父类，封装了各种产品对象的公有方法，它的引入将提高系统的灵活性，使得在工厂类中只需定义一个通用的工厂方法，因为所有创建的具体产品对象都是其子类对象。
ConcreteProduct（具体产品角色）：它是简单工厂模式的创建目标，所有被创建的对象都充当这个角色的某个具体类的实例。每一个具体产品角色都继承了抽象产品角色，需要实现在抽象产品中声明的抽象方法。

代码示例¶

//@ 汽车接口
class ICar
{
public:
	virtual string name() = 0;
	virtual ~ICar() = default;
};

//@ 奔驰汽车
class BenzCar : public ICar
{
public:
	virtual string name() override
	{
		return "Benz Car";
	}
};

//@ 宝马汽车
class BmwCar : public ICar
{
public:
	virtual string name() override
	{
		return "Bmw Car";
	}
};

//@ 工厂
class Factory
{
public:
	enum CAR_TYPE
	{
		BENZ_CAR, //@ 奔驰汽车
		BMW_CAR	  //@ 宝马汽车
	};

	std::unique_ptr<ICar> createCar(CAR_TYPE type)
	{
		std::unique_ptr<ICar> ret{ nullptr };
		switch (type)
		{
		case BENZ_CAR:
			ret.reset(new BenzCar());
			break;
		case BMW_CAR:
			ret.reset(new BmwCar());
			break;
		default:
			break;
		}
		return ret;
	}
};

int main()
{
	std::unique_ptr<Factory> pFactory(new Factory());
	std::unique_ptr<ICar> pCar = pFactory->createCar(Factory::BENZ_CAR);
	std::cout << pCar->name() << std::endl;

	pCar.swap(pFactory->createCar(Factory::BMW_CAR));
	std::cout << pCar->name() << std::endl;

	return 0;
}

简单工厂模式总结¶

简单工厂模式提供了专门的工厂类用于创建对象，将对象的创建和对象的使用分离开，它作为一种最简单的工厂模式在软件开发中得到了较为广泛的应用。

实现方式¶

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

优点¶

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

缺点¶

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

适用场景¶

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