前言
最近一直在Java方向奋斗《终于,我还是下决心学Java后台了》,今天抽空开始学习Java的设计模式了
。计划有时间就去学习,你这么有时间,还不来一起上车吗?
之所以要学习Java模式,是因为面试的时候有时间回答的不是太完整,面试过后才想起来如何回答。所以,我说了: 只有总结才是王道,只有总结才能提高
设计模式
其实正规的来说Java其实是23中设计模式,不过网上也有说是24种或者是26中的!设计模式不过是前人对代码的一种封装。用专业的话来讲:设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结
创建型模式,共五种:
1.工厂方法模式、
2.抽象工厂模式、
3.单例模式、
4.建造者模式、
5.原型模式。
结构型模式,共七种:
6.适配器模式、
7.装饰器模式、
8.代理模式、
9.外观模式、
10.桥接模式、
11.组合模式、
12.享元模式。
行为型模式,共十一种:
13.策略模式、
14.模板方法模式、
15.观察者模式、
16.迭代子模式、
17.责任链模式、
18.命令模式、
19.备忘录模式、
20.状态模式、
21.访问者模式、
22.中介者模式、
23.解释器模式。
今日重点:工厂方法模式
工厂模式是创建型模式之一,又称为静态工厂方法模式!
优点:
1.良好的封装性,代码结构清晰。一个对象创建是有条件约束的,如一个调用者需要一个具体的产品对象,只要知道这个产品的类名(或约束字符串)就可以了,不用知道创建对象的艰辛过程,减少模块间的耦合。
2.工厂方法模式的扩展性非常优秀。在增加产品类的情况下,只要适当地修改具体的工厂类或扩展一个工厂类,就可以完成“拥抱变化”。例如在我们的例子中,需要增加一个棕色人种,则只需要增加一个BrownHuman类,工厂类不用任何修改就可完成系统扩展。
3.屏蔽产品类。这一特点非常重要,产品类的实现如何变化,调用者都不需要关心,它只需要关心产品的接口,只要接口保持不表,系统中的上层模块就不要发生变化,因为产品类的实例化工作是由工厂类负责,一个产品对象具体由哪一个产品生成是由工厂类决定的。在数据库开发中,大家应该能够深刻体会到工厂方法模式的好处:如果使用JDBC连接数据库,数据库从MySql切换到Oracle,需要改动地方就是切换一下驱动名称(前提条件是SQL语句是标准语句),其他的都不需要修改,这是工厂方法模式灵活性的一个直接案例。
4.工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类,其他的实现类都不用关心,符合迪米特原则,我不需要的就不要去交流;也符合依赖倒转原则,只依赖产品类的抽象;当然也符合里氏替换原则,使用产品子类替换产品父类,没问题!
缺点:
每次增加一个产品时,都需要增加一个具体类和对象实现工厂,是的系统中类的个数成倍增加,在一定程度上增加了系统的复杂度,同时也增加了系统具体类的依赖。这并不是什么好事。
用途:
第一种情况是对于某个产品,调用者清楚地知道应该使用哪个具体工厂服务,实例化该具体工厂,生产出具体的产品来。Java Collection中的iterator() 方法即属于这种情况。
第二种情况,只是需要一种产品,而不想知道也不需要知道究竟是哪个工厂为生产的,即最终选用哪个具体工厂的决定权在生产者一方,它们根据当前系统的情况来实例化一个具体的工厂返回给使用者,而这个决策过程这对于使用者来说是透明的。
典型例子:
车子继承vehicle(车)类,有小汽车卡,公交车bus等,车子工厂实现工厂接口,工厂接口有抽象方法vehicle produce vehicle(String type)方法,车子工厂中实现工厂方法vehicle produce vehicle(String Type),方法中根据需要new新的车子。
示例代码:
测试类:
注意事项
有人把工厂模式分为: 简单工厂模式 ,工厂方法模式,抽象工厂模式,所以多出一种模式,这里简单工厂模式比较简单,实际中用的的很少,只在很简单的情况下用,没啥好说的,据说这不是一个真正的设计模式。在这里我就不做讨论了。希望 大家也不用纠结!
项目地址:
总结
学习一个知识点要知道是什么,为什么,怎么办,要知其然。也要知其所以然!
原文出处:https://www.cnblogs.com/gooder2-android/p/9583767.html