小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。
简单工厂模式,他不属于 GoF 23 种设计模式,但在软件开发中应用也较为频繁,通常将它作为学习其他工厂模式的入门。
什么是简单工厂模式
简单工厂模式又称为静态工厂模式,实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类(这些产品类继承自一个父类或接口)的实例。简单工厂模式的创建目标,所有创建的对象都是充当这个角色的某个具体类的实例。
其实就是将一个具体类的实例化交给一个静态工厂方法来执行,它不属于 GOF 的 23 种设计模式,但现实中却经常会用到,而且思想也非常简单。
简单工厂模式的结构
简单工厂模式包含如下角色:
| 角色 | 功能 |
|---|---|
| 工厂角色(Creator) | 是简单工厂模式的核心,它负责实现创建所有具体产品类的实例。工厂类可以被外界直接调用,创建所需的产品对象。 |
| 抽象产品角色(Product) | 是所有具体产品角色的父类,它负责描述所有实例所共有的公共接口。 |
| 具体产品角色(Concrete Product) | 继承自抽象产品角色,一般为多个,是简单工厂模式的创建目标。工厂类返回的都是该角色的某一具体产品。 |
简单工厂模式的应用场景
- 前几天苹果公司刚发布 iPhone12 和 iPhone12 Pro,那么问题来了,苹果公司的代工厂到底生产多少种尺寸的手机呢?
- 由工厂决定生产哪种型号的的手机,苹果公司的工厂就是一个工厂类,是简单工厂模式的核心类。
- iPhone12、iPhone12 Pro、iphone12 Pro Max 都是苹果手机,只是型号不同。苹果手机类满足抽象的定义,各个型号的手机类是其具体实现。
在以下情况下可以使用简单工厂模式:
工厂类负责创建的对象比较少:由于创建的对象较少,不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数,对于如何创建对象不关心:客户端既不需要关心创建细节,甚至连类名都不需要记住,只需要知道类型所对应的参数。
简单工厂的 UML 图
简单工厂模式的实现
-
创建一个"苹果手机"类,定义一个获取手机尺寸的方法
public abstract class ApplePhone { //获取尺寸 protected abstract void getSize(); } -
苹果手机不同型号的"手机类"。
public class Iphone12 extend ApplePhone{ public void getSize() { System.out.println("iphone 12 屏幕:3.5英寸"); } } public class Iphone12Pro extend ApplePhone{ public void getSize() { System.out.println("iphone 12 pro 屏幕:4.5英寸"); } } -
建立一个"工厂类"生产不同型号的"手机对象"。
public class AppleFactory { public static ApplePhone createPhone(String model){ ApplePhone applePhone = null; switch (model) { case"iphone12": applePhone = new Iphone12(); break; case"iphone12 pro": applePhone = new Iphone12Pro(); break; default: break; } return applePhone; } } -
客户端测试类
public class Client { public static void main(String[] args) { ApplePhone applePhone ; applePhone = AppleFactory.createPhone("iphone12"); applePhone.getSize(); applePhone = AppleFactory.createPhone("iphone12 pro"); applePhone.getSize(); } }
简单工厂模式的优缺点
优点:
工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.
通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。
而不必管这些对象究竟如何创建及如何组织的.明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点:
由于工厂类集中了所有实例的创建逻辑,违反了开闭原则,将全部创建逻辑集中到了一个工厂类中;
它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.
这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;