iOS开发常用设计模式？
- MVC模式
- MVVM模式
- 代理模式
- 单例模式
- 工厂模式
- 装饰者模式
- 观察者模式(KVO和通知中心)
- KVC模式
对MVC的理解
- MVC是最常用的设计模式之一
- MVC通过设置Model, View和Controller三大功能模块, 把一个界面处理事件时所关联的所有对象和方法分配到不同模块
- 在这些模块中, Model模块负责封装数据模型, View模块负责处理界面控件, Controller则作为Model和View的进行交互的中间者
MVC中Model,View, Controller之间如何通信?
- 通信方式:
- model和Controller之间可以互相通信
- view和Controller之间可以互相通信
-
view和model之间无法直接互相通信, 必须通过Controller来进行间接通信
MVC通信方式
对MVVM的理解以及如何实践
- 定义
- Model + View + Controller + ViewModel
- 是对MVC的扩展, 进一步"瘦身"控制器
- 对ViewModel的理解
- ViewModel是Model的一部分, 继承于NSObject
- ViewModel中不能涉及UI类
- ViewModel负责业务逻辑, 包括JSON解析和网络请求等等
- ViewModel处理完业务逻辑后, 只需要把View需要的数据传给Controller
MVC 和MVVM的区别
- MVVM是对MVC的扩展, 可以进一步减少Controller的代码量
- MVVM是将View的业务逻辑(请求数据, 数据解析, 定时器等)从控制器中分离出去，单独由一个类(ViewModel)来处理
对代理模式的理解
- 定义
- 通过定义协议和设置代理, 并让代理实现协议中的方法, 动态为原来的类拓展新的方法
- 使用代理模式的好处
- 解耦
- 有利于代码的封装
- 有利于程序的结构化
使用代理模式的注意事项?
- 避免循环引用
- 代理要遵守代理协议
- @require修饰的协议方法必须实现
对单例的理解
- 定义: 在当前应用程序的生命周期, 当前对象只有一个实例
- 使用单例的好处:
- 节约系统资源
- 该实例易于被外界访问
- 作为全局对象, 可以有效实现数据共享问题 (传值)
单例中如何保证只有一个实例对象
-
ARC中
- 定义一个返回单例对象的类方法
- 重写allocWithZone, 确保不会通过alloc来创建一个新对象
- 重写copyWithZone
- 重写mutableCopyWithZone
-
MRC中
- 定义一个返回单例对象的类方法
- 重写allocWithZone, 确保不会通过alloc来创建一个新对象
- 重写copyWithZone
- 重写mutableCopyWithZone
- 重写release, retain, retainCount, autoRelease, dealloc方法
使用单例模式时要注意什么？
- 单例不适用于变化的对象，如果同一类型的对象总是要在不同场景发生变化，单例就会引起数据的错误。
对工厂模式的理解
- 简单工厂模式 ：通过工厂类集中地创建新的类的一种模式
- 步骤
- 创建一个工厂类，工厂类提供一个创建类的方法
- 在该方法设置类型参数, 根据类型创建对应的类, 并返回
- 示例代码:
- 以下实例通过OperationFactory的operationWithType方法, 根据传入的type类型, 创建并返回对应的类
#import "OperationFactory.h"
#import "Operation.h"
#import "AddOperation.h"
#import "MinusOperation.h"
@implementation OperationFactory
+ (id)operationWithType:(OperationType)type
{
Operation *operation = nil;
if (type == OperationTypeAdd)
{
operation = [[AddOperation alloc] init];
}
else
{
operation = [[MinusOperation alloc] init];
}
return operation;
}
对装饰模式的理解
- 一种动态地给某个对象添加新的功能的设计模式
- 装饰模式相比继承更为灵活， 可以在不必改变原类文件和不使用继承的情况下, 给某个对象而不是整个类添加一些功能
- 步骤:
- 创建一个被装饰者Decorater
- 给Decorater添加装饰者Person属性, 在setter方法中给Person赋值
- 调用装饰者Person的方法( -eat, -sleep)
- 示例代码:
@implementation Decorater
- (void)setPerson:(Person *)person
{
_person = person;
}
- (void)viewDidLoad {
[super viewDidLoad];
Decorater *decorater = [[Decorater alloc] init];
Student *student = [[Student alloc] init];
decorater.person = student;
[decorater.person eat];
Teacher *teacher = [[Teacher alloc] init];
decorater.person = teacher;
[decorater.person eat];
}
工厂模式，装饰模式常用于哪些场景？
- 工厂模式
- 在需要集中地创建多个类的情况下可以使用
- 装饰者模式
- 该模式遵循"多用组合, 少用继承"的设计原则
- 在不想添加类方法也不使用继承的情况下, 如果想动态地添加一个类的功能, 推荐使用装饰者模式
对观察者模式的理解
- 定义对象间的一种一对多的依赖关系，并且当一个对象的状态发生改变的时候，所有依赖于它的对象都会得到通知且自动更新
- 观察者模式常用的方法
- KVO (通过键值观察机制实现)
- NSNotification (通过通知中心实现)
KVO与NSNotification有什么区别?
- 通知是由一个中心对象为所有观察者提供变更通知，通知的内容主要是与程序相关的事件, 如进入后台
- KVO则是被观察的对象直接向观察者发送通知，主要是绑定于特定对象属性的值。
在哪些场景可以使用KVO和NSNotification？
- KVO使用场景:
- 使用在线播放器时, 用KVO监听播放状态
- 需要监听某一个对象的属性值变化时
- NSNotification使用场景:
- 监听程序是否进入后台/前台
- 界面间的反向传值
KVC和KVO是什么, 有什么区别, 使用时需要注意什么？
- 定义:
- KVC 对键值进行改变的代码方法
- KVO 对键值对进行监视、观察的方法
- 区别:
- 使用场景不同
- 使用方法不同
- 底层实现方法不同
- 注意事项:
- KVC在使用
setValueForKey时, 一般Key的值与属性名应该保持一致 - KVO在使用完后,应当移除观察者Observer
- KVC在使用
KVO内部实现原理
- 以Person类为例
Person *p1 = [[Person alloc] init];
[p1 addObserver:self forKeyPath:@"age"
options: NSKeyValueObservingOptionNew
context:nil];
- 内部实现原理
- 动态创建Person类的子类NSKVONotifying_Person
- 修改当前对象的isa指针, 指向-->NSKVONotifying_Person
- 只要调用对象的set,就会调用NSKVONotifying_Person的set方法
- 重写NSKVONotifying_Person的set方法：
- 通知观察者, 属性发生改变
KVC内部实现原理
- KVC底层是通过isa-swizzling技术（类型混合指针机制）来实现属性定位
- 使用setValue：forKey时内部的实现步骤
- 先查找相匹配的setter方法
- 如果找到setter方法，就判断参数类型是否为对象
- 是对象，则赋值成功
- 如果是NSNumber或NSValue等类， 则先把值转为基本数据类，再赋值
- 如果找不到setter方法
- 就根据_key, _isKey, key, isKey的匹配模式匹配相应的实例变量
- 如果匹配到的变量是NSNumber等基本数据烈性， 则先把值转为基本数据类型，再赋值
- 如果setter方法和实例变量都找不到匹配的变量，系统默认执行
setValue:forUndefinedKey方法，如果不重写该方法，就会报出NSUndefinedKeyException的异常
使用KVC和KVO的好处?
- KVC
- 快速整体性赋值 (setValueForKeysWithDict...)
- 可高效地获取到子类的属性值
- KVO
- 能一对多地建立依赖关系, 同时观察多个属性
- 方便的记录变化前的值和变化后的值
- 让代码更简洁清晰并易于维护
一般在项目中哪些地方会用到KVC？
- 使用场景:
- CoreData
- sqlite数据库保存
- 字典转模型
setValuesForKeysWithDictionary
