设计模式也是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式的目的就是为了重用代码、让代码更容易被他人理解、保证代码可靠性。欢迎小伙伴们收藏关注，持续分享更多优质干货！
设计模式之道
15、责任链(Chain of Responsibility)模式
写在前面
Hello，你好呀，我是灰小猿！一个超会写bug的程序猿！
提到设计模式，相信小伙伴们一定都不会陌生，而且在很多在公司的岗位要求上，都会要求我们或多或少的掌握或使用过几个设计模式。今天我就和大家一起来就21种设计模式的最通俗的定义和使用场景进行分析，势必与面试官掰扯到底！！！
何为设计模式？
首先，何为设计模式（养生之道）？且听一一分解！
设计模式（Design pattern）代表了一种最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的一种解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。所以毋庸置疑，单单从字面意思就知道，设计模式是用来解决开发中遇到的难题的。
设计模式也是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。看这一句是不是就已经知道了设计模式的定义了呢？使用设计模式的目的就是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 也可以说是为了简化开发而诞生的。毫无疑问，设计模式对于开发者和对于系统来说都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。
听了这么多概念，是不是也不一定记得住？没关系！记住设计模式是为了在遇到问题时能简化开发，尽快解决的就行了。
设计模式的分门别类
上面也说到了，设计模式是经过分类编目的，那么它就一定是有很多种分类的，所以按照这21种设计模式的使用场景和特点，可以分为以下八种！
- 对象创建型：1.原型模式；2.工厂模式；3.抽象工厂模式；4.单例模式；5.生成器
- 接口适配型：1.适配器模式；2.桥接模式；3.外观模式
- 对象去耦型：1.中介者模式；2.观察者模式
- 抽象集合型：1.组合模式；2.迭代器模式
- 行为扩展型：1.访问者模式；2.装饰器模式；3.责任链模式
- 算法封装型：1.模版方法模式；2.策略模式；3.命令模式
- 性能与对象访问型：1.享元模式；2.代理模式
- 对象状态型：1.备忘录模式
是不是也觉得很多记不住啦？没关系啦！其实对于这些设计模式，还有一个简单的分类，就是按照使用目的划分为的三类：
- 对象创建型（creational）：主要用于处理对象的创建，实例化对象
- 结构处理型（structural）：处理类或对象间的组合
- 行为描述型（behavioral）：描述类或对象怎样进行交互和职责分配
其中：
- 对象创建型包括：工厂方法模式、抽象工厂模式、单例模式、生成器模式、原型模式
- 结构处理型包括：装饰器模式、适配器模式
- 行为描述型包括：观察者模式
按照分类只记住这几种就会简单一些。其实每一种设计模式都有属于它的特点和应用场景，经过反复的练习，掌握每一种设计模式的定义和应用场景，应对简单的面试还是没有问题的。最重要的就是之后合理使用其来开发项目，应用到实战中，彻彻底底的秀面试官一脸！
接下来就来和大家介绍一下这21种设计模式的基本定义和适用场景，记住这个对于之后熟练使用设计模式是很有帮助的！
1、原型(Prototype)模式
定义：原型(Prototype)模式用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
适用场景：
- 当一个系统应该独立于它的产品创建、构成和表示时;
- 当要实例化的类是在运行时刻指定时,例如，通过动态装载;
- 为了避免创建一个与产品类层次平行的工厂类层次时;
- 当一个类的实例只能有几个不同状态组合中的一种时，建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
2、工厂方法(Factory Method）模式
定义：工厂方法(Factory Method）模式定义一个用于创建对象的接口，让子类决定将哪一个类实例化，使一个类的实例化延迟到其子类。
适用场景：
- 当一个类不知道它所必须创建的对象的类的时候;
- 当一个类希望由它的子类来指定它所创建的对象的时候;
- 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。
3、抽象工厂(AbstractFactory) 模式
定义：抽象工厂(AbstractFactory) 模式提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
适用场景：
- 一个系统要独立于它的产品的创建、组合和表示时;
- 一个系统要由多个产品系列中的一-个来配置时;
- 当要强调一系列相关的产品对象的设计以便进行联合使用时:
- 当提供一个产品类库,而只想显示它们的接口而不是实现时。
4、单例(Singleton)设计模式
定义：单例(Singleton)设计模式是一种创建型模式，其意图是保证一个类仅有一个实例，并提供一个访问这个唯一实例的全局访问点。
适用场景：
- 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时;
- 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无须更改代码就能使用一个扩展的实例时。
5、生成器(Builder)模式
定义：生成器(Builder)模式将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
适用场景：
- 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时;
- 当构造过程必须允许被构造的对象有不同的表示时。
6、适配器(Adapter Pattern)模式
定义：适配器模式将类的接口转换成客户希望的另外一个接口，目的是消除由于接口不匹配所造成的类的兼容性问题。
适用场景：
- 已有类的接口与需求类接口不匹配。
- 借助一个抽象类，不必实现接口中的全部方法
7、桥接(Bridge)模式
定义：桥接模式把抽象层次结构从实现中分离出来，使其能够独立变更。抽象层定义了供客户端使用的上层抽象接口。实现层次结构定义了供抽象层次使用的底层接口。
适用场景：
- 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。
- 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
- 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。
8、外观(Facack) 模式
定义：外观(Facack) 模式为子系统中的一组接口提供一个致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
适用场景:
- 要为一个复杂子系统提供一个简单接口时，子系统往往因为不断演化而变得越来越复杂;
- 客户程序与抽象类的实现部分之间存在着很大的依赖性;
- 当需要构建一个 层次结构的子系统时，使用facade模式定义子系统中每层的入口点。
9、中介者(Mediator)模式
定义：中介者(Mediator)模式用一个中介对象来封装系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
适用场景:
- 一组对象以定义良好但是复杂的方式进行通信，产生的相互依赖关系结构混乱且难以理解;
- 一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象;
- 想定制一个分布在多个类中的行为，而又不想生成太多的子类。欲使一个后端数据模型能够被多个前端用户界面连接,采用中介者模式最合适。
10、观察者(Observer)模式
定义：观察者(Observer) 模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
适用场景：
- 当一个抽象模型有两个方面，其中一个方面依赖于另一-个方面，将这两者封装在独立地对象中以使它们可以各自独立地改变和复用;
- 当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变时;
- 当一个对象必须通知其他对象，它又不能假定其他对象是谁，即:不希望这些对象是紧耦合的。
11、组合(Composite)模式
定义：组合模式将对象组合成树形结构以表示“部分-整体"的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
适用场景:
- 想表示对象的部分-整体层次结构;
- 希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
12、迭代器(Iterator Pattern)模式
定义：迭代器提供了一种顺序访问聚合对象（集合）中元素的方法，而无需暴露结构的底层表示和结构细节。 遍历集合元素的任务从集合 转移给了迭代器对象。
适用场景：
- 需要访问组合对象内容，而不想暴露内部表示、结构。
注意：迭代器分为内部迭代器和外部迭代器。
外部迭代器允许客户端更自由的使用，同时需要熟悉组合对象的内部结构。
内部迭代器被封装在集合内部，在集合外部提供接口。
集合对象（nsarray, nsdictionary）都默认提供了迭代器。
13、访问者(Visitor Pattern)模式
定义：访问者模式作用于组合对象结构中的每一个元素的操作，它让我们在不改变元素类的前提下，扩展这些类的新操作。在接受访问者的接口方法中，实现将元素传给访问者，然后访问者扩展对元素的操作。
适用场景：
- 想对一个对象进行很多不相关的操作，又不想污染这个对象。
14、装饰器(Decorator)模式
定义：装饰器模式描述了以透明围栏来支持修饰的类和对象的关系，动态地给一个对象添加一些额外的职责，从增加功能的角度来看，装饰器模式相比生成子类更加灵活。
适用场景:
- 在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责;
- 处理那些可以撤销的职责;当不能采用生成子类的方式进行扩充时。
15、责任链(Chain of Responsibility)模式
定义：责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用场景：
- 有多个的对象可以处理一个请求，哪个对象处理该请求在运行时刻自动确定;
- 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求;
- 可处理-个请求的对象集合应被动态指定。
16、状态(State Pattern)模式
定义：允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
适用场景：
- 行为随状态改变而改变的场景。
- 条件、分支语句的代替者。
17、策略(Strategy)模式
定义：策略模式定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换。此模式使得算法可以独立于使用它们的客户而变化，
适用场景：
- 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法;
- 需要使用-个算法的不同变体。例如，定义一些反应不同空间的空间/时间权衡的算法。当这些变体实现为一一个算法的类层次时，可以使用策略模式;
- 算法使用客户不座该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构;
- 一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，将相关的条件分支移入它们各自的Strategy类中，以代替这些条件语旬。
18、命令(Command) 模式
定义：命令模式将一个请求封装为一个对象，从而使得可以用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可撤销的操作。
适用场景：
- 抽象出待执行的动作以参数化某对象，此模式是过程语言中的回调(callback) 机制的一个面向对象的替代方式;
- 在不同的时刻指定、排列和执行请求;
- 支持取消操作;
- 支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍;
- 用构建在原语操作上的高层操作构造一个系统。
19、享元(Flyweight)模式
定义：享元模式运用共享技术有效地支持大量细粒度的对象。
适用场景:
-
一个应用程序使用了大量的对象;
- 完全由于使用大量的对象，造成很大的存储开销;
- 对象的大多数状态都可变为外部状态;
- 如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象:
- 应用程序不依赖于对象标识。
20、代理(Proxy Pattern)模式
定义：通过提供与对象相同的接口来控制对这个对象的访问，以使得在确实需要这个对象时才对它进行创建和初始化。
代理模式可以分为远程代理和虚拟代理。
远程代理：用本地对象代替远程对象。如：发送网络时的代理服务器。
虚拟代理：将代理直接面向客户端，使客户端认为操作的虚拟代理就是真实对象。虚拟代理提供占位对象和重型对象。默认使用占位对象，当需要使用重型对象时才加载。
适用场景：
- 远程代理，这种方式通常是为了隐藏目标对象存在于不同地址空间的事实，方便客户端访问。
- 虚拟代理，这种方式通常用于要创建的目标对象开销很大时。
- 安全代理，这种方式通常用于控制不同种类客户对真实对象的访问权限。
- 智能指引，主要用于调用目标对象时，代理附加一些额外的处理功能。
- 延迟加载，指为了提高系统的性能，延迟对目标的加载。
使用实例：
Object-C不支持多继承，如果代理对象不是NSObject的子类的话，可以考虑用NSProxy来作为占位或者替代对象。尽管NSProxy也是NSObject类型，但是NSProxy的作用就是当代理。
21、备忘录(Memento Pattern)模式
定义：在不破坏原有封装的前提下，捕获一个对象的内部状态，并在该对象之外保存状态。 这样，之后可将对象恢复到之前的状态。将状态封装成对象保存。
适用场景：
- 需要保存对象在某一时刻的状态（或部分状态），这样以后就可以恢复到先前的状态。
- 提供一个可回滚的操作
使用实例：
Cocoa Touch框架在归档，属性列表序列化，核心数据中采用了备忘录模式。
好了，关于21种设计模式的讲解就先分享这些，掌握了这些基本理论，和面试官掰扯几个回合应该是没问题了，之后就看你如何机智的使用设计模式开发项目了！
关于设计模式有问题的小伙伴们可以在评论区留言提出！
觉得不错记得点赞关注哟！
灰小猿陪你一起进步呀！
转载：https://blog.csdn.net/weixin_44985880/article/details/116605616