在讲解简单工厂模式之前,有必要先了解一下OO的一些原则
1.OCP(开闭原则,Open-Closed Principle):一个软件的实体应当对扩展开放,对修改关闭。也就是说,对于一个已有的软件,如果需要扩展,应当在不需修改
已有代码的基础上进行。
2.DIP(依赖倒转原则,Dependence Inversion Principle):要针对接口编程,不要针对实现编程。简单点说,对于不同层次的编程,高层次暴露给低层次
的应当只是接口,而不是它的具体类。
3.LoD(迪米特法则,Law of Demeter):只与你直接的朋友通信,而避免和陌生人通信。
设计模式,相信不少人或多或少的在开发和学习过程中都会有接触到的,其实我接触它的时间是挺早,但是具体的了解其中的意义,却是一脸茫然。
由于工作的原因,针对这块的需求越来越多,如何更好地进行代i码设计,做好 扩展、复用、灵活高的程序,成为了一个摆在我面前的大山,我不知道如何去使用它,这其实也是我本能的对于设计模式的一种恐惧心里,从内心感觉它是很难的一件事情,这些事情困扰着我,当然当你压力过大的时候,你或许会崩溃 或许会战胜自己 的恐惧 迎难而上,而我在崩溃之前选择了后者,至此 我要向设计模式发起猛烈的进攻,我可以掌控设计模式,我可以驾驭它,相信自己,你也可以,跟着我的脚步,走进设计模式 的世界中来的,好啦,开车啦 !!
一、工厂模式之简单工厂
这个模式我相信 是使用最多的,我们可能在实际开发中已经使用到了,但是我们却不知道它有一个不错的名称---简单工厂模式
学习知识之前 我们都应该问一下自己,更甚一点说,搞清楚状况小子,别开小差,集中精力。let's go
学的是什么知识?简单工厂模式,可以是你的代码更加容易维护、低耦合、对象集中管理
它解决了什么问题?解决了如何更好地创建和维护对象,简单说就是封装对象的创建,当对象更换时,可以很方便的进行修改
怎么样学习它?学习方法,从定义、示例、最佳实践中去学习
怎么样算是学会了?找到应用场景,并成功使用上模式
那么我将以现在最流行的 章丘铁锅的 从曝光后的疯狂扩张 到 乱象丛生的结局,来说一下这个简单工厂,此举例仅是为了理解工厂模式,
话说 章丘铁锅在没有被曝光之前 那可能是全国众多做铁锅的一家,没有什么其他特别之处,
这个做铁锅的都是以个人(家庭)为单位,进行做生意的,竞争可能还是很激烈吧,
自从曝光之后 订单疯狂增长,这样问题就来了,面对这么多的订单,一个是时间一个是质量还有如何能做到符合客户的要求,应该如何保证,结果是在庞大的利益面前,铁锅的质量直线下降,导致订单量的极速回缩,买家投诉暴增,一个章丘铁锅从此跌下神坛,
我们不难总结出问题的原因,没有统一的管理,各种生产良莠不齐,导致问题的根源,我们无法去很好的保证这些个人做的铁锅的质量是否达到标准,此时铁锅就是我们要管理的对象,因为对它没有进行统一管理,导致出现问题,不能及时解决,导致了一个彻彻底底的失败,没有回旋的余地,这个事件究竟带给我们什么启示呢,不妨细细的想一下
1、没有统一管理
2、沟通没有到位,可能导致做的和客户要求的不一致
3、利益至上,没有把握好质量关
其实就是类似这种模式,每个对象都是自己进行管理,这样做的缺点就是客户端严重依赖了具体对象,这样就违反了OCP选择,对扩展开放 对修改关闭,这样每次都会new对象,完全把具体对象暴露给客户端,当然这里也违反了.DIP,针对接口,不针对实现。
从上面的叙述中我们是否想到了有这么一个解决方案可以很好的解决此问题-----工厂应运而生
工厂屏蔽了创建细节,它保证你能得到你所需要的铁锅,你不需要知道如何去创建这个铁锅,你只要对工厂说 我需要一个炒菜的锅 那么工厂就会给你这样的一个锅,
那么它的形式是什么样的,让我们以上面示例的代码形式去提现简单工厂模式
1.定义锅的接口,方法work 表示该锅的具体用途(炒菜、煎炸)
2、分别实现炒菜和煎炸的锅
3、重点来了,如何去创建具体的锅呢,这时候简单工厂模式提现了它存在的意义,如下所示
通过这种方式,很方便的创建所需要的具体的对象,通过不同的类型去选择具体的实现对象,
这样的模式在实际的开发中是经常见到的,在我们开发的项目中,很多地方都使用到了简单工厂模式,
当然这个模式已经很好了,但是他却是违反了OCP原则,那么在此之上是不是还有相关的工厂模式去解决这样的问题,答案是有的,那就是工厂方法模式,工厂方法模式我们将在下一节讲一讲