设计模式
2023-04-01 16:30:03 6 举报AI智能生成
设计模式整理
作者其他创作
大纲/内容
设计模式
适合创建对象较少的场景，客户端传入参数，对如何创建不用关心
缺点：工厂类职责相对较重，不利于扩展
工厂对象决定创建出哪一种产品类的实例
简单工厂
实例化推迟到子类中进行
创建对象需要大量重复代码
通过子类指定创建那个对象
类的个数容易过多
增加了系统的抽象性和理解难度
缺点
定义创建对象接口，但让实现这个接口的类决定实例化那个类
工厂方法
用于创建一系列对象
需要修改抽象工厂和所有的具体工厂
产品族扩建新产品困难
创建一个或一系列相互依赖对象的接口，无需指定具体的类
抽象工厂模式
创建一个对象需要消耗过多资源时（IO操作、访问数据库等）
工具类、帮助类（ 应用程序的日志应用、接入第三方SDK等）
频繁实例化然后销毁的对象（日志、网络访问等
使用场景
直接在应用加载时初始化，但会浪费内存
特点
饿汉式
单例的初始化操作，延迟到需要的时候才进行，但线程不安全
使用同步锁synchronized保证多线程情况下单例对象的唯一性，但很多不必要的同步会影响性能
构造方法里做限制
反射破坏单例
序列化破坏单例
注意点
懒汉式
线程安全，避免了不必要的同步，但高并发环境下小概率会有DCL失效问题
双重校验锁（DLC）
懒加载的同时保证线程安全，推荐使用
静态内部类
反射无法破坏单例
不适合大量创建单例场景
枚举式
非线程安全
使用Map存放单例对象
适合大量创建单例场景
容器式
分类
定义一个getInstance操作，允许客户访问它的唯一实例，getInstance是一个静态方法，主要负责创建自己的唯一实例。
单例模式
工厂模式
没啥可说的，几乎用不到
静态代理
被代理类
代理类
代理与被代理共同接口方法
包含
生成代理类，传入类加载器， 获取被代理类的所有的接口以及执行处理器
jdk动态代理类重新生成一个新的类，同时新的类要实现被代理类实现的所有接口
编译新生成的class文件，重新利用类加载器加载后运行
生成步骤
JDK代理的目标对象必须要实现接口，因为JDK代理是根据被代理对象的所有接口去生成新的方法
JDK代理
创建被代理的类及方法
创建一个实现接口 MethodInterceptor 的代理类，重写 intercept 方法
创建获取被代理类的方法 getInstance(Object target)
获取代理类，调用代理类方法
CGLib代理的不需要被代理对象实现任何接口，它会重写被代理类的所有方法，所以不能代理final修饰的方法或者类
CGLB代理
JDK动态代理通过反射去实现被代理对象的所有接口，所以JDK只能代理实现了接口的对象，CGLlib对代理类所有方法重写，所以private的方法都不能被代理，不是所有的方法都能被代理
JDK动态代理跟CGLib代理都是在运行期生成新的字节码，但是CGLib实现更为复杂，用的是ASM框架，生成代理类的效率比JDK低
JDK动态代理是通过反射机制去查询所有被代理对象的接口，CGLib代理是通过FastClass机制直接调用方法，所有执行效率，CGLib比JDK代理要高
JDK动态代理跟CGLib动态代理的区别
动态代理
代理模式
客户端
抽象原型
具体原型
类初始化消耗资源过多
NEW对象要复杂的过程
构造函数比较复杂
循环中大量对象
应用场景
仅克隆基本类型的变量，而不克隆引用类型的变量
浅克隆
既复制基本类型的变量，也复制引用类型变量
序列化实现
实现
深克隆
浅克隆和深克隆
深克隆破坏单例，在应用中可以禁止深克隆或者重写clone方法返回还是单例
克隆破坏单例
ArrayList
在源码中的运用
性能优良，比NEW一个对象性能上提升很多
深克隆可以保存对象状态
优点
需要每个类配置一个克隆方法
克隆方法位于类的内部，对已有类进行改造会修改代码
原型模式
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示
介绍
产品类
抽象建造者
具体建造者
指挥者
代替setter方法构建对象，链式调用代码美观且简洁
指挥者中，buildPartA()、buildPartB()、buildPartC()的顺序不同，可能会产生不同的结果
用不同的ConcreteBuilder构建对象，会产生不同的结果
创建的过程中的分步装配具有很大灵活性。如果一个对象灵活性要求比较高的话可以考虑使用此模式，否则可以考虑其它创建型模式
封装性好
扩展性好
产生过多抽象建造者对象
产品内部发生变化，建造者都要修改，成本较大
忽略掉指挥角色。直接使用抽象建造者来对对象进行组装。具体使用时在每个组件装配的过程中都返回自身
链式调用
建造者模式
把一个类的接口变成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作
类适配
对象适配
接口适配
Target（目标角色）
Adaptee（被适配角色
Adapter（适配器角色）
系统需要使用现有的类，而此类的接口不符合系统的需求，即接口不兼容
需要一个统一的输出接口，而输入端的类型不可预知
提供类的透明性和复用
目标类和适配器类解耦，提供程序的扩展性
可能会增加复杂性
降低代码可读性
适配器模式
将抽象部分与实现部分分离，使它们都可以独立的变化
Abstraction（抽象化角色
RefinedAbstraction（具体抽象化角色
Implementor（实现化角色）
ConcreteImplementor（具体实现化角色
一个类存在两个独立变化的维度，且这两个维度都需要进行扩展
不希望使用继承或因为多层次继承导致系统类的个数急剧增加
任何多维度变化类之间的耦合都可以使用桥接模式来实现解耦
抽离抽象和实体部分
符合开闭原则
符合复用原则
增加了系统理解和设计难度
正确识别系统中独立变化的维度
桥接模式
允许对象实现与继承相同的代码重用，负责任务的调用和分配任务
抽象任务角色（Task）
委派者角色(Delegate
具体任务角色
双亲委派
将大型任务细化，提高任务效率
多重委派容易紊乱
委派模式
0 条评论
回复 删除
下一页
