工作中常用到的设计模式
在脉脉上看过一个帖子：在工作中最常用的设计模式都有哪些？
总结一下这些出现频率高的设计模式（排名不分先后）
创建型设计模式
- 工厂模式（简单工厂、抽象工厂、工厂方法）
- 单例模式
结构型设计模式
- 装饰器模式
- 组合模式
行为型设计模式
- 责任链模式
- 策略模式
- 模板模式
注意：
- 设计模式不是解决所有问题的灵丹妙药。
- 不要试图强迫使用他们; 如果这样做的话，会发生坏事。
- 请记住，设计模式是问题的解决方案，而不是解决问题的解决方案；所以不要过分思考。
- 如果以正确的方式在正确的地方使用，他们可能是救世主; 否则他们可能会导致代码混乱。
（自己还没理解，例子以后再补）
工厂模式
Spring 使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
单例模式
Spring 中的 Bean 默认都是单例的。
装饰器模式
比如说java IO 很多都是装饰器模式
装饰器主要解决的是直接继承下因功能的不断横向扩展导致子类膨胀的问题，而是用装饰器模式后就会比直接继承显得更加灵活同时这样也就不再需要考虑子类的维护。
使用装饰器模式满足单一职责原则，你可以在自己的装饰类中完成功能逻辑的扩展，而不影响主类，同时可以按需在运行时添加和删除这部分逻辑。另外装饰器模式与继承父类重写方法，在某些时候需要按需选择，并不一定某一个就是最好。
装饰器实现的重点是对抽象类继承接口方式的使用，同时设定被继承的接口可以通过构造函数传递其实现类，由此增加扩展性并重写方法里可以实现此部分父类实现的功能。
在装饰器模式中有四个比较重要点抽象出来的点；
抽象构件角色(Component) - 定义抽象接口
具体构件角色(ConcreteComponent) - 实现抽象接口，可以是一组
装饰角色(Decorator) - 定义抽象类并继承接口中的方法，保证一致性
具体装饰角色(ConcreteDecorator) - 扩展装饰具体的实现逻辑
组合模式
策略模式
解决 在有多种算法相似的情况下 if...else 所带来的复杂和难以维护
具体的场景就是，需求可能会改变，但是外部调用的方法现在就要写好，所以就需要留下可拓展的空间
策略设计模式使用？ - nonesuccess的回答 - 知乎
在Spring中，ResourceLoader代表了加载资源的一种方式，正是策略模式的实现。
责任链模式
模板模式
模板模式 最重要的是使用抽象类定义一套行为逻辑（方法调用的先后顺序），定义一套规则 ，后面继承该类的 要按照这套逻辑 实现具体的方法
Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。
参考资料：
https://www.guanguans.cn/design-patterns-for-humans-cn
https://www.runoob.com/design-pattern/design-pattern-tutorial.html
