我们都知道解决一个问题有N种解决方式，但在面向对象的设计中如何能做到“高内聚，低耦合”，设计可重用的对象才是我们追求的。正确的设计模式对开发运行流畅的应用的重要性是不言而喻的。这也是考验一个开发者的基本功。目前主要流行的设计模式有：
- 代理模式
- 观察者模式
- 单利模式
- 工厂模式
- 策略模式
- MVC模式
- MVVM模式
- MVP模式
下面我们一起学习一下这几种设计模式：
一、代理模式
代理模式官方定义是：为其他对象提供一种代理以控制对这个对象的访问。
1.委托者：设置代理协议的类
2.代理者：接受委托者代理的类
一般充当代理角色的是Controller，因为view上有一些事件发生，但是不能做出相应的处理，view知道这个事件发生了，但因为他只是一个view不能作出处理，所以要告诉他的代理可能是一个ViewController代他完成这件事。
完整的流程分为5步：
1）.在自定义视图的DelegateView.h文件中定义一个DelegateViewDelegate协议,协议默认的都是必须的实现的方法,可以根据需求来添加可选实现的方法。
2）.定义代理属性,用来存储代理对象。
3）.代理类要服从协议，为DelegateView指定代理对象.(找个代理干活)。
4）.代理类实现协议中的方法.在这只实现了一个必须实现的方法。
5）.委托方通知代理来执行任务.委托方DelegateView通知代理(视图控制器)来执行这个任务。
二、观察者模式
在设计过程中，我们经常会接触到一种情况：一个对象的行为引发其它多个对象相应的行为。这时我们便可以通过观察者模式的设计思想来设计对象模型。
在ios中观察者模式的实现有四种方法：
- NSNotification
- KVO
- Protocol
- Code Block代码块
1）、Notification是一对多的，而delegate回调是一对一的。但是你可以做一个Array来实现对多回调，这个问题的其实意义不大。
2）、Notification - NotificationCenter机制使用了操作系统的对象间通讯功能，而delegate是直接的函数调用。Notification跨度大，而delegate效率可能比较高。
3）、 相较于前两者KVO才是一种真正的观察者模式，它允许你将一个处理函数绑定到某个类的属性，属性发生改变是就会自动触发，不像其他两种需要你手动的发通知。KVO是一种非常灵活的观察机制，广泛应用于界面设计。KVO在另一文中会有介绍。
4）、 Code Block其实就相当于C的函数指针，可以用来做各种回调。我觉得其应当具备最高的效率。使用Code Block要注意的地方就是使用外部变量。在block里直接引用外部变量的话会在block定义的时候复制外部变量的一个拷贝，也就是说得到的是block定义时的值，在block内修改这个值也不会传给外部。要得到实时的数据，或者将数据传出的话需要在相关变量前面加__block即可。
三、 单利模式
单例是一种重要的概念，它是一种极其便利的设计模式，单例就是确保在程序运行过程中只创建一个对象实例，可以用于需要被多次广泛或者说多次使用的资源中。在iPhone SDK中大量使用了单例的概念，iOS开发中常见的系统单例：
UIApplication(应用程序实例)
NSNotificationCenter(消息中心)
NSFileManager(文件管理)
NSUserDefaults(应用程序设置)
NSURLCache(请求缓存)
NSHTTPCookieStorage(应用程序cookies池)
单例模式的优缺点：
优点：
1.提供了应用唯一的实例对象，规范化统一管理资源，即提供了对唯一实例的受控访问。
2.不用再频繁地创建和销毁对象，从而提高了系统的性能和节约系统资源。
3.避免对共享资源的多重占用。
缺点：
1.由于单利模式中没有抽象层，因此单利类的扩展有很大的困难。
2.单利类的职责过重，在一定程度上违背了“单一职责原则”。
3.单例从创建后到彻底关闭程序前都会一直存在，如果过多的创建单例无疑浪费系统资源和影响系统效率。
使用GCD方式创建单例：
四、工厂模式
工厂模式的优点：解耦，即封装了对象的创建细节，将对象的创建代码和其他代码进行分离，减少了代码的相干性。
1.工厂模式是一种常用的实例化对象的模式，属于创建型模式的一种。
2.可以把工厂类理解成真正意义上的工厂，工厂是用来生产东西的，实例化对象实际上就像生产东西一样，我们可以把对象的创建放到工厂方法中。
五、 策略模式
什么是策略模式：
策略模式是对算法的包装，是把使用算法的责任和算法本身分隔开来，委派给不同的管理对象。策略模式通常把一个系列的算法包装到一系列的策略类里面，作为一个抽象策略的子类。
实例：排序算法，NSArray的sortedArrayUsingSelector；
五、 MVC模式
MVC是80年代出现的一种软件设计模式，是模型（model），视图（view）和控制（Controller）的缩写。
- 数据Model： 负责封装数据、存储和处理数据运算等工作。
- 视图View： 负责数据展示、监听用户触摸等工作。
- 控制器Controller： 负责业务逻辑、事件响应、数据加工等工作。
优点：
MVC模式能够完成各司其职的任务模式，提高代码的可读性和可移植性，降低耦合度，优化Controller的代码量从而大大提高开发的效率。当程序调试时，如果某一个功能没有按照既定的模式工作，可以很方便的定位到到底是Controller还是View还是Model出了问题，除此之外，在代码管理方面：比如你要修改显示的效果，只需要修改V中的就行，然后按照调理在C中添加相应的方法，多么明确。建议在程序中能多多使用这个模式。
六、 MVVM模式（Model View View-Mode）
一种很好解决Massive ViewController 问题的方法就是将Controller中的展示逻辑抽取出来，放置到一个专门的地方，而这个地方就是viewModel。MVVM衍生于MVC，是对MVC的一种演进，它促进了UI代码与业务逻辑的分离。它正式规范了视图和控制器紧耦合的性质，并引入新的组件。
这里用两张图显示它们的区别:
MVC:
MVVM:
ViewModel：存放各种业务逻辑和网络请求。
七、 MVP模式（Model View Presenter）
- MVP的 V 层是由UIViewController 和UIView 共同组成
- view 将委托presenter 对它自己的操作，（简单来说就是presenter发命令来控制view的交互，要你隐藏就隐藏，叫你show 你就乖乖的show）
- presenter拥有对 view交互的逻辑（就是上面说的意思）
- presenter跟model层通信，并将数据转化成对适应UI的数据并更新view
- presenter不需要依赖UIKit
- view层是单一，因为它是被动接受命令，没有主动能力
presenter 作为业务逻辑的处理者，首先要向Service层拿数据赋值给model，所以它将可以向model层通信。其次，UI的处理权移交给了它，所以它需要与view成通讯，发送命令更新UI。同时，UI的响应将触发业务逻辑的处理，所以view 层向presenter层通讯，告诉他用户做了什么操作，需要你反馈对应的数据来更新UI。这样就完成了从用户交互获得交互反馈到整个业务逻辑。
扫一扫
298
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
