设计模式心得(一) 简单工厂模式

来源:互联网 发布:ubuntu14.04安装mysql 编辑:程序博客网 时间:2024/03/29 10:11

一直以来想要整理一下设计模式的心得,总有这样那样的事情耽误,现在抽点写一下吧。其实跨度这么长时间,自己的理解也变化了不少。当然纯属个人的理解,有不对的地方还是多包涵。


简单工厂模式应该是每一个学习设计模式的第一站,为什么这么说呢,这就要从这个模式的使用说起。简单工厂模式不属于23种设计模式之一,是工厂模式家族中最简单实用的模式,没有什么特殊的处理,根据传入的参数,产出一个对应的“产品”,但是,它却是面向对象编程的一个很好的体现。在这个模式里面,我们不再需要关心传入传出,只需要单纯的维护工厂即可。

在我的感觉中,简单工厂模式,就是将一条条复杂的高速通道给封装到一个盒子里面,用户再也不用关心我要从哪个入口进入哪个出口出来,盒子上只留有一个门,凭“卡”进入,你的“卡”信息决定了为你安排的线路,不需要再在入口和出口的位置纠结了,所有的纠结扔给工程师吧,只要你的盒子路线划分好(即工厂类内部逻辑清晰),过来的车(传入的请求),自然而然的会到达预定的目的地(返回正确的结果)。而当路线满足不了需求的时候(程序的需求变更),你只需要修改盒子内部结构(修改工厂类内部逻辑),以及告诉打卡机(增加一个判断条件)即可。


如果这么说不是很好理解,我们用下面的一个小例子来说明:计算器的设计,按照我们以往的思路,计算器肯定有一个类,然后里面有加减乘除的方法和传入的值,使用的时候我们只需要实例化出这个类,然后就可以使用里面的方法,在没有需求变更的时候,这样其实也是挺方便的。但是某一天,我们的计算器需要升级了,添加A方法B方法...,这时候你也可以时候我们可以直接修改计算器这个类,但是这时候你没有发现,其实你的业务和逻辑已经混在一起了,我们已经失去了计算器(因为“计算器”!=“会各种算法的机器”),同时当你把过多的逻辑和业务混淆在一起后,你的逻辑算法也将失去价值,它再也不能为你提供更多的帮助,你也将会陷入一个不断复制修改的过程,而这个过程还可以会引发更恐怖的事情,你可能会在某次修改的时候漏过某些方法,这可是一个灾难。


反过来说,我们的简单工厂要做的正是避免这种情况,我们在生产计算器的时候会让它继承一个运算类,这个是干嘛用呢?这个是告诉大家,计算器是计算器,它本身没有任何功能,之所有有了那些功能,是因为它里面安装了这种可以运算的功能,而这个运算类就是我们核心的运算规则,在生产一些高级的计算器的时候,它可能会有各种各样其他的运算功能,这个不要紧我们只需要在原本的运算类基础上向下派生子类,同时实现一些高级的接口即可,这样,我们的业务就算是与逻辑脱离开来,对于逻辑的维护不会影响到业务的处理,同时对于业务的修改也不会造成逻辑的混乱。


同时,工厂的使用会大大的提高程序的复用,尽量的避免了程序的复制,也就尽可能的避免了升级过程中漏掉一些方法的修改。


最后说一下,编程时一门技术,更是一门艺术。

原创粉丝点击