具体的实现Demo请进入DesignPatterns iOS工程实现查看

13. 责任链模式

避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些
对象连接成一条链，并且沿着者条链传递请求，直到有对象处理它为止。
iOS里的事件传递。就是一种责任链模式。
使用场景
有多个对象可以处理一个请求，具体哪个对象处理该请求由运行时自动确定。
在不确定指定接收者的情况写，向多个对象中的一个提交一个请求。

14：命令模式(很重要)

将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
使用场景
需要对行为进行记录，撤销或者重做，事物等的处理时。凡是有命令的地方，都可以使用命令模式。命令模式实现了很容易对命令的扩展（即对扩展开放），添加一个命令就可以了，同过这些命令取修改接受者的状态，其实我们直接执行函数就可以修改接受者的状态，当我们需要添加一些行为的记录，撤销的等行为，为了将行为的实现者receiver与行为的请求者(既可以是receiver也可以是其他对象)实现松耦合。

15：解释器模式

16：迭代器模式

提供一种按顺序访问一个聚合对象中的各个元素。而又无需暴露该对象的内部表示。
迭代器的关键代码是实现hasNext,next。
迭代器简化并且统一了对于集合类型的访问方法。在新添加的集合类型里，无需修改原有代码，只需要实现针对这个心添加的集合的迭代器就可以了。所以对扩展时开放的。

17：中介者模式

中介者模式和我们日常生活中的中介者其实是一样的。房产中介。解决了买家与卖家之间错综复杂的关系。实现了。买家与中介联系，卖家与中介联系,当然这里协调的对象也可以是相同类型的比如都是"买家",我们把买家与卖家统一称为“同事”（这类在初看文章的时候不理解为什么都是”同事“，其是为了方便描述罢了。在实际的开发中，那你想协调哪两种或者多种对象之间的交互都是可以的）。在对象的世界里面，也是如此。
实际的例子

MVC里的模式，c就是中介者，m,v都是同事。c需要协调m与v的交互。那么从这里也可以看出。设计不当的时候很容易将c搞的比较复杂。
代码里的例子
同事之间有一定的关系。同事A修改的分值，同事B的分值同样会修改。同事C的值统一会修改。
那么就有个问题，我同事A修改了值，我还要通过A取修改B的值，B的值修改了，B还要去修改C的值。这样就是对象间非常复杂的操作关系。
引入中介这后，这个几个对象之间的关系就变成只有中介者之间交互。这样关系就轻松多了。

18：备忘录模式

保存一个对象的某个状态，以便在适当的时候恢复对象。
在不破话封装的前提下，捕获一个对象的内部状态，幷在该对象之外保存这个状态，这样可以
在以后将恢复到原先保存的状态。
实现代码的核心是搞一个备忘录的类。要保存状态的类可以实现协议方法，取出当前需要保存的
信息。和将保存的信息恢复为类的过程。整个是在需要备忘得对象实现的。
所以，备忘录其实，就时搞一个类专门实现“存”与"取"一个对象的状态，以备忘。

19：观察者模式

当一个对象的状态发生改变的时候，所有的依赖对象都将得到通知。
解决一对多的情况。
观察者模式，在iOS里到处都有。通知中心，Kvo,等.

20：状态模式(很重要,实际的开始中很常见)

对象的行为依赖于他的状态，并且可以根据它的状态的改变而改变相关的行为。
使用场景
当代码中包含有大量于状态有关的行为时。

21：策略模式

策略模式同状态模式一样，不同的是将策略进行隔离。当有新的策略时，只需要扩展新的策略就行了。

22：模板方法模式

23：访问者模式

具体的实现Demo请进入DesignPatterns iOS工程实现查看

6. 适配器模式

适配器模式将某个类的接口转换成客户端期望的另一个接口表示。目的是消除由于接口不匹配所造成的类的兼容性问题。分为3类，类适配器，对象的适配器

1. 类适配器
   所谓的类适配器，指的是适配器Adapter继承我们的被适配者Adaptee，并实现目标接口Target。

2. 对象适配器
   所谓的对象适配器，就是适配器实现我们的接口，但是并不继承需要被适配的类。而是通过在构造函数中将需要被适配的类传递进来从而进行适配(也就是组合的形式)。

它们的特点(至于特点，可以从它们的实现方法取考虑)
类适配器只能适配一个类，而对象适配器可以将不同的待适配者适配到统一目标。
而类适配器由于是继承，可以置换待适配对象的一些方法。

7. 外观模式

外观模式让子系统更加易用，使用端不需要了解子系统的内部的实现。
也不需要跟众多子系统的内部的模块进行交互，只需要跟门面交互就可以了。外观角色好比一道屏障，对客户端屏蔽了子系统的具体实现。

8. 桥接模式

桥接模式的场景：
类似于绘制形状，有多个形状，每个形状的颜色还不一样。为每种形状都提供各种颜色的版本，会造成n*n个类。

这是可以采用桥接模式，将继承关系转换成关联关系，为每种形状都提供各种颜色的版本。
桥接模式的本质是将继承关系转换成关联的关系。从而降低了类与类之间的耦合度，减少了系统中的类的数量，也减少了代码量。

9. 装饰

有这样一个场景，购买咖啡时，可以要求在其中加入各种调料。例如
豆浆，摩卡，蒸奶，有时添加，有时不添加。这样就会导致类的爆炸，并且无法满足混合添加,多次添加的的情况。
关键的实现装饰类的实现

装饰类的设计，装饰类既有主类的属性，本类也是主类类型。这样可以递归的方式来获得最总被装饰了的对象。

10. 代理

代理不说了，开始做iOS时就是代理模式。

11. 享元

享元就是共享对象。既可以内存缓存对象，也可复用对象（通过一个唯一的标识）。

12. 组合模式

我的理解，组合的设计模式在这里有两层含义。
一层含义：对象包含对象的问题，通过组合的方式（在对象内部引用对象）来进行布局。
二层含义：引申到树形结构的对象包含对象。

接下来将进入设计模式里的创建型设计模式。这里将对设计模式的使用场景与优劣，以及UML图做描述。
具体的实现Demo请进入DesignPatterns iOS工程实现查看

0. 简单工厂（if type）

（通过传类型进行区分，对修改是开放的，所有不好）
简单工厂就是一个工厂，将类型传进去，在一个类里面生成不同的类型。
弊端：这个工厂会包括多个需要生产的产品的引用。而且对于修改是开放的，因为需要修改类里面的内容。对于扩展也是需要在同一个类里面做修改。

1. 工厂方法（一个产品线）

使用场景：
当需要创建多种分Type的对象时，特别是针对多种类型有共同的行为特征时。或者写出简单工厂时，思考是否可以用工厂方法。

好处：
工厂方法遵循开闭原则就是”对扩展开放，对修改关闭”，再说白点就是实现工厂方法以后要进行扩展时不需要修改原有代码（你看简单工厂里添加类型时时不是还要修改if语句），只需要增加一个工厂实现类和产品实现类就可以。

实现：
产品基类（协议），工厂基类(协议)。产品实现，工厂实现。客户端直接使用工厂生产相应的产品就可以了。

费曼工厂方法会针对每个产品都有一个工厂实现类。工厂实现类有一个相应工厂的一个实现，这个实现是生产产品的实现。我们可以将工厂方法理解成一个产品线。

2. 抽象工厂（多个产品线及真正的工厂）

使用场景
1.通过对象组合创建抽象产品

2.创建多个系列产品
3.必须修改父类的接口才能支持新的产品

费曼 所谓的抽象工厂，就是将工厂方法的产品线扩大到多个产品线 我们可以将抽象工厂理解成多条产品线（真正的工厂）,每一个工厂有其特殊的标识。

突然想到一个例子
”北京杂酱面“ 与 “重庆杂酱面”都是杂酱面，都是配料都是面条，汤，酱，但北京面馆（一个工厂），是北京面条，北京汤，北京酱，重庆面馆（一个工厂）是重庆面条，重庆汤，重庆酱，这个工厂是一个产品线。

3. 单例模式(整个应用程序只用一个对象)

使用场景
在一个应用程序中，当需要在多个地方共享数据时

注意点
注意多线程的使用下的情况。

在实际的使用中，单例模式也不能滥用。举个例子，单例有个isLogin，我判定isLogin为true进入一个操作，其他线程将isLogin改成false，那么在这个单例里执行的操作都将有问题。
因为数据被其他线程改变了。在实际的开发中，这种情况会是一个大坑。

4. 构建者(子部分算法的变化无常，当构成这个对象组成相对固定)

构建者模式使用多个简单的对象一步一步构建一个复杂的对象。
主要解决的问题，有时候面临着"一个复杂的对象"的创建工作，通常其子对象部分有着剧烈的变换，需要将他们组合在一起。

我的理解是，当创建一个对象，这个对象需要很多组合的对象（且这些组合的对象有一定固定算法，我需要将这些对象随意的组合成我需要的对象）时，用构建者模式。（区别与抽象工厂，抽象工厂创建后不是随意的组合，是工厂创建后就只能生产固定的产品了，抽象工厂的变换在外部，而构建者的变换在内部，哈哈，就是这个意思）
例如
构造电脑，电脑的组成由CPU,显示器，主板，这是相对固定的。但子部分，CPU有各种实现的算法。所以这种情况使用构建者最好。

5. 原型模式

原型模式
原型遵循copy或者clone的协议。执行copy或者clone就是按照原型创建一个对象。在iOS里理解成copy就行了。

在这里给大家推荐一本设计模式入门的书《HeadFirst 设计模式》，这是我真正理解设计模式的开始。当然对于设计模式的理解，需要一定的开发经验才能真正理解的。

本篇文章不是对设计模式的全解。而是我自己在iOS的实践中对设计模式的理解的一个一个梳理。我在DesignPatterns iOS工程实现里写出了相关的Demo

学习方法：抽象—》具体—》应用—》引申。重点在与理解设计模式的几大原则在设计模式里的体现。当你理解了几大原则在设计模式里的体现，也就理解了设计的精髓所在。在自己写出相关Demo后，然后自己默写出相关设计模式的UML图，分析每种设计模式的优劣是为解决什么问题而诞生。那么那你就真正理解了设计模式。

设计模式的六大原则

1. 开闭原则（面向对向设计的首要目标:对扩展开放，对修改关闭）
   对扩展开放，对修改关闭，也就是在进行扩展时，不要对先前的代码修改（因为如果对先前的代码进行修改的化，需要重新测试）。对扩展开放最好直接创建一个新类，其他的东西都不要更改。可以采用抽象的方式，将对象抽象出来，形成对这个"抽象化"处理。

2. 里氏替换原则（子类替换基类业务不受影响）
   在软件中将一个基类对象替换成它的子类对象，程序不将不会出现任何差错。其实这是开闭原则的一个实现。也就是在程序中尽量使用基类类型来对对象进行定义，而运行时在确定其子类类型。这样有一种面向基类，面向协议编程，这样在有扩展进来时，更改的代码就会很少。

3. 依赖倒置原则(面向协议编程)
   名字取的很高大上。实际就一句话，实现依赖抽象，抽象不依赖实现。也就是面向协议编程，不针对实现编程。

4. 接口隔离原则(接口分离)
   使用多个专门的接口，而不使用单一的总接口。每个接口
   应该承担一种相对独立的角色，将不同功能类型的接口进行分离

5. 迪米特法则（减少对象之间交互）
   应该减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的作用。

6. 合成复用原则（多用组合少用继承）
   尽量使用合成与聚合，而不是使用继承。
   这条在实际的开发中，的确很有感触。继承用的不好会导致维护的困难。

设计模式分类

创建型设计模式
结构型设计模式
行为型设计模式

一：创建型（5种）

1:单例模式
2:工厂方法(生成单一产品)
3:抽象工厂（生产系列产品）
4:建造模式（生产比较复杂的具有统一生产流程的产品，将生产流程固话）
5:原型设计模式(clone的实现)

二：结构型（7种）

6:适配器模式（将一个对象适配成需要的接口）
7:桥接模式
8:组合模式（类似于iOS里的view，对每一个组件具有相同的操作方法）
9:外观模式（子系统）
10:享元模式（聚合使用）
11:代理模式
12:装饰模式

三：行为型（11种）

13:责任链模式
14:命令模式
15:解释器模式（暂时不太明白）
16:迭代器模式
17:中介者模式
18:备忘录模式
19:观察者模式
20:状态模式
21:策略模式
22:模板方法模式
23:访问者模式(暂时不太明白)

其中，命令模式，状态模式，策略模式，都是同的思想，将命令封装，将状态封装，将策略封装。