一、创建模式
1.工厂方法:一个工厂通过方法创建多个产品
2.抽象工厂方法:多个工厂创建多个产品族
3.建造者模式:分解构建步骤,分步构建
4.原型模式:一个对象需要多次修改部分值,利用克隆实现
5.单例模式:只要一个实例,减少系统开销
二、结构模式
6.适配器模式:重构时,不修改已有模块,增加适配器来协调2个模块工作
7.桥接模式:开发时,jdbc,需要增加桥对象,可切换对接对象,实现不同桥功能
8.组合模式:开发时,组织机构,文档结构
9.装饰器模式:重构时,不修改已有模块,对已有模块功能进行扩展
10.外观模式:开发重构
11.享元模式:开发时,创建对象池,共享对象,减少系统开销
12.代理模式:重构时,代理目标对象执行,主要是控制目标对象方式是否执行
三、行为模式
13.责任链模式:审批流
14.命令模式:浏览器的请求方式,封装请求,分离请求者与接收者
15.解释器模式:表达式解析
16.迭代器模式:迭代器
17.备忘录模式:ghost,保存当前对象状态,用于恢复
18.中介者模式:QQ,多个构件间通信的枢纽
19.观察者模式:消息通知,广播机制,通过注册接收者,观察者发消息给多个接收者
20.状态模式:针对对象切换,将状态封装成对象,通过切换状态来用不同状态对象实现相同方法。
21.策略模式:针对方法切换,对某个方法进行切换,实现不同的实现方式。
22.模板方法模式:sitmesh,tiles,freemarker就是类似装饰模式,只不过如同模板一般,只需要关注变动的地方即可
23.访问者模式:利用多态特性
————————————————
原文链接:https://blog.csdn.net/kimheesunliulu/article/details/99693009
1.单例模式:
应用场景
- 整个程序的运行中只允许有一个类的实例
- 频繁实例化然后销毁的对象
- 创建对象时耗时过多或者耗资源过多,但又经常用到的对象
- 封装一些常用的工具类
- 保存一些共享数据在内存中,其他类随时可以读取
优点
1.实现了整个程序对唯一实例访问的控制。
2.因为单例要求程序只能有一个对象,所以对于那些需要频繁创建和销毁的对象来说可以提高系统的性能,并且可以节省内存空间。
3.可以全局访问。
4.允许可变数目的实例。
缺点
1. 不适用于变化频繁的对象。
2.符合的场景有限。
3.如果实例化的对象长时间不被利用,系统会认为该对象是垃圾而被回收,可能会导致对象状态的丢失
4.可扩展性较差。
UML图(转自https://blog.csdn.net/It_sharp/article/details/82147111)
2.动态代理
应用场景
- 统计每个 api 的请求耗时
- 统一的日志输出
- 校验被调用的 api 是否已经登录和权限鉴定
- Spring的 AOP 功能模块就是采用动态代理的机制来实现切面编程
优点
缺点
UML图
3.工厂模式
应用场景
工厂方法模式应用场景:
1.类不知道自己要创建哪一个对象
2.类用它的子类来指定创建哪个对象
3.客户需要清楚创建了哪一个对象
4.一个抽象产品类,可以派生出多个具体产品类。
5.一个抽象工厂类,可以派生出多个具体工厂类。
6.每个具体工厂类只能创建一个具体产品类的实例。
抽象工厂模式:
1.系统需要屏蔽有关对象如何创建、如何组织和如何表示
2.系统需要由关联的多个对象来构成
3.有关联的多个对象需要一起应用并且他们的约束是强迫的(不可分离)
4.你提供一组对象而不显示它们的实现过程,只显示它们的接口。
5.多个抽象产品类,每个抽象产品类可以派生出多个具体产品类。
6.一个抽象工厂类,可以派生出多个具体工厂类。
7.每个具体工厂类可以创建多个具体产品类的实例。
区别:
工厂方法模式只有一个抽象产品类,而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例,而抽象工厂模式可以创建多个。
优点(转自https://blog.csdn.net/Fly_as_tadpole/article/details/88326807)
简单工厂模式:工厂类含有必要的判断逻辑,可以决定在什么时候创建哪一个产品类的实例,客户端可以免除直接创建产品对象的责任,而仅仅"消费"产品。简单工厂模式通过这种做法实现了对责任的分割。简单工厂模式能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。通过它,外界可以从直接创建具体产品对象的尴尬局面中摆脱出来。外界与具体类隔离开来,偶合性低。明确区分了各自的职责和权力,有利于整个软件体系结构的优化。
工厂方法模式:工厂方法模式是为了克服简单工厂模式的缺点(主要是为了满足OCP)而设计出来的。简单工厂模式的工厂类随着产品类的增加需要增加很多方法(或代码),而工厂方法模式每个具体工厂类只完成单一任务,代码简洁。工厂方法模式完全满足OCP,即它有非常良好的扩展性。
抽象工厂模式:抽象工厂模式主要在于应对“新系列”的需求变化。分离了具体的类,抽象工厂模式帮助你控制一个应用创建的对象的类,因为一个工厂封装创建产品对象的责任和过程。它将客户和类的实现分离,客户通过他们的抽象接口操纵实例,产品的类名也在具体工厂的实现中被分离,它们不出现在客户代码中。它使得易于交换产品系列。一个具体工厂类在一个应用中仅出现一次——即在它初始化的时候。这使得改变一个应用的具体工厂变得很容易。它只需改变具体的工厂即可使用不同的产品配置,这是因为一个抽象工厂创建了一个完整的产品系列,所以整个产品系列会立刻改变。它有利于产品的一致性。当一个系列的产品对象被设计成一起工作时,一个应用一次只能使用同一个系列中的对象,这一点很重要,而抽象工厂很容易实现这一点。抽象工厂模式有助于这样的团队的分工,降低了模块间的耦合性,提高了团队开发效率。
缺点(转自https://blog.csdn.net/Fly_as_tadpole/article/details/88326807)
简单工厂模式:当产品有复杂的多层等级结构时,工厂类只有自己,以不变应万变,就是模式的缺点。因为工厂类集中了所有产品创建逻辑,一旦增加产品或者删除产品,整个系统都要受到影响。系统扩展困难,一旦添加新产品就不得不修改工厂逻辑,有可能造成工厂逻辑过于复杂,违背了"开放--封闭"原则(OCP).另外,简单工厂模式通常使用静态工厂方法,这使得无法由子类继承,造成工厂角色无法形成基于继承的等级结构。
工厂方法模式:假如某个具体产品类需要进行一定的修改,很可能需要修改对应的工厂类。当同时需要修改多个产品类的时候,对工厂类的修改会变得相当麻烦。比如说,每增加一个产品,相应的也要增加一个子工厂,会加大了额外的开发量。
抽象工厂模式:抽象工厂模式在于难于应付“新对象”的需求变动。难以支持新种类的产品。难以扩展抽象工厂以生产新种类的产品。这是因为抽象工厂几乎确定了可以被创建的产品集合,支持新种类的产品就需要扩展该工厂接口,这将涉及抽象工厂类及其所有子类的改变。
UML图
4.责任链模式
应用场景
优点
缺点
UML图