设计模式之工厂模式—要的是工厂而不是作坊

开发 前端
我们用生活中常用的支付来说明工厂模式的实现逻辑。我们在用手机支付的时候都会选择支付方式,比如微信支付、支付宝支付,当然还有其他的比如微付充支付、连连支付等等。

工厂模式应该是我们比较常用的设计模式之一,它提供了一种创建对象的最佳方式,在创建对象时不会对调用者暴露创建逻辑,调用者只需根据自己的需求获取需要的对象,做到"拿来即用"。

说人话就是,我要什么,你就得给什么。

我们用生活中常用的支付来说明工厂模式的实现逻辑。我们在用手机支付的时候都会选择支付方式,比如微信支付、支付宝支付,当然还有其他的比如微付充支付、连连支付等等。用户选择了某一种支付方式,相应的要生成支付的对象,执行支付的方法,而这里支付对象的生成,我们交给工厂去做。

首先定义一个支付的抽象类:

抽象产品类

这个类的作用是标准化支付对象,规定好支付对象可以进行的操作,那就是下单。

然后就可以具体化我们的支付对象了,这里就以微信支付和支付宝支付为例:

微信支付产品类

支付宝支付产品类

有了具体的支付产品类,我们就可以创建工厂进行生产了,将微信支付和支付宝支付的支付对象给创建出来:

工厂类

很简单,就是根据支付类型返回支付对象。

接下来做一个小测试,模拟下用户支付,假设用户选择了微信支付:

测试方法

可以看到最终执行了微信的下单方法。

OK,大功告成,可以下班啦!

但这真的是我们要的工厂模式吗?

假如我们需要再加一种支付方式,比如连连支付,怎么整?简单啊,再加个连连支付的产品类,工厂类里再加个if判断,返回连连支付的对象,不就OK了吗?

这样是可以实现的。但如果我们在工厂类里进行扩展的时候,一不小心留个bug在里面,有可能会导致整个工厂类都不可用了,进而连带着整个支付系统就不可用了,这样显然是不合理的。实际上,这样的工厂模式违背了一个很重要的设计原则——开闭原则。开闭原则就是说,当你在扩展程序的时候,不要改动原有代码,要实现一个热插拔的效果。

这种工厂模式实际上称为简单工厂模式,是一个管理混乱、杂乱无章的小作坊,而我们需要的,是一个井然有序、收放自如的现代化工厂。

所以,这就延伸出了另一种工厂模式——工厂方法模式。

既然在原有的工厂类上进行扩展是不合理的,那索性就把工厂类分开,一个支付一个工厂类,各自工厂类生产各自的支付对象,当需要进行扩展的时候,只需新建自己的工厂类和支付产品类,而与其他的支付方式无关,这样就实现了热插拔的效果。

于是我们的代码可以演变为,保留原有的支付抽象类和支付产品类,去掉工厂类,新建一个抽象工厂类,微信支付和支付宝支付各自实现其工厂类。

抽象工厂类

支付宝支付工厂类

微信支付工厂类

这样就实现了工厂类的分离,微信支付工厂类负责生产微信支付的产品,支付宝支付工厂类负责生产支付宝支付的产品,所有工厂类各司其职,互不干扰。

测试一下:

这样,工厂方法模式就实现了,这其实也是我们平时用的最多的模式,平时所说工厂模式实际就是指的工厂方法模式。当然,工厂模式还有抽象工厂方法模式,这是比小作坊、小工厂更加高级的超级工厂模式,实现起来比较繁琐,平时也基本用不到,这里就不细说了。

责任编辑:姜华 来源: 今日头条
相关推荐

2021-03-06 22:50:58

设计模式抽象

2011-11-17 16:03:05

Java工厂模式Clojure

2020-08-21 07:23:50

工厂模式设计

2010-04-19 09:30:00

工厂模式PHP设计模式

2009-01-15 10:55:29

JavaScript设计模式抽象工厂

2022-01-12 13:33:25

工厂模式设计

2021-09-29 13:53:17

抽象工厂模式

2020-10-19 09:28:00

抽象工厂模式

2011-07-28 09:50:58

设计模式

2019-08-16 10:46:46

JavaScript工厂模式抽象工厂模式

2020-08-11 11:20:30

Typescript设计模式

2011-07-21 14:33:02

设计模式

2010-10-09 09:25:35

Python工厂模式

2024-03-06 13:19:19

工厂模式Python函数

2020-09-14 17:26:48

抽象工厂模式

2013-11-26 16:29:22

Android设计模式

2020-12-17 09:38:16

设计模式参数

2015-11-03 09:43:43

avascript设计模式工厂模式

2023-03-27 00:20:48

2024-02-20 12:09:32

模式工厂方法接口
点赞
收藏

51CTO技术栈公众号