设计模式是什么？为什么要学习它？
简而言之就是前人总结的如何提高代码可复用性，灵活可扩展性的经验。软件开发经过多年的发展，现今遇到的很多问题前人也遇到过，并成功解决了。站在前辈巨人的肩上，能让我们快速轻松解决很多问题。关于设计模式的书籍，应该最著名的就是四人组的《设计模式》，被奉为OO圣经。信耶稣读圣经，信OO读四人组的《设计模式》。对于新手，推荐《HeadFirst》。本篇就是《HeadFirst》第一章实践，本书之前已读了一遍。纸上得来终觉浅，绝知此事要躬行。书中为java例子，由于平时使用swift开发，此系列文章将使用swift实践。
本章精华
1 找出应用中需要变化之处，独立出来加以封装
把会变化的部分抽取封装，这样可以单独对它修改而对剩余系统不造成影响，提高了剩余系统的复用性与可扩展性。我们所有的努力就是为了实现一个效果：可以大量复用已有代码，需要修改时，可以只对一小部分改动，并且修改不会影响系统其它部分，避免牵一发而动全身。没有人想因为小功能的修改而要对整个系统进行修改。
2 针对接口编程，而不是针对实现编程
这句话看起来每个字都认识，但是初学者一定会一脸懵逼。简单说一下，在swift中，它可以表述为：面向协议编程，而不是针对实现编程。通过协议定义对象之间交互的方式，把具体的实现代码抽离主体对象，主体对象只了解辅助对象实现了协议，并不清楚辅助对象如何具体实现。这样做成功的将一部分功能单独隔离了起来，避免它的捣乱（变化）对其他部分造成影响。是不是觉得与1非常像，没错，它们两说的就是一个东东，1如何封装变化？就是用2的套路，通过协议定义接口，然后把变化部分封装隔离。
3 多用组合，少用继承
what? Are you kidding me? 面向对象不就是要通过继承来复用代码的吗？
你没听错，就是少用继承，多用组合。原因是继承是一种很强的关系，会造成很强的耦合。父类的属性方法，子类需要无条件接受。而组合是将一部分功能抽取封装在一个辅助类中，会获得更好的灵活性与隔离性（隔离性即局部的改变不会对整个系统造成影响）。听起来是不是又与1、2相关，😆。对头，1告诉你抽取变化的部分，2告诉你把抽取出的部分以接口（协议）的方式暴露出去，3告诉你通过把2暴露出的接口通过组合的方式接入被抽取的类中。
案例：
某车企要研发一个汽车模型展示应用在车展上给人们使用。按OO的思想，先创建一个基类CarModel,然后让不同的车型继承自它。下面是基类：
公司车展要展示两个型号的车，XLimousine（X牌加长豪华轿车），XSportsCar（X牌跑车）。虽然两个车型开门方式不一样，不过很容易嘛，只需要override openDoor方法就好了。下面是两个子类：
很不幸，公司感觉两个车型太少，会让人觉得公司创新能力不幸，决定再加三款车型，XSuperStarCar（超级明星款），XElectricalCar（电动轿车），XElectricalSportsCar（电动超跑）。这下工作量变大了，由于可能开门方式不同，需要在每个子类检查并override openDoor方法。下面是三个子类：
从上面的代码可以看到openDoor 方法在多处有重复，每当有车型进来都要override openDoor方法，若有子类继承了父类的方法，修改父类中的方法会影响所有子类行为（除非这就是你想要的效果），除了复用性差，扩展性也不灵活，比如当老板说，我们现在提供可定制开门方式的汽车，我们需要让客户在单个车型上动态切换开门方式，你会怎么做？
重构：
从上面的精华部分我们知道，要观察应用的变化部分，然后抽取出来，用单独的类封装，并且通过接口暴露功能，通过组合的方式提供给主体对象。下面开始重构：
1 创建OpenDoorBehavior协议
2 创建行为类实现协议
3 通过组合的方式接入CarModel基类
下面是1、2步代码：
下面开始重构CarModel基类，组合行为类。
可以看到，在CarModel中的属性类型是协议，而不是具体的行为子类，好了，现在可以将所有CarModel子类的 openDoor方法全部删除了。使用时只需要将正确的行为类实例传入即可，而每个车型根本不知道开门的具体实现，它只知道有openDoor方法可以开门。另外，现在你可以在运行时动态改变开门方式，只需要给行为属性一个新的实例，是不是更加灵活，复用度更高了？
结语：
你知道iOS中的代理模式，与我们谈的策略模式有什么关系吗？
在iOS中，系统大量使用代理模式来传递消息，告诉你某些事件发生了，你可以在代理方法里添加响应代码。代理模式也是通过协议暴露接口，也是通过组合方式供主体调用，系统也不想知道你如何响应，只管调用。
下面给出策略模式正式定义：
