前言
最近一直在 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://github.com/androidsta…
总结
学习一个知识点要知道是什么，为什么, 怎么办，要知其然。也要知其所以然！
阅读更多
终于，我还是下决心学 Java 后台了
来谈一下 android 中的 MVVM
金 9 银 10 的面试黄金季节，分享几个重要的面试题
身为程序员写一百万行代码的感觉
相信自己，没有做不到的，只有想不到的
在这里获得的不仅仅是技术！