常用设计模式介绍

常用设计模式介绍

创建型模式：思考的是对象的创建的过程

1、单例模式：一个类只能生成一个对象：静态成员变量
（1）懒汉式单例：
在需要时创建：多线程可能会创建多个对象（加锁解决该问题，但锁机制会影响性能，最推荐的懒汉式单例——局部静态变量）
（2）饿汉式单例：
在初始化的时候进行创建：多线程不会创建多个对象（线程安全，比较常用，但容易产生垃圾，因为一开始就初始化）

2、工厂模式
（1）简单工厂：
抽象产品->具体产品
工厂->生成不同的具体产品
好处：
将产品指针和产品对象分离
缺点：
每增加一个产品，就需要改动工厂类

    抽象工厂角色：工厂方法模式的核心，任何工厂类都必须实现这个接口
    具体工厂角色：具体工厂是抽象工厂的一个实现，负责实例化产品对象
    抽象角色：工厂方法模式所创建的所有对象的父类，它负责描述所有实例所有共有的公共接口
    具体产品角色：工厂方法模式所创建的具体实例对象

（2）工厂方法：
抽象产品->具体产品
抽象工厂->具体工厂
好处：
增加新产品和新工厂时不需要改变原来的类（开闭原则）
（3）抽象工厂：
同一家工厂生成不同的产品族类
缺点：
对于增加新的产品，无能为力；支持增加产品族

抽象工厂和工厂方法的模式基本一致，区别在于，工厂方法是是生产一个具体的产品，而抽象工厂可以原来生产一组相同，有相对关系的产品；重点在于一组，一批，一系列。

3、建筑者模式：将复杂的对象和部件的创建分离开来
具体产品->创建产品的抽象流程->具体流程->建造者建造产品
优点：
封装性好，创建和使用分离
扩展性好、建造类之间独立、一定程度上解耦
缺点：
一旦建造流程改变，建造类就需要改动
产生多余的对象
****建造者模式和工厂模式的区别：
工厂模式只关心生产产品的类别
建造者模式关心生产产品的过程

4、原型模式：又称之为克隆模式；用拷贝对象的方法创建新的对象
实现方式：在类的内部写一个clone函数
好处：简化new创建对象的过程

结构性模式：思考的是类与类之间的关系，通过解耦和联通形成更为复杂的结构

1、适配器模式（也称包装模式）：给类增加或删除功能能够适配其他本不兼容的类
分类：
（1）类适配器：实现原理：多继承
（2）对象适配器：单继承，在适配器类中创建一个类的对象
实例：STL中的stack

2、外观模式：接口继承
提供了一个统一接口，用来访问子系统的一群接口，外观定义一个高层接口，让子系统更容易使用
作用：简化你的类的接口，将一系列的复杂的过程封装到内部，对外只提供最简单的接口
优点：
减少系统的互相依赖，所有的依赖都是对外观类的依赖，与子系统无关
对用户隐藏了子系统的实现，减少用户对子系统的耦合
加强了安全性，子系统中的方法如果不在外观类中开通，就无法访问子系统的方法
缺点：
不符合开放封闭原则，如果业务出现变更，则可能直接修改外观类

3、代理模式：创建一个代理对象实现对原对象的访问
组成：
（1）抽象对象：声明真实对象和代理对象的共同接口
（2）具体对象：进行访问的对象，是我们最终要引用的对象
（3）代理对象：代替访问对象进行访问
优点：
（1）代理模式能将代理对象与真实对象被调用的目标对象分离降低了系统的耦合度，扩展性好
（2）保护目标对象
（3）增强目标对象
缺点：
（1）代理模式会造成设计中类的数目的增加
（2）在客户端和目标对象增加一个代理对象，会造成请求处理速度变慢
（3）增加了系统的复杂性
适用场景：
智能指针

4、装饰器模式（也称包装模式）:对类的功能进行扩展（继承的一种代替方案）
组成：
(1）被装饰的原有对象的抽象类
（2）被装饰的具体类
（3）抽象装饰类
（4）具体装饰类
好处
：(1）扩展更灵活
（2）可以进行不同的组合
缺点：
可读性变低。程序变得复杂
适用场景：
（1）扩展一个类的功能或者给一个类添加附加职责
（2）一个多态对象的添加功能，或多态撤销功能
（3）动态扩展类的功能
包装模式VS适配器模式VS代理模式
适配器模式：将接口A使用接口B的功能
代理模式：用代理对象代替进行处理
包装模式：对原有对象进行功能扩展

5、桥接模式：在具体中抽离出抽象属性，再通过具体类去连接
优点：
(1)抽象和现实的分离
(2)优秀的扩展能力
(3)实现细节对客户透明
缺点：
(1)增加了理解和设计难度，由于联合关联关系建立在抽象层，要求开发者针对抽象进行设计和编程
(2)要求正确识别出系统中两个独立变化的维度，因此其使用范围有一定的局限性
适用场景：
(1)一个类存在两个独立变化的维度，且这两个维度都需要进行扩展
(2)对于那些不希望使用继承或因为多继承导致系统类的个数急剧增加的系统，桥接模式尤为适用
包装模式VS桥接模式
共性：都是对原有类进行了扩展，减少了子类的数量（少用继承）
包装模式：将多余的功能放到一个独立的类族中
桥接模式：将原有类的一种属性抽象出来，形成了一个独立分支，再进行连接

6、享元模式：是对象池的一种实现，类似于线程池，线程池可以避免不停的创建和销毁多个对
象，消耗性能。
最大好处：
节省空间
做法：
创建一个享元池，需要对象时到池子里取，如果不存在就返回一个新的
作用：
缓存共享对象，降低内存消耗
角色：
抽象享元角色：抽象类或接口，可以接受并作用于外部状态
具体享元角色：实现抽象抽象享元角色接口，并为内部状态增加存储空间
不可共享的享元角色：指那些不需要共享的抽象享元角色子类，不可共享的享元角色不需要从工厂中创建，直接new即可
享元工厂：提高一个已创建的抽象享元角色对象或创建一个抽象享元角色对象
优点：
(1)可以极大的减少内存中对象的数量，使得相同对象或相似对象在内存中只保存
一份，减低内存占用，增加程序的性能。
(2)外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不同的环境中被共享。
缺点：
使得系统更加复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂化
适用情况：
系统中有大量的相似对象
需要缓存池的对象

行为型模式：思考的是靠的是类与类之间的关系，协调工作

1、模板方法模式：定于一个操作中的算法的骨架，而将一些步骤延迟到子类
（1）在一个类中定义一系列的算法，算法的细节交给子类去实现
（2）提高了代码的复用性
（3）每个实现都要定义一个新的类
作用：
使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定步骤
适用场景：
一次性实现一个算法的不同部分，并将可变的行为留给子类实现
各子类中公共行为应被提出出来并集中到一个公共父类中以避免代码重复
需要通过子类来决定父类算法中某些步骤是否执行，实现子类对父类的反向控制

2、策略模式：抽象父类，具体实现算法的子类，这些算法都是同一类算法，都是为了解决
同一个问题。只是方式不同。
好处：
每一种算法都是一个独立的类，接口的调用非常的方便
缺点：
类过多–策略模式会造成很多的策略类，每个具体策略类都会产生一个新类
策略模式VS装饰模式：
策略模式侧重父类的改变，而装饰模式侧重两个类之间的关系

3、观察者模式：实现类与类之间的通信（两个没有继承关系的类）
原理：将观察者绑定在观察者的内部（观察者监听被观察者状态）
观察者：更新被观察者信息
被观察者：添加/删除 观察者
发布消息：遍历观察者容器，群发消息
优点：
满足开闭原则
具体主体和具体观察者是松耦合关系
缺点：
代码结构会变的很复杂，小心循环依赖，造成系统奔溃
只能接收到被害观察者的状态，不能影响其状态

4、责任链模式：对一个请求的不同等级的处理
（1）责任链模式本身不创建责任链
（2）有效的降低了请求的发送端和接收端的耦合
（3）责任链可以是一条线、一棵树、一个环
（4）避免循环依赖：一定要能够处理所有的请求
适用场景：
一个请求有多个处理对象
5、中介者模式：实现类与类之间的通信（聊天室中的私聊）
（1）将一对多的依赖变成一对一的依赖
（2）有效的降低了类和类之间的耦合
（3）程序的逻辑变得复杂
适用场景：
中介者模式也称调停者模式
1.N个对象之间产生了相互依赖的关系（N>2）
2.MVC模式
6、备忘录模式：在不破坏类的封装性的情况下，捕获一个对象的内部状态，并在对象之外保存
这个状态，这样可以在以后将对象恢复到原先保存的状态。
作用：对象之外保存状态：浏览器回退、编辑器撤销和重做、棋牌游戏悔棋
优点：
给我们程序提供了后悔药，完善了业务场景。
备份的状态数据由额外的备忘录管理，备忘录又由管理者管理，符合单一责任原则。
缺点：
资源消耗过大，需要保存的原发类的成员变量太多，每保存一次对象状态都需要消耗一定的系统资源

7、命令模式：将“请求”封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。
命令模式也支持可撤销的操作。
作用：封装方法调用细节，以便解耦请求者和执行者
优点：
实现客服端和接受者之间的解耦
可以动态的添加新的命令，扩展性好
只需要调用同一种方法便可实现不同的功能
缺点：
实现一个具体的命令系统，可能要创建很多的具体命令对象
适用场景：
需要抽出待执行的动作，然后以参数形式提供出来，类似于回调机制
**命令模式可以结合责任链模式，实现命令族解析任务
**结合模板方法模式，则可以减少子类的膨胀问题

8、状态模式：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类
作用：当控制一个对象状态转换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类当中，可以把复杂的判断逻辑简化。
优点：
(1)结构清晰，避免了程序的复杂，提高了系统可维护性
(2)体现了开闭原则和单一责任原则，每个状态都是一个类，与单一责任原则高度符合，扩展状态只需要增加子类，正是开闭原则的体现。
缺点：
如果一个事务有很多个状态，就会造成子类太多的问题。需要在项目使用时来平衡是
否使用状态模式。
适用场景：
行为随状态改变而改变的场景，例如权限设计
条件、分支判断语句代替者，通过扩展子类来实现条件判断处理