敖丙所在的电商公司都是怎么用工厂模式的

前言

不知道随着大家工作年限的增长，有没有一种危机感，害怕自己的技术深度开始没有提升，所以经常会去看一点框架的源码，或者报一些网课去提升自己。

最近我有一个老东家的同事跟我聊起来这个问题，说最近刚换公司了，但是自己的写的代码感觉很“low”，在codereview的时候总能被提出各种建议，几年经验了还在犯那种新手的错，写代码毫无模式和设计美感可言。

而且在想学习技术深度的时候（看一写框架的源码）总感觉只理解了表面，而没有理解里面的思想。

这里大家应该都知道我想说什么了，没错就是 设计模式，其实这也是我刚工作第一年第二年不断在思考问题，为什么要学设计模式？设计模式优点有哪些？

• 提升查看框架源码的能力
• 提升自己对复杂业务的逻辑的代码设计能力以及code能力
• 对面试以及后面的职场道路打下扎实的基础

比如我之前做电商活动的时候，我之前做会场活动的小伙伴就用了责任链+工厂+单例的模式，我只需要多个工厂类型，然后责任链传递，复用他的单例就ok了，这就是设计模式的好处，可以装X还可以造福后人。

正文

今天我就聊一下工厂模式，工厂模式在我们的电商领域的应用是非常广泛的。写之前我看了自己电脑项目的代码，确实随处可见。

工厂模式主要可以分为三大类：

• 简单工厂模式
• 工厂方法模式
• 抽象工程模式

今天我也主要围绕这三种模式来举例了解一下

简单工厂模式

工厂模式主要是用于对实现逻辑的封装，并且通过对公共的接口提供对象的实列画的服务，在我添加新的类时不需大动干戈，只要修改一点点就好。

举个例子我之前所在的电商业务怎么创建创建商品的：

在这个简单工厂里面，如果要创建活动商品1 以及活动商品2，我们要创建商品的时候只要调用简单工厂里面的创建商品方法，根据类型创建出不同的商品然后实列化返回就可以了。

简单工厂几种实现方式：

静态工厂模式

我们还是以创建商品为列子

这种方式创建看起来其实也没什么问题，根据类型创建不同的商品，但是有一个问题不知道大家发现没有？

是不是我每增加一种类型是不是我还要去修改createProduct方法的 if else？这不是违背我们的开闭原则吗？

所以这种方式不好，我们还有接来的两种：

• 使用反射机制

• 直接注册商品对象，添加一个Type类型方法，根据type类型返回自身相同类型的方法

  同样的我们还是以创建商品为列：反射实现

看上面的代码，我发现反射其实也很容易就实现了，但是在一些特定的情况下，并不适用，而且在某些特定的情况下是无法实现的，而且反射机制也会降低程序的运行效果，在对性能要求很高的场景下应该避免这种实现。

这里还有一个问题适用反射不当是容易导致线上机器出问题的，因为我们反射创建的对象属性是被SoftReference软引用的，所以当**-XX:SoftRefLRUPolicyMSPerMB** 没有设置好的话会一直让机器CPU很高。

当然他的默认值是1000，也就根据大家的情况而定吧，反正就是注意一下这点。

剩下的一种其实很反射实现很像，就是为了避免使用反射，在Map的对象中不是存的要添加的类，而是将要添加的每种类对象实列。这个我就不写demo了😂

工厂方法模式

工厂方法模式是对静态工厂模式的上的一种改进，我们的工厂类直接被抽象化，需要具体特定化的逻辑代码转移到实现抽象方法的子类中，这样我们就不要再去修改工厂类（即：不用再去做什么if else 修改）这也是我们当前比较常用的一种方式。

还是我们以创建商品为例：

看这张图 其实就是说白了再创建一个工厂，用来创建工厂类对象

接下来我们看下代码怎么来实现这个功能吧：

这里我们先创建一个抽象工厂方法

再创建一个商品工厂去继承抽象工厂方法。

当还有其他类型的时候我们只要去继承我们创建的工厂方法可以了

这个代码大家肯定都能实现出来，但是我们真正的需要学习的是前辈们的这种工厂模式的思想。把这种思想运用到我们真实的业务场景中，学以致用才能对我们有真正的提升。

我再给大家举一个列子：学以致用

假设现在leader要你做一个分享商品图片，我们知道商品的类型 有很多，比如 无SKU 商品，有SKU 商品，下单分享，邀请分享......等一系列的场景。那我们怎么去设计这个代码做到更加的易懂，易读，今后扩展性好呢？

ps：sku和spu是我们电商里面的名词，spu差不多跟item也就是商品是一个维度，一个商品item有很多sku，比如：iphone是一个商品是item 也是spu，白色的iphone 12 64G 就是一个具体的sku。

第一步我们应该都是定义一个创建分享模版

第二步我们再创建一个分享工厂根据我们的类型获取我们预先加载在Spring容器中的bean实列

最后就是定义我们不同的类型来实现分享图片。

其实我们学习设计模式就是这种思想，有了这种思想 上面提到的三点优势才能体现出来对我们今后的成长，面对复杂业务设计以及思考能力才能提升。

那么问题来了，什么时候该用工厂方法模式，而非简单工厂模式呢？

这里引用设计模式之美里面的一句话：当对象的创建逻辑比较复杂，不只是简单的 new 一下就可以，而是要组合其他类对象，做各种初始化操作的时候，我们推荐使用工厂方法模式，将复杂的创建逻辑拆分到多个工厂类中，让每个工厂类都不至于过于复杂。

而使用简单工厂模式，将所有的创建逻辑都放到一个工厂类中，会导致这个工厂类变得很复杂

抽象工厂模式

看完工厂方法模式，再理解抽象工厂模式就更加简单，因为它其实就是工厂方法的一个延伸。

工厂方法类中只有一个抽象方法，要想实现多种不同的类对象，只能去创建不同的具体工厂方法的子类来实列化，而抽象工厂 则是让一个工厂负责创建多个不同类型的对象

感觉理解起来有点绕，我们还是来画个图吧

样子可能有点丑，但是能说明问题，其实看上去可以分为以上几个部分组成：

• 抽象工厂类
• 具体工厂类
• 抽象类

抽象工厂类我个人可以理解为一个刚出厂的手机，具体抽象工厂这是认为我们每个人对这个手机壁纸自定义设置，最后抽象类我理解就是手机壁纸。

我们每个人可以自定义不同壁纸比如：动图妹妹，静图风景，小傻瓜等等。

结尾

我在几家电商公司任职期间，见过很多大佬的代码，怎么形容呢，就是各种各种设计模式，看起来真的无敌优雅，然后我们接入的时候还很方便，直接传参数就好了。

我们的业务代码中设计模式本身就是无处不在的，我在写这个文章的时候刻意翻看我们以前的项目，基本每个项目里面都能看到他们的身影，在跟我前同事聊过之后体会更深了。

其实我们想要走的更高更远，那我们学习的脚步就不能一直停下，后面我可能会针对设计模式写一个互联网公司的流程引擎，来看看我们针对更复杂的业务逻辑我们怎么运用框架去实现它。