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

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

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

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

抽象产品类

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

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

微信支付产品类

支付宝支付产品类

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

工厂类

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

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

测试方法

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

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

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

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

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

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

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

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

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

抽象工厂类

支付宝支付工厂类

微信支付工厂类

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

测试一下：

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

网页题目：设计模式之工厂模式—要的是工厂而不是作坊
本文链接：http://www.shufengxianlan.com/qtweb/news33/454283.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联