不知道随着大家工作年限的增长,有没有一种危机感,害怕自己的技术深度开始没有提升,所以经常会去看一点框架的源码,或者报一些网课去提升自己。 最近我有一个老东家的同事跟我聊起来这个问题,说最近刚换公司了,但是自己的写的代码感觉很“low”,在codereview的时候总能被提出各种建议,几年经验了还在犯那种新手的错,写代码毫无模式和设计美感可言。 而且在想学习技术深度的时候(看一写框架的源码)总感觉只理解了表面,而没有理解里面的思想。 这里大家应该都知道我想说什么了,没错就是
比如我之前做电商活动的时候,我之前做会场活动的小伙伴就用了责任链+工厂+单例的模式,我只需要多个工厂类型,然后责任链传递,复用他的单例就ok了,这就是设计模式的好处,可以装X还可以造福后人。 正文今天我就聊一下 工厂模式主要可以分为三大类:
今天我也主要围绕这三种模式来举例了解一下 简单工厂模式工厂模式主要是用于对实现逻辑的封装,并且通过对公共的接口提供对象的实列画的服务,在我添加新的类时不需大动干戈,只要修改一点点就好。 举个例子我之前所在的电商业务怎么创建创建商品的: 在这个简单工厂里面,如果要创建活动商品1 以及活动商品2,我们要创建商品的时候只要调用简单工厂里面的创建商品方法,根据类型创建出不同的商品然后实列化返回就可以了。 简单工厂几种实现方式: 静态工厂模式我们还是以创建商品为列子 这种方式创建看起来其实也没什么问题,根据类型创建不同的商品,但是有一个问题不知道大家发现没有? 是不是我每增加一种 所以这种方式不好,我们还有接来的两种:
看上面的代码,我发现反射其实也很容易就实现了,但是在一些特定的情况下,并不适用,而且在某些特定的情况下是无法实现的,而且反射机制也会降低程序的运行效果,在对性能要求很高的场景下应该避免这种实现。
剩下的一种其实很反射实现很像,就是为了避免使用反射,在Map的对象中不是存的要添加的类,而是将要添加的每种类对象实列。这个我就不写demo了😂 工厂方法模式工厂方法模式是对静态工厂模式的上的一种改进,我们的工厂类直接被抽象化,需要具体特定化的逻辑代码转移到实现抽象方法的子类中,这样我们就不要再去修改工厂类(即:不用再去做什么if else 修改)这也是我们当前比较常用的一种方式。 还是我们以创建商品为例: 看这张图 其实就是说白了再创建一个工厂,用来创建工厂类对象 接下来我们看下代码怎么来实现这个功能吧: 这里我们先创建一个抽象工厂方法 再创建一个商品工厂去继承抽象工厂方法。 当还有其他类型的时候我们只要去继承我们创建的工厂方法可以了
我再给大家举一个列子: 假设现在leader要你做一个分享商品图片,我们知道商品的类型 有很多,比如 无SKU 商品,有SKU 商品,下单分享,邀请分享......等一系列的场景。那我们怎么去设计这个代码做到更加的易懂,易读,今后扩展性好呢?
第一步我们应该都是定义一个创建分享模版 第二步我们再创建一个分享工厂根据我们的类型获取我们预先加载在Spring容器中的bean实列 最后就是定义我们不同的类型来实现分享图片。
那么问题来了,什么时候该用工厂方法模式,而非简单工厂模式呢?
抽象工厂模式看完工厂方法模式,再理解抽象工厂模式就更加简单,因为它其实就是工厂方法的一个延伸。
感觉理解起来有点绕,我们还是来画个图吧 样子可能有点丑,但是能说明问题,其实看上去可以分为以上几个部分组成:
抽象工厂类我个人可以理解为一个刚出厂的手机,具体抽象工厂这是认为我们每个人对这个手机壁纸自定义设置,最后抽象类我理解就是手机壁纸。 我们每个人可以自定义不同壁纸比如:动图妹妹,静图风景,小傻瓜等等。 结尾我在几家电商公司任职期间,见过很多大佬的代码,怎么形容呢,就是各种各种设计模式,看起来真的无敌优雅,然后我们接入的时候还很方便,直接传参数就好了。 我们的业务代码中设计模式本身就是无处不在的,我在写这个文章的时候刻意翻看我们以前的项目,基本每个项目里面都能看到他们的身影,在跟我前同事聊过之后体会更深了。 其实我们想要走的更高更远,那我们学习的脚步就不能一直停下,后面我可能会针对设计模式写一个互联网公司的流程引擎,来看看我们针对更复杂的业务逻辑我们怎么运用框架去实现它。 |
|