最近一直在Java方向奋斗 《终于,我还是下决心学Java后台了》 ,今天抽空开始学习Java的设计模式了 。计划有时间就去学习,你这么有时间,还不来一起上车吗?
之所以要学习Java模式,是因为面试的时候有时间回答的不是太完整,面试过后才想起来如何回答。所以,我说了: 只有总结才是王道,只有总结才能提高
其实正规的来说Java其实是23中设计模式,不过网上也有说是24种或者是26中的!设计模式不过是前人对代码的一种封装。用专业的话来讲:设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结
工厂模式是创建型模式之一,又称为静态工厂方法模式!
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新的车子。
有人把工厂模式分为: 简单工厂模式 ,工厂方法模式,抽象工厂模式 ,所以多出一种模式,这里简单工厂模式比较简单,实际中用的的很少,只在很简单的情况下用,没啥好说的,据说这不是一个真正的设计模式。在这里我就不做讨论了。希望 大家也不用纠结!
项目地址:
github.com/androidstar…