分类
创建型 (Creational)：
单例模式 (Singleton)
结构型 (Structural)：
MVC、装饰者模式 (Decorator)、适配器模式 (Adapter)、外观模式 (Facade)
行为型 (Behavioral)：
观察者模式 (Observer)、备忘录模式 (Memento)
单例模式 - Singleton
在 iOS 中单例模式很常见，UserDefaults.standard、 UIApplication.shared 、 UIScreen.main 、 FileManager.default 这些都是单例模式。
设计模式之王- MVC
模型层 (Model) ：
存储数据并且定义如何操作这些数据。
视图层 (View) ：
负责模型层的可视化展示，并且负责用户的交互，一般来说都是继承自 UIView 这个基类。
控制器 (Controller) ：
控制器是整个系统的掌控者，它连接了模型层和数据层，并且把数据在视图层展示出来，监听各种事件，负责数据的各种操作。
另外：Model-View-ViewModel(MVVM)
装饰者模式 - Decorator
装饰者模式可以动态的给指定的类添加一些行为和职责，而不用对原代码进行任何修改。当你需要使用子类的时候，不妨考虑一下装饰者模式，可以在原始类上面封装一层。
在 Swift 里，有两种方式实现装饰者模式：扩展 (Extension) 和委托 (Delegation)。
扩展
扩展是一种十分强大的机制，可以让你在不用继承的情况下，给已存在的类、结构体或者枚举类添加一些新的功能。最重要的一点是，你可以在你没有访问权限的情况下扩展已有类。这意味着你甚至可以扩展 Cocoa 的类，比如 UIView 或者 UIImage 。
举个例子，在编译时新加的方法可以像扩展类的正常方法一样执行。这和装饰器模式有点不同，因为扩展不会持有扩展类的对象。
委托
装饰者模式的另一种实现方案是委托。在这种机制下，一个对象可以和另一个对象相关联。比如你在用 UITableView ，你必须实现 tableView(_:numberOfRowsInSection:) 这个委托方法。
你不应该指望 UITableView 知道你有多少数据，这是个应用层该解决的问题。所以，数据相关的计算应该通过 UITableView 的委托来解决。这样可以让 UITableView 和数据层分别独立。视图层就负责显示数据，你递过来什么我就显示什么。
适配器模式 - Adapter
适配器把自己封装起来然后暴露统一的接口给其他类，这样即使其他类的接口各不相同，也能相安无事，一起工作。
如果你熟悉适配器模式，那么你会发现苹果在实现适配器模式的方式稍有不同：苹果通过委托实现了适配器模式。委托相信大家都不陌生。举个例子，如果一个类遵循了 NSCoying 的协议，那么它一定要实现 copy 方法。
外观模式 - Facade
外观模式在复杂的业务系统上提供了简单的接口。如果直接把业务的所有接口直接暴露给使用者，使用者需要单独面对这一大堆复杂的接口，学习成本很高，而且存在误用的隐患。如果使用外观模式，我们只要暴露必要的 API 就可以了。
API 的使用者完全不知道这内部的业务逻辑有多么复杂。当我们有大量的类并且它们使用起来很复杂而且也很难理解的时候，外观模式是一个十分理想的选择。
外观模式把使用和背后的实现逻辑成功解耦，同时也降低了外部代码对内部工作的依赖程度。如果底层的类发生了改变，外观的接口并不需要做修改。
举个例子，如果有一天你想换掉所有的后台服务，你只需要修改 API 内部的代码，外部调用 API 的代码并不会有改动。
观察者模式 - Observer
在观察者模式里，一个对象在状态变化的时候会通知另一个对象。参与者并不需要知道其他对象的具体是干什么的 - 这是一种降低耦合度的设计。这个设计模式常用于在某个属性改变的时候通知关注该属性的对象。
常见的使用方法是观察者注册监听，然后再状态改变的时候，所有观察者们都会收到通知。
在 MVC 里，观察者模式意味着需要允许 Model 对象和 View 对象进行交流，而不能有直接的关联。
Cocoa 使用两种方式实现了观察者模式： Notification 和 Key-Value Observing (KVO)。
备忘录模式 - Memento
备忘录模式捕捉并且具象化一个对象的内在状态。换句话说，它把你的对象存在了某个地方，然后在以后的某个时间再把它恢复出来，而不会打破它本身的封装性，私有数据依旧是私有数据。
归档 - Archiving
苹果通过归档的方法来实现备忘录模式。它把对象转化成了流然后在不暴露内部属性的情况下存储数据。
网友评论