设计模式
2018-08-28 16:40:34 3 举报AI智能生成
设计模式总结，主要是个人在学习设计模式中一个总结的方法，方便以后随时根据该总结进行实际运用。
作者其他创作
大纲/内容
分类
创建型模式
单例模式
要点
创建方式
简单模式
饿汉模式
懒汉模式
内部类模式
总结
优点
提供了对唯一实例的受控访问
节约系统资源，减少对象的创建和销毁，有利于提高系统性能
缺点
没有抽象层，难以扩展
单一类，导致职责过重，违反单一职责原则
可能会被垃圾回收器释放，导致利用的时候重新实例化
适用场景
系统要求只有一个实例
只允许使用一个公共访问点
简单工厂模式
简述
工厂角色
抽象产品角色
具体产品角色
模式结构
抽象产品类
具体产品类
工厂类
总结
优点
实现了创建对象和使用的分离
客户端无需知道创建对象的类名，只需知道参数即可
若引入配置文件，通过反射机制还能更换具体产品类的使用
缺点
工厂类职责过重，一旦出错，影响整体流程
增加了系统类的个数，提高了系统的复杂度和理解难度
新增产品时导致系统扩展困难
适用场景
适用对象较少，逻辑偏于简单的业务
客户端只关注传入的参数，不关心创建对象的细节
工厂方法模式
总结
优点
向客户隐藏具体产品类的实例化细节
实现工厂角色和产品角色的多态性设计
新增产品只需添加一个具体工厂和具体产品即可，
缺点
系统的类的个数较多，
引入了抽象层、DOM、反射等技术，
适用场景
客户端不知道其所需要的对象的类
抽象工厂类通过其子类来指定哪个对象
模式结构
抽象产品
具体产品
抽象工厂
具体工厂
简述
定义一个用于创建对象的接口，让子类决定将哪一个类实例化
抽象工厂类可以是接口，也可以是抽象类或者具体类
抽象工厂模式
简述
定义
产品等级结构
产品族结构
模式结构
抽象工厂
具体工厂
抽象产品
具体产品
总结
优点
隐藏了具体类的生成细节
新增产品族时符合开闭原则
缺点
新增产品等级结构不满足开闭原则，且修改麻烦
适用场景
系统不依赖产品类对象的创建细节
系统有多个产品族，且每次只使用其中的一个产品族
产品等级结构稳定，不经常发生变化
原型模式
简述
使用原型实例指定创建对象的种类，并且通过克隆这些原型创建新的对象
通过克隆方法创建的对象是一个全新的对象，在内存中有新的地址
模式结构
抽象原型类
具体原型类
客户类
总结
优点
使用原型模式可以简化复杂对象的创建过程
扩展性比较好
原型模式通过克隆方法复制对象，简化了创建结构
可以使用深克隆的方式来保存对象的状态
缺点
需要为每一个类提供一个克隆方法
实现深克隆时，需要为每一层对象编写复杂的代码
适用场景
创建新对象的成功较大时
需要避免使用分层次的工厂类创建分层次对象时
建造者模式
简述
将一个复杂对象的构建与表现进行分离，使得同样的构建过程可以创建不同的表示
模式结构
抽象建造者
负责声明产品对象的接口或抽象类
提供创建部件方法和返回产品对象的方法
具体建造者
实现抽象建造者的接口。
产品角色
声明产品部件的对象
指挥者
负责复杂对象的部件生成顺序，完成复杂对象的建造
总结
优点
将产品本身与产品过程解耦
每个具体建造者相互独立，符合开闭原则
将复杂产品的创建步骤细化，使得创建过程更加清晰
缺点
只适用于产品具有普遍性，差异不大
假设产品内部结构复杂， 则增加了系统的理解程度，导致系统异常庞大
适用场景
产品对象具有统一的复杂内部结构
产品对象的属性相互依赖，且需指定生成顺序
结构型模式
适配器模式
简述
将一个接口转换成客户希望的另外一个接口，使接口不兼容的那些类可以一起工作
类适配器模式
适配器和适配者之间的关系是继承关系
对象适配器模式
适配器和适配者之间的关系是关联关系
模式结构
目标抽象类
适配器类
适配者类
总结
优点
通过引入适配器来重用现有的适配者类，无需修改原有代码
增加了类的透明性和复用性
缺点
由于不支持多重继承，一次只能适配一个适配者类
适配者类不能为最终类
目标抽象类只能为接口
总结
系统需要按照实际业务复用以前的类
创建一个重复的类用于连接一些没有太大关联的类
桥接模式
简述
将抽象部分和其实现部分分离，使他们能够独立地变化
模式结构
抽象类
定义抽象类的接口
扩充抽象类
具体类，扩充抽象类的接口，并且实现Abstration的抽象方法
实现类接口
定义实现类的接口
具体实现类
在不同的具体实现类中实现Implementor接口
总结
优点
分离抽象接口及其实现部分
取代了多层继承方式
提高了系统的可扩展性
缺点
增加系统的理解和设计难度
要求能正确识别出系统中独立变化的维度
适用场景
需要将两个层次的继承关系转为抽象层的关联关系
需要对抽象类角色和实现类角色进行动态耦合
组合模式
简述
组合多个对象形成树形结构以表示具有“整体-部分”关系的层次结构
模式结构
抽象构件
包含所有子类共有行为的声明和实现
叶子构件
表示叶子节点的对象
容器构件
表示容器节点对象
总结
优点
它可以很清楚地定义分层次的复杂对象
客户端只关心使用的对象，不必关心具体的实现方法
增加新的容器和叶子构件很方便，符合开闭原则
通过叶子和容器的递归组合，可形成复杂的树形结构
缺点
在增加新的构件时，对构件类型的限定比较困难，只能通过运行时类型检查来实现
适用场景
用来处理一个树形结构的业务场景
能够清晰地区分出叶子构件和容器构件的系统
装饰模式
简述
即动态地给一个对象增加一些额外的职责。
模式结构
抽象构件
它是具体构件和抽象装饰类的共同父类，声明在具体构件中实现的业务方法
具体构件
用来实现在抽象构件中声明的方法
抽象装饰类
也是抽象构件的子类，用来给具体构件增加职责
具体装饰类
负责向构件增加新的职责
总结
优点
对于扩展一个对象的功能，装饰模式比继承更加灵活【1】
通过配置文件可以在运行时选中不同的具体装饰类，从而实现不同的行为【2】
可以对一个对象进行多次装饰，从而创建出很多不同行为的组合【3】
新增具体构件类和装饰类不影响原有类库代码，符合开闭原则【4】
缺点
使用装饰模式会产生很多小对象，导致占用更多的系统资源。【1】
容易产品多次装饰，会导致系统排错困难【2】
适用场景
在不影响其他对象的情况下，以动态透明的方式给单个对象添加职责【1】
当不能采用继承方式或者采用继承方式导致系统扩展困难时，可以使用装饰模式【2】
外观模式
简述
是指通过一个统一的外观角色为紫铜提供一个一致的入口
模式结构
外观角色
将客户端发来的请求委派到响应的子系统中去，传递给相应的子系统对象去处理
子系统角色
用来处理外观角色传过来的请求
总结
优点
屏蔽子系统组件，使客户端调用更加简单
实现了子系统跟客户端的松耦合关系
提供了一个统一访问子系统的入口
缺点
如果对客户端访问子系统类做太多的限制则会减少可变性和灵活性
适用场景
客户端需要访问一系列复杂的子系统的情况
客户端与多个子系统之间存在很大依赖性
享元模式
简述
运用共享技术有效地支持大量细粒度对象的复用。
模式结构
抽象享元类
声明具体享元类公共的方法，向外界提供享元对象的内部数据和提供设置外部数据的方法
具体享元类
通常结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象
非共享具体享元类
享元工厂类
用于创建并管理享元对象，存在则返回，不存在则创建
总结
代理模式
简述
给某一个对象提供代理，并由代理对象控制对原对象的引用
模式结构
抽象主题角色
声明了抽象主题和真实主题共同的接口
代理主题角色
包含了真实主题的所有引用，在代理主题提供一个与真实主题角色相同的接口
真实主题角色
定义代理角色所代表的真实对象，并在真实主题角色中实现真实的业务操作
总结
分类
远程代理||保护代理||缓冲代理||智能引用代理||
优点
能够协调调用者和被调用者，降低系统的耦合度
可以针对抽象主题角色编程，增加和修改代理类无需修改源代码，符合开闭原则
缺点
由于客户端和真实主题中增加了代理对象，可能会导致请求的处理速度变慢
实现代理可能需要额外的工作，而且有些代理的实现非常复杂。
适用场景
当客户端需要访问远程主机中的对象时，就需要一个远程代理
当需要一个消耗资源较少的对象来代表一个消耗资源较多的对象时，便可以使用虚拟代理
当需要控制一个对象的访问，为不同用户提供不同级别的访问权限时，可以使用保护代理
当需要为一个被频繁访问的操作结果提供一个临时储存空间，以供多个对象共享这些结果时，可以使用缓冲代理
当需要为一个对象的访问提供一些额外的操作时，可以使用智能引用代理
行为型模式
子主题
子主题
子主题
子主题
子主题
子主题
子主题
子主题
子主题
预备知识
UML类图
特性
统一
建模
语言
结构
视图
图
模型元素
通用机制
面向对象设计原则
单一职责原则
开闭原则
抽象层
实现层
里氏代换原则
依赖倒转原则
依赖注入
构造注入
设值注入
方法注入
接口隔离原则
合成复用原则
迪米特法则
0 条评论
下一页
