简单工厂模式介绍：类创建型模式，含角色及核心职责

模式定义

简单工厂模式，亦称作静态工厂方法模式，是类创建型模式的一种。此模式允许根据传入的参数返回不同类的实例。它特设一个类，专门负责生成其他类的实例，而这些被创建的实例往往共享一个共同的父类。

模式结构

简单工厂模式包含如下角色：

Factory：工厂角色

Product：抽象产品角色

ConcreteProduct：具体产品角色

工厂角色（Creator）

工厂模式是基础，其核心职能在于生成各类具体产品的实例。此类工厂可直接被外部调用，用以构建所需的产品实体。

抽象产品角色（Product）

这是所有具体产品角色的基础类别，其主要任务是阐述所有实例所具备的通用接口。

具体产品角色（Concrete Product）

源自抽象产品角色的特性，通常涉及多个角色，这构成了简单工厂模式的主要创建目标。由工厂类所提供的，均为该抽象角色下的某个具体产品。

UML图

下面是代码实现：

package factory;
//简单工厂代码demo
public class Test1 {
	interface Product{
		public void work() ;
	}
	
定义了一个静态内部类Phone，该类继承自Product接口。
		public void work() {
			System.out.println("手机开始工作");
		}
	}
定义了一个静态类Computer，该类继承自Product接口。
		public void work() {
			System.out.println("电脑开始工作");
		}
	}
	
	static class ProductFactory{
公开静态方法获取产品，参数为产品名称字符串：getProduct(String productName) {
			if("phone".equals(name)) {
				return new Phone();
若名称与“计算机”相符，则执行条件判断。
				return new Computer();
			}else {
				return null;
			}
			
			
		}
	}
执行主程序入口，调用系统初始化操作，启动主函数。
		// 使用工厂模式 降低使用者与被使用者之间的耦合
创建一个名为phone的新手机对象。
将用户与使用对象之间的关联性转变为用户与制造厂之间的关联性。
Product phone；系由ProductFactory根据"phone"这一参数所获取的产品实例；
		if(null!=phone) {
		phone.work();
		}
	}
}

仔细思考一番，这不就是存在问题吗？若要生成大量不同类型的示例，在工厂类中是否需要进行多次判断？对此，是否有改进的策略或其他可行的模式呢？

模式分析

将创建对象的过程与对象自身的业务处理分离开来，有助于降低系统间的耦合程度，从而使得对这两方面的修改都变得更加简便。

在执行工厂类的方法时，得益于工厂方法均为静态，其操作便捷，可直接通过类名进行调用。此外，仅需提供一个基础参数。在具体开发过程中，我们甚至可以将这些参数存储于XML等配置文件中，这样一来，在调整参数时，便无需对源代码进行任何修改。

简单工厂模式存在一个显著缺陷，即工厂类承担了过多的职责，每当新增产品时，都必须对工厂类的决策逻辑进行修改，这种做法显然与开闭原则背道而驰。

简单工厂模式的核心在于，仅需输入一个恰当的参数，即可直接获得所需的对象，无需了解其构建的具体过程。

模式优缺点

工厂类内置了必要的决策机制，能够确定何时以及创建哪个产品类的实例，从而使得客户端无需承担直接构建产品对象的任务，只需负责“使用”产品；简单工厂模式正是通过这种方式实现了职责的划分，并专门设置了工厂类来负责对象的生成。

用户在使用过程中无需掌握所建产品类别确切的名称，仅需了解对应的具体参数信息；面对那些较为繁复的类别名称，采用简单工厂方法能够有效降低用户需记忆的内容量。

通过引入配置文件机制，我们能够在不触及客户端代码的前提下，灵活地替换或添加新的产品类别，从而在较大程度上增强了系统的适应性。

工厂汇集了所有产品的生成规则，若其运作出现异常，整个系统便会遭受波及。

采用简单工厂模式会导致系统内部类数量增多，从而在一定程度上提升了系统的复杂性以及理解的困难程度。

系统扩展存在挑战，新增产品时往往需要调整工厂的运作逻辑；当产品种类增多，工厂逻辑可能会变得过于繁杂，这不利于系统的进一步扩展与维护。

简单工厂模式因采用静态工厂方法，导致工厂角色难以构建起一个基于继承的层级体系。

模式适用环境

在以下情况下可以使用简单工厂模式：

工厂所负责生成的实体数量相对有限；因此，生成的实体数量少，使得工厂方法中的业务流程不会变得过于繁杂。

客户端仅需了解向工厂类传递的参数，对于对象的生成过程并不感兴趣：客户端无需关注创建过程的细节，甚至无需记住具体的类名，只需掌握类型与相应参数的对应关系即可。

小结

创建型模式对类实例化的流程进行了概括，它使得对象的生成与对象的应用得以分开处理。

简单工厂模式亦称作静态工厂方法模式，此类模式归属于类创建型范畴。在这种模式里，通过参数的不同，可以生成不同类的实例。该模式特别设立了一个类，其职责是创建其他类的实例，而这些被创建的实例往往共享一个共同的父类。

简单工厂模式中涉及三个关键角色：首先，工厂角色承担着创建所有实例的内部逻辑的实现任务；其次，抽象产品角色作为所有创建对象的父类，负责定义这些实例共有的公共接口；最后，具体产品角色则是创建的目标，所有被创建的对象均以某个具体类实例的形式扮演这一角色。

简单工厂模式的要点在于：当你需要什么，只需要传入一个正确的参数，就可以获取你所需要的对象，而无须知道其创建细节。

简单工厂模式的核心优势是实现了对象创建与使用的分离，将对象的生成任务委托给特定的工厂类来执行。然而，这种模式的显著不足在于工厂类的灵活性不足，若要引入新的具体产品，就必须对工厂类的判断逻辑进行修改。此外，当产品种类增多时，工厂方法的相关代码会变得异常复杂。

简单工厂模式适用于以下场景：工厂类所创建的对象数量有限；用户仅需提供给工厂类相应的参数，而对对象的创建过程并不感兴趣。