设计模式是一个处理软件设计中常见问题的解决方法，并可以重复使用。它向开发者提供了设计模板，使开发者更容易写出逻辑清晰、具有可复用性的代码。它还可以使代码具有松耦合性，能让开发者轻松的更新或替换项目中使用的组件。设计模式相当于软件开发的保险单，保险的运作原理就是现实祝福小额保险，以避免日后可能出现巨大的损失。设计模式的优点很多，但是也有一定的局限性。本质上来，设计模式就是别人在他们的项目中遇到的问题的解决方案。在开篇之前，请认清楚：设计模式是避免或解决问题的起点，而不是为了某一个问题量身定制的解决方案。但是这并不意味着他们没用，只是确实需要花费一些精力对他们进行改造，以适合我们自己的项目。有些程序员将设计模式奉做不可变的发哦。这些人是模式热爱着，他们把模式当做最佳实践来推广。这种做法很不妥，使用不必要的模式而对项目作出的更改，都是完全没有抓住问题的关键行为。 当然说到这里，笔者本文并不是来讽刺设计模式，确实讲解各种设计模式。只是想在开篇之前说清楚一些很重要的问题。接下来的一些文章笔者主要从swift的角度来介绍实际开发中的设计模式。
简单的例子说明设计模式的好处
其实很多设计模式在实际开发中我们都有使用到，抛开那些常见的设计模式来说,如：单例、观察者等。实际上还有一些十分常见的设计模式，但是对于那些没有系统的学习过设计模式的程序员而言，他们很有可能不知道有些经常使用的东西原来是一种设计模式。如对象模板模式和原型模式，可能乍一听这两个词汇感觉很高大上，实际上那怕是一个刚刚入门的开发人员就已经接触过这两种设计模式。所谓的对象模板模式就是使用类或者结构体作为数据类型及其逻辑的规范。创建对象时使用模板，并在初始化时完成数据赋值。赋值时，要么使用模板中的默认值，要呢使用类或者结构体的初始化器来提供数值。所谓的原型模式就是简单的深浅拷贝的问题。
先来思考一个问题，swift中的元组是很有意思的特性，但是为何实际开发中并没不是很多数据源是通过元组来赋值完成的。设想一个电商类项目的tableView中，每一个cell对应一个商品信息，展示的商品信息包含价格、图片、商品名称信息。在使用swift元组的时候，针对每一个cell的数据源我们可以这样使用元组。
var products = [("14","http.......","扫把")，("14","http.......","jact")，("14","http.......","风扇")]
但是往往实际开发中我们并不会这样使用。试想，此时如果想在cell 中添加一些信息，那么数据源就要大改。实际上这种方式已经违背了设计模式的理念。当一个组件依赖另一个组件的内部实现时，也就是说当无法在不更新一个组件的情况下修改组件时，这两个组件就是紧耦合的。cell对元组结构的依赖意味着，当cell要求更多的数据的时候，cell同元组紧密的耦合在一起了。当元组发生变化的时候，所有依赖它的部分都要进行相应的修改。
设计模式结构
总体来说设计模式分为三大类：创建型、结构型、行为型。
创建型模式：对象模板模式、工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
接下来，笔者将一一介绍这些设计模式。将会从是什么、何时使用以及有那些常见问题来具体的介绍设计模式。不定时更新！！！！
设计模式的总原则
总原则：开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。
设计模式的六大原则
1、单一职责原则
不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
2、里氏替换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科
历史替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。
5、迪米特法则（最少知道原则）（Demeter Principle）
就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
6、合成复用原则（Composite Reuse Principle）
原则是尽量首先使用合成/聚合的方式，而不是使用继承。
原型设计模式(构建型)的讲解------（开篇文中的一些干货）
作为设计模式的开篇文章理应带上一点点干货，而不是一味地讲解一些大道理，应结合实际说明具体的涉及模式，以及在实际开发中是如何应用的。
关于是什么的问题？
原型模式通过克隆已有的对象来创建新的对象，已有的对象即为原型。
有什么优点的问题？
使用该模式可以将创建对象的代码隐藏，组件无须知道创建新的对象需要使用到那些类或结构体，不用了解创建它的一些细节问题。另外，每次初始化一个新的对象都要耗费一定的时间和系统资源，使用这个模式可以避免重复的耗时过程。
何时使用该模式？
当你需要创建新的实例但又不想依赖初始化器的时候，就可以使用这个模式。
有哪些陷阱？
最主要的一个陷阱就是在克隆原型的时候，可能会选择错误的复制类型。复制可分为深复制和潜复制这个一定要区分好。
使用swift如何实现类似OC的copy函数？
众所周知swift中，class是引用类型，结构体是值类型，那么对于swift中的class而言如何实现值类型？给所有的对象增加引用是面向对象编程的一个重要部分，但这不符合原型模式。为了支持克隆，Foundation框架中定义了NSCoping协议，在协议中你可以说明如何复制对象。另外有一点需要注意，为了使用NSCoping协议，必须让所使用的类继承自NSObject类，因为NSObject定义了copy方法。除此之外，还要知道NSCopying协议定义了一个copyWithZone方法，复制对象时将会调用此方法。复制的机制有实现该协议的类负责实现。具体实现代码如下：
class Person: NSObject,NSCopying {
var name:String?
var age:Int?
init(name:String, age:Int){
self.name = name
self.age = age
}
func copy(with zone: NSZone? = nil) -> Any {
return Person(name: self.name!, age: self.age!)
}
}
当外部按照如下方式调用的时候，会发现在更p2的name属性的时候，p1的name属性并没有发生改变，因为此时p2是p1的复制副本，所以不会影响p1的name属性。
let p1 = Person(name: "zhengyawei", age: 25)
let p2 = p1.copy() as! Person
p2.name = "bushizhengyawei"
print("\(p1.name) \(p1.age)")//Optional("zhengyawei") Optional(25)
print("\(p2.name) \(p2.age)")//Optional("bushizhengyawei") Optional(25)