三个问题
在文章的最开始，先抛出三个问题：
- OC是否存在真正意义上的“私有变量”？
- 为什么苹果要提供KVC这门技术？
- KVC的完整调用流程是怎么样的？
使用KVC访问“私有变量”
对第一个问题，答案是NO，OC并不存在真正意义上的“私有变量”。我们来看这样的一段代码：
//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技术，我们可以打破封装特性，代码如下：
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
Teacher *t = [Teacher new];
NSLog(@"teacher's age = %@", [t valueForKey:@"age"]);
}
@end
运行程序，然后我们看一下打印结果：
结论1：只要我们知道私有成员变量的名字并结合KVC技术，在OC的世界里，根本没有“秘密”😅
为什么苹果要提供KVC给我们？
虽然KVC的确把面向对象语言撕开了一道口子，但是换个角度想，这道口子同时也给iOS开发者提供了一定的便利性。也就是说，KVC实际上是一把双刃剑，用得好，可以在特定场景下为我们高效解决需求，用得不好，后果同样可怕。
例如，当我尝试用KVC访问Teacher类中并不存在的变量“gender”时，程序直接Crash了：
我们分析一下这个Crash，发现是**valueForUndefinedKey:**方法抛出的异常，我们试着来实现一下这个系统方法，不妨先返回nil，然后再运行一次：
这一次系统没有Crash，而且gender打印了（null）。从结果上可以看出，当KVC找不到gender这个值时，会来到valueForUndefinedKey:方法，给我们最后一次机会，只要我们返回一个值来回应KVC对gender的访问，即便是返回nil，系统也不至于Crash。
结论2：KVC是一把双刃剑，有利也有弊，通过重写valueForUndefinedKey:方法，可以规避使用KVC的弊端
KVC的调用流程
字不如图，我们直接看KVC的调用流程图：
- 第一步，先去寻找“符合条件”的访问方法，即getter方法，如果存在那就调用，并结束流程；
- 第二步，如果第一步找不到对应的访问方法，再调用系统的accessInstanceVariablesDirectly方法，该方法默认返回YES，它本质上是一个开关，用来控制是否要继续寻找“符合条件”的成员变量。
- 如果accessInstanceVariablesDirectly返回YES，继续找“符合条件”的成员变量，找到了就返回其值，并结束流程，找不到就进入第三步；
- 如果accessInstanceVariablesDirectly返回NO，不需要找成员变量，直接判定这个key值为UndefinedKey（未定义的key值，也就是该key不存在），此时流程来到第三步；
- 第三步，调用valueForUndefinedKey:方法，并抛出Crash异常，结束调用。但如果我们重写了valueForUndefinedKey:方法，并返回一个明确的值给UndefinedKey，则不抛出Crash异常。
前面的解释里，我多次用了“符合条件”这个词，怎么理解？还是用图说话，KVC会按照下图所示的格式，逐一去寻找对应的方法或者成员变量，感兴趣的可以自己写个demo试试看。
结论3：KVC的调用流程分三步走，先找方法，再找成员变量，最终还找不到，就直接调用valueForUndefinedKey:来抛出异常。
总结
- 因为KVC技术的存在，在OC的世界里没有真正意义上的“私有变量”；
- KVC是一把双刃剑，有利也有弊，但通过重写valueForUndefinedKey:方法，可以规避使用KVC的弊端
- KVC的调用流程分三步走，先找方法，再找成员变量，最终还找不到，就直接调用valueForUndefinedKey:来抛出Crash异常。
