见解: 设计模式是经验,我们需要先知道每种设计模式所解决的问题,
然后什么时候使用。
代码是思想的具体化,先有想法然后再是代码
具体设计模式选择:
1.单列模式
解决问题:一个全局使用的类频繁地创建与销毁
何时使用:当你想控制实列数目,节省系统资源的时候
2. 原型模式
解决问题:在运行期建立与删除原型
何时使用:
注意点: 深拷贝,浅拷贝 关键看对象中是否包含引用,深拷贝引用对象会重新拷贝,浅拷贝引用对象不会拷贝
3. 建造者模式
解决问题: 复杂对象的创建工作,这个复杂对象的各个部分经常变化,但将它们组合在一起的算法相对稳定
何时使用:一些基本部件不会变,而其组合经常变化
4. 工厂模式
解决问题:接口选择的问题
何时使用:明确的计划不同条件下创建不同实列
5. 抽象工厂模式
解决问题:接口选择的问题
何时使用:系统的产品多于一个的产品族,而系统只消费其中某一族的产品
6.适配器模式
解决问题:现存对象不满足新环境要求
何时使用:系统需要使用现有的类,但此类的接口不符合系统的需要
7. 桥接模式
解决问题:在有多维度会变化的情况下,用继承会造成类爆炸问题,扩展起来不灵活
何时使用:实现系统可能有多个维度变化,每一种维度都可能变化
8.过滤器模式
解决问题:使用不同的标准来过滤一组对象
何时使用: 通过逻辑运算以解耦的方式
9.组合模式
解决问题:客户程序与复杂元素的内部结构解耦
何时使用:部分整体层次结构, 忽略组合对象与单个对象的不同
10. 装饰器模式
解决问题: 通过继承扩展一个类,当扩展功能的增多,子类会很膨胀
何时使用: 在不想增加很多子类的情况下扩展类
11. 外观模式
解决问题:降低访问复杂系统的内部子系统的复杂度,简化客户端与之的接口
何时使用: 客户端不需要知道系统内部的复杂联系, 定义系统的入口
12.享元模式
解决问题:有大量对象,可能会造成内存溢出
何时使用:连接池,常量池
13.代理模式
解决问题:直接访问会给使用者或者系统结构带来很多麻烦,可在访问此对象时加上一个对
此对象的访问层。
何时使用:想在访问一个类时做一些控制
14. 责任链模式
解决问题:将请求的发送者和请求的处理者解耦
何时使用:在处理消息的时候需过滤很多道
15. 命令模式
解决问题: 无法抵御变化的紧耦合的设计
何时使用: 将行为请求者和行为实现者解耦 redis 很多的命令
16. 解释器模式
解决问题: 对于一些固定文法构建一个解释句子的解释器 :xml,word,csv 等可以解释的
何时使用: 一种特定类型的问题发生的频率足够高,就可将问题抽象为一个简单语言中的句子,
构建一个解释器,该解释器通过解释这些句子来解决问题。
17. 迭代器模式
解决问题:不同的方式来遍历整个整合对象
何时使用: 遍历一个聚合对象
18.中介者模式
解决问题:对象与对象之间存在大量的关联关系
何时使用: 多个类相互耦合,形成了网状结构
19. 备忘录模式
解决问题: 在对象之外保存对象的一个内部状态,之后可以将对象恢复到原先保存的状态
何时使用: 允许用户取消不确定或者错误的操作,恢复到他原先的状态
20.观察者模式
解决问题:一个对象状态改变给其他对象通知的问题
何时使用:一个对象的状态发生改变,所有的依赖对象将收到通知
21.状态模式
解决问题: 对象的行为依赖于它的状态,并且可以根据它的状态改变而改变它的相关行为
何时使用: 代码中包含大量与对象状态有关的条件语句
22.策略模式
解决问题: 在有多种算法相似的情况下,使用if...else 所带来的复杂和难以维护
何时使用: 一个系统有许多许多类,而区分它们的只是它们直接的行为
23. 模板模式
解决问题:一些方法通用,却在每一个子类都重新写了这一方法
何时使用: 有一些通用的方法
24. 访问者模式
解决问题: 稳定的数据结构和易变的操作耦合问题
何时使用:
25. 传输对象模式
解决问题: 客户端与服务端的数据交互
何时使用:
......
参考: https://www.runoob.com/design-pattern/design-pattern-tutorial.html