前言
最近一直在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新的车子。
示例代码：
注意事项
有人把工厂模式分为： 简单工厂模式 ，工厂方法模式，抽象工厂模式，所以多出一种模式，这里简单工厂模式比较简单，实际中用的的很少，只在很简单的情况下用，没啥好说的，据说这不是一个真正的设计模式。在这里我就不做讨论了。希望 大家也不用纠结！
总结
学习一个知识点要知道**是什么，为什么,怎么办，**要知其然。也要知其所以然！
###阅读更多
相信自己，没有做不到的，只有想不到的
在这里获得的不仅仅是技术！