在文章的最开始,先抛出三个问题:bash
对第一个问题,答案是NO,OC并不存在真正意义上的“私有变量”。咱们来看这样的一段代码:ui
//Teacher.h文件
@interface Teacher : NSObject
@end
//Teacher.m文件
@interface Teacher ()
{
@private NSInteger age; //age为Teacher类的私有变量
}
@end
@implementation Teacher
- (instancetype)init{
if (self = [super init]) {
age = 10;
}
return self;
}
@end
复制代码
Teacher类中存在一个私有变量age,在Teacher的init方法中设置age=10,照理说这个age外界是没法访问的,这一点也符合面向对象语言的封装特性,可是(永远有个可是,敲黑板了,这里是重点),使用KVC技术,咱们能够打破封装特性,代码以下:spa
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
Teacher *t = [Teacher new];
NSLog(@"teacher's age = %@", [t valueForKey:@"age"]);
}
@end
复制代码
运行程序,而后咱们看一下打印结果:code
结论1:只要咱们知道私有成员变量的名字并结合KVC技术,在OC的世界里,根本没有“秘密”😅cdn
虽然KVC的确把面向对象语言撕开了一道口子,可是换个角度想,这道口子同时也给iOS开发者提供了必定的便利性。也就是说,KVC其实是一把双刃剑,用得好,能够在特定场景下为咱们高效解决需求,用得很差,后果一样可怕。对象
例如,当我尝试用KVC访问Teacher类中并不存在的变量“gender”时,程序直接Crash了: blog
咱们分析一下这个Crash,发现是**valueForUndefinedKey:**方法抛出的异常,咱们试着来实现一下这个系统方法,不妨先返回nil,而后再运行一次: 开发
这一次系统没有Crash,并且gender打印了(null)。从结果上能够看出,当KVC找不到gender这个值时,会来到valueForUndefinedKey:方法,给咱们最后一次机会,只要咱们返回一个值来回应KVC对gender的访问,即使是返回nil,系统也不至于Crash。get
结论2:KVC是一把双刃剑,有利也有弊,经过重写valueForUndefinedKey:方法,能够规避使用KVC的弊端string
字不如图,咱们直接看KVC的调用流程图:
前面的解释里,我屡次用了“符合条件”这个词,怎么理解?仍是用图说话,KVC会按照下图所示的格式,逐一去寻找对应的方法或者成员变量,感兴趣的能够本身写个demo试试看。
结论3:KVC的调用流程分三步走,先找方法,再找成员变量,最终还找不到,就直接调用valueForUndefinedKey:来抛出异常。