目录
前言
设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，设计模式不是具体的代码，而是一种合理、易拓展、易维护的代码架构思想。设计模式被运用在各种优秀的框架中。掌握设计模式不仅能帮助我们更好的理解开源框架、亦能提升我们的编程能力。本文旨在总结常用设计模式的原理和常用场景。写作水平有限，不恰当处请指出。
读懂UML图
- 继承（extends）：带三角箭头的实线，箭头指向父类
- 实现关系（implements）：带三角箭头的虚线，箭头指向接口
- 依赖：带箭头的虚线，指向被使用者
- 关联 ：带普通箭头的实心线，指向被拥有者
- 聚合：带空心菱形的实心线，菱形指向整体
- 组合:带实心菱形的实线，菱形指向整体
设计模式六大原则
- 单一职责原则（SRP）：单个类只负责一项业务
- 里氏替换原则：子类功能要多于父类功能，但是不要修改父类功能，以免引起调用歧义
- 依赖倒置原则（面向接口编程）：调用接口时注入接口而不是具体实现
- 接口隔离原则：接口功能粒度要细，不要把所有的声明放到一个接口，利用java单继承多实现，分成多个接口
- 迪米特法则：不要引入无法管理的类，引入类要以成员变量形式。又称最少知道原则
- 开闭原则：对扩展开放，对修改关闭
设计模式分类
创建型模式，共五种：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰者模式、代理模式、门面模式（外观模式）、桥梁模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模版方法模式、观察者模式、迭代器模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
创建型模式原则
创建型模式包括简单工厂模式、工厂方法模式、抽象工厂模式、建造者模式、单例模式，创建型模式模式遵循的设计原则如下：
- 解耦：把对象的创建和使用分离开
- 单一职责：工厂负责对象的创建和实例化，对于使用者来说创建过程是黑盒的
- 面向接口编程：使用者通过接口获取对象，易于分工、维护
创建型模式 分析
1.简单工厂模式
- 说明：我们把被创建的对象称为“产品”，把创建产品的对象称为“工厂”。如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”。简单工厂模式属于不属于23种设计模式，它是工厂模式在简单场景下的一种应用。它的缺点是增加新产品时会违背“开闭原则”。
- 适用场景：简单工厂模式适用于产品(子类)较少的场景，例如图书馆管理系统中的用户类，它的实现类很固定，只有学生、教职工两种类型，在设计之初就可预见所有的类型，拓展的可能性很小，这种场景下适合使用简单工厂模式。
- 缺点：不满足开闭原则，难拓展
- UML解读：product可以理解为图书馆用户类，ConcreateProduct1为学生类，ConcreateProduct2为教职工类，Factory为工厂，Client为使用用户类的业务。Client想要建一个学生类或者教职工，只要调用工厂方法并且传入对应类型，工厂方法便会返回相应类型。
2.工厂方法模式
- 说明：工厂方法模式是对简单工厂模式的进一步抽象化，工厂方法模式满足开闭原则，可以更好的支持更好的支持多种产品(子类)、常扩展产品的业务场景。
- 使用场景：车辆售后维修系统的零件模块可以使用工厂方法模式，售后的零件是一个很灵活的业务场景，零件可以分为普通单个维修零件、套项零件(例如维修大灯总成的多个零件组合成的零件组)、技术升级零件(检查车辆可能存在的问题)。随着业务拓展会有更多的零件类型产生，如果使用简单工厂模式在新增了零件类型后就要修改原有代码适应新场景，修改同时可能会引入错误，不满足开闭原则。
- 缺点：每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。
- UML解读：product1、product2为不同的零件类型，Factory1、Factory2为对应类型的工厂，它们都实现了AbStractFactory，Client为零件类的使用者。如果想要创建一个A零件就找A零件的工厂方法，如果想拓展一个新的零件类型就新增一个零件工厂和零件实体，这样就不会对老代码产生影响。
3.抽象工厂方法模式
- 说明：工厂方法模式是工厂和商品一对一的模式，抽象工厂方法模式可以理解为一个工厂对一系列商品的情况。
- 使用场景：永辉超市要选择奶类食品供应商，采购的商品包括牛奶和酸奶，供应商包括蒙牛和伊利。蒙牛和伊利都是抽象工厂，因为它们都有生成系列产品的能力。
- 其缺点是：当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。
- UML解读：factory1和factory2分别代表蒙牛和伊利，product1*代表牛奶，product1*代表酸奶。
4.建造者模式
- 说明：建造者模式适用于整体对象由多个部件组成，且多个部件可以独立存在的情况，产品的组成部分是不变的，但每一部分是可以灵活选择的。
- 场景：组装汽车时需要用到发动机、车架、邮箱等零部件，零部件的生产相互独立，为汽车总成提供零件供应。在组装汽车时按照一定的顺序对零部件进行安装、调试，最终完成汽车的组装。汽车的最终组装者类似于电影导演的角色。
- UML解读：Client是调用发起者，可以看作是外部触点，Director是导演类负责执行汽车的组装.BMBuilder和BenZBuilder实现了CarBuilder，CarModel 以及两个实现类 BenzModel 和 BMWModel 叫做产品类(Product Class)，这个产品类实现了模板方法模式。
CarBuilder 以及两个实现类 BenzBuilder 和 BMWBuilder 叫做建造者(Builder Class)。
5.单例模式
- 说明：保证一个类只有一个实例，并提供一个全局访问点
- 场景：数据库连接池的设计、
- 优点：在内存中只有一个实例，减少内存开销、全局统一的访问点可以严格控制对象的访问
- 缺点：没有接口，扩展困难
- UML图：客户端访问单例类，单例类负责控制任何情况下只有一个实例
单例模式学习友情链接：
单例模式的懒汉式为什么是线程不安全的，懒汉式如何实现线程安全
6.原型模式
- 说明:原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象
- 特点:不需要知道任何创建的细节，不调用构造函数
- 场景:类初始化效果过多资源、new产生的一个对象需要非常繁琐的过程（数据准备、访问权限控制）、构造函数比较复杂、循环体中产生大量的对象。
- 优点:使用原型模式创建对象比直接new对象的性能高、简化创建过程
- 缺点:必须配备克隆方法、克隆复杂对象或克隆出的对象进行复杂性改造时容易引入风险、对复杂对象深拷贝、浅拷贝要运用得当
- 扩展:深克隆、浅克隆区别与使用
原型模式学习友情链接：
原型模式的使用案例、克隆复合对象出现的问题及解决方案、深克隆和浅克隆的区别
创建型模式 总结
- 简单工厂方法：把所有对象的创建，集中到一个类中处理
- 工厂方法模式：一个工厂负责一个产品的创建
- 抽象工厂模式：将一系列的产品抽象到同一个工厂创建
- 建造者模式：对象的创建比较复杂时，按照步骤一块块创建，让创建过程模板化
- 单例模式：控制实例数量，确保一个类只有一个实例
- 原型模式：用于低消耗的创建对象
图片、部分文字出处如下(侵删)：
扫一扫
197
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
