打算分享一些有争议的话题，并且表达一下我的看法。这是该系列的第一篇，我想讨论的是：类的成员变量应该如何定义？
在 Objective-C 的语言的早期，类的私有成员变量是只能定义在 .h 的头文件里面的。像如下这样：
@interface ViewController : UIViewController {
@private
NSInteger _value;
}
之后，苹果改进了 Objective-C，允许在 .m 里面添加一个特殊的匿名 Category，即没有名字的 Category，来实现增加类的成员变量。像如下这样：
@interface ViewController ()
@property (nonatomic) NSInteger value;
@end
这样的好处是，这些变量在头文件中被彻底隐藏起来了，不用暴露给使用者。
接着，在 2013 年的 WWDC 中，苹果进一步改进了 Objective-C，允许在 .m 的
@implementation 中直接添加类的私有成员变量。像如下这样：
@implementation ViewController {
NSInteger _value;
}
于是，大家对于如何定义私有的成员变量上就产生的分歧。许多人喜欢用匿名的 Category 的方式来定义私有成员变量。但是，我个人更推荐在 @implementation 中直接添加类的私有成员变量。下面我做一些解释。
历史原因
首先早期的 iOS 程序员一定知道，在 2011 年 ARC 被推出之前，Objective-C 是需要手工地管理引用计数的。而对类的所有私有成员使用 self.property 的形式，就可以使编译器为我们自动生成管理引用计数的代码。在 2012 年前，这个 feature 还需要使用 @synthesize 关键字来启用的。于是，苹果通过在代码规范中推荐和强调使用 self.property 的编程习惯，来让大家避免在内存管理中遇到问题。而在 ARC 时代，这个编程习惯带来的优势不再存在了，因为编译器会自动为我们管理引用计数，我们只需要关心不要造成循环引用问题就行了。
省心省事
刚刚说到，在类中完全使用 _property 的方式来访问私有成员变量，是不会有内存管理上的问题的。但是使用 self.property 的方式来访问私有变量是不是也是一样不会有内存管理上的问题呢？确实也是，但是有一点需要注意：我们最好不要在 init 和 dealloc 中使用 self.property 的方式来访问成员变量，这一点是写在苹果的官方文档里的，我在以前的文章里也介绍过。(见：《不要在init和dealloc函数中使用accessor》）
所以，如果你用 self.property 来访问私有成员变量。那么你需要注意，在 init 和 dealloc 中不使用这种方式。这其实对程序员来说是一个负担，你需要不停提醒自己有没有犯错。如果你使用完全的 _property 的方式来访问私有成员变量，就不用想这一类问题了。
关于隐藏
大家知道，self.property 其实是调用了类的 [self property] 方法，所以这其实是有一层方法调用的隐藏，很多时候，我们需要延迟初使化一个类成员的时候，就会把这个成员的初使化方法写在这个 [self property] 方法的实现中。
那么问题来了，当你在阅读别人代码时，看到 self.property 的时候，你会想：这里会不会有一些隐藏的函数实现？于是你需要跳转到其方法实现中去查找。但是在实际开发中，大部分的 property 其实是使用编译器自动生成的 Getter 和 Setter 方法，于是你会找不到实现，这个时候，你才知道：“哦，原来这段代码并没有做自定义的成员初使化工作”。
这种默认的隐藏在代码中多了，会影响代码的阅读和维护。其实大部分的类成员变量都需要在类初使化方法中赋值，大部分的 UIViewController 的成员变量，都需要在 viewDidLoad 方法中赋值。那既然这样，不如直接在相应的方法中用一个名为 setupProperty 方法直接进行初使化。这样的好处是，代码的可读性更好了，self.property 只有需要延迟初使化的情况下才被使用。
关于这个还有一个小故事，我之前 Review 过一个同事的 iOS 端代码，那个同事喜欢把 table view 的数据另外封装成一个类，而我觉得这些数据其实就是一个数组，没必要进行这一层封装，最终我们争论了比较久。我的观点是，一切隐藏都是对代码复杂性的增加，除非它带来了好处，例如达到了代码复用，提高了代码的可维护性等，否则，没有好处的封装只会给代码阅读理解带来成本。就我现在的经历中，大部分的 table view 的数据都可以放在一个数组中，没必要把这个数组封装起来，另外提供一套操作这个数组数据的方法。
简短的代码更易读
_property 的写法比 self.property 更短，也更简单。我认为这样写出来的代码更方便阅读。
执行速度更快，IPA体积更小
我之前从来没想到过这两者之间的速度和应用体积会有很大差别。不过一个同行（来自国外著名的社交网络公司）告诉我，他们公司发现二者还是有不小的差距，如果你们的应用需要做一些深度优化，可以考虑一下把 self.property 换成 _property。但我觉得，大部分应用都应该是不需要做这种深度优化的。
KVO 和 KVC
是的，如果用 _property 这种写法，就不能使用 KVO 和 KVC 了。但是我得反问一下，在一个类的内部，KVO 自己的私有成员变量算是一个好设计吗？我们讲类要”高内聚，低耦合”，KVO 是为了实现观察者模式，让对象之间相互解耦的。如果把 KVO 用在类的内部，KVO 自己的私有成员，我认为其实这不是一个很好的设计。
Computed Properties
在 Swift 中，引入了 Computed Properties 的概念，其实这在 Objective-C 中也有，只是没有专门给它名字。如果一个 property 我们提供了对应的 setter 和 getter，并且没有直接使用其对应的 _property 变量，那么这个 property 就是所谓的 Computed Properties。
是的，在类的内部如果直接使用 _property 形式，也无法使用 Computed Properties 了，但我认为这影响不大。其实 Computed Properties 也就是一层对数据存取的封装，我们另外实现两个函数，分别对应数据的 setter 和 getter 功能，就可以达到同样的效果。
循环引用问题
微博上的@王_晓磊在评论中提到：直接用私有变量有个需要特别注意的地方，在 block 里直接写 _property 相当于 self->_property，虽然没写 self，但是暗含了对 self 的retain，容易造成循环引用。要记得用 weakSelf/strongSelf 大法。
这一点确实是被很多人忽视的，所以我也一并写在这里，感谢他的补充。
写在最后
其实我上面提到的这些问题都是小问题，影响不大。但是代码风格的统一却是大问题。所以不管你们项目中使用的是 self.property 风格还是 _property 风格，问题都不大，但是如果你们同时使用这两种风格，那么就非常不好了。
希望我的这篇文章能让大家了解到在这方面的争论，也希望大家能够在这一点上，在公司内部达成统一。
转载：http://blog.devtang.com/2015/03/15/ios-dev-controversy-1/#qrcode
关于Getter和Setter？
我比较习惯一个对象的"私有"属性写在extension里面，然后这些属性的初始化全部放在getter里面做，在init和dealloc之外，是不会出现任何类似_property这样的写法的。就是这样：
@interface CustomObject()
@property (nonatomic, strong) UILabel *label;
@end
@implement
#pragma mark - life cycle
- (void)viewDidLoad
{
[super viewDidLoad];
[self.view addSubview:self.label];
}
- (void)viewWillAppear:(BOOL)animated
{
[super viewWillAppear:animated];
self.label.frame = CGRectMake(1, 2, 3, 4);
}
#pragma mark - getters and setters
- (UILabel *)label
{
if (_label == nil) {
_label = [[UILabel alloc] init];
_label.text = @"1234";
_label.font = [UIFont systemFontOfSize:12];
... ...
}
return _label;
}
@end
唐巧说他喜欢的做法是用_property这种，然后关于_property的初始化通过[self setupProperty]这种做法去做。从刚才上面的代码来看，就是要在viewDidLoad里面多调用一个setup方法而已，然后我推荐的方法就是不用多调一个setup方法，直接走getter。
嗯，怎么说呢，其实两种做法都能完成需求。但是从另一个角度看，苹果之所以选择让[self getProperty]和self.property可以互相通用，这种做法已经很明显地表达了苹果的倾向：希望每个property都是通过getter方法来获得。
早在2003年，Allen Holub就发了篇文章《Why getter and setter methods are evil》，自此之后，业界就对此产生了各种争议，虽然是从Java开始说的，但是发展到后面各种语言也参与了进来。然后虽然现在关于这个问题讨论得少了，但是依旧属于没有定论的状态。setter的情况比较复杂，也不是我这一节的重点，我这边还是主要说getter。我们从objc的设计来看，苹果的设计者更加倾向于getter is not evil。
认为getter is evil的原因有非常之多，或大或小，随着争论的进行，大家慢慢就聚焦到这样的一个原因：Getter和Setter提供了一个能让外部修改对象内部数据的方式，这是evil的，正常情况下，一个对象自己私有的变量应该是只有自己关心。
然后我们回到iOS领域来，objc也同样面临了这样的问题，甚至更加严重：objc并没有像Java那么严格的私有概念。但在实际工作中，我们不太会去操作头文件里面没有的变量，这是从规范上就被禁止的。
认为getter is not evil的原因也可以聚焦到一个：高度的封装性。getter事实上是工厂方法，有了getter之后，业务逻辑可以更加专注于调用，而不必担心当前变量是否可用。我们可以想一下，假设一个ViewController有20个subview要加入view中，这20个subview的初始化代码是肯定逃不掉的，放在哪里比较好？放在哪里都比放在addsubview的地方好，我个人认为最好的地方还是放在getter里面，结合单例模式之后，代码会非常整齐，生产的地方和使用的地方得到了很好的区分。
所以放到iOS来说，我还是觉得使用getter会比较好，因为evil的地方在iOS这边基本都避免了，not evil的地方都能享受到，还是不错的。
转载：https://casatwy.com/iosying-yong-jia-gou-tan-viewceng-de-zu-zhi-he-diao-yong-fang-an.html
网友评论