深恶痛绝重写setter和getter
2018-01-21 18:53
239 查看
一、写在前面:重写setter和getter的缺点:
1. 没有必要
2. 代码可读性大大降低
3. 容易造成逻辑混乱,引起意想不到的问题
二、没有必要
例子1: 使用重写get方法的方式初始化数据- (NSMutableArray *)dataArray { if (_dataArray == nil) { _dataArray = [NSMutableArray array]; } return _dataArray; }
对于现在的处理器,这样做没有任何意义,并且需要写更多的代码,占更多的行数,这些在阅读代码时会造成一定程度的不便。
二、代码可读性大大降低
例子2:使用重写get方法的方式初始化视图- (UITableView *)tableView { if (_tableView == nil) { _tableView = [[UITableView alloc] initWithFrame:CGRectMake(0, 0, 320, 480) style:UITableViewStylePlain]; } return _tableView; }
例2 中只是初始化了一个非常简单的视图,可能需要初始化的是一个较为复杂的视图,这时就会有人说这个是懒加载的。
我非常同意对于复杂视图懒加载的必要性。
但懒加载并不是只有重写get方法一种方式,而重写get方法会使得代码可读性大大降低。这是最令我抓狂的事情了。
开发中,如果我们需要看别人的代码,很多时候我们并不是逐行地看的,而是靠搜索,搜索这个属性在哪里被用到了,搜索这个方法在哪里被调用了。
但如果使用重写get方法的方式,一搜索“.tableView”,可能会有一长溜的结果,如果更不幸,在init或者viewDidLoad等方法中没有使用到“.tableView”的话,你要花不定长的时间来搞明白到底哪次调用时初始化了。
有人可能会说,那你就在所有的地方都打上断点,然后运行一次,看哪里先调用,就是在哪里初始化的。
但是这大大降低了你看代码的速度,有更优的方式,为什么要采取这种方式。
降低可读性的问题,可能写代码的人感受不到,但读代码的人却是深有体会。
四、容易造成逻辑混乱,引起意想不到的问题
代码可读性降低,必然会引起逻辑混乱,虽然两者不是因果关系,但却是如影随形。五、重写getter和setter的代替方案
- (void)createTableView { if (self.tableView == nil) { self.tableView = [[UITableView alloc] initWithFrame:CGRectMake(0, 0, 320, 480) style:UITableViewStylePlain]; } }
相关文章推荐
- property生成属性的时候,同时重写setter与getter方法,那么实例变量不自动生成
- getter,setter都要重写
- iOS-OC为什么需要重写setter或getter方法?
- iOS积累-为什么使用属性之后, 同时重写setter,getter方法会报错
- 重写setter与getter方法以及其使用情况
- MRC下setter、getter方法写法、重写dealloc方法
- myeclipse重写setter、getter、toString以及重构类的快捷键
- OC 语言- 同时重写setter方法或者getter方法会报错
- 同时重写属性的getter/setter方法和readonly的使用
- ios 同时重写setter和getter方法
- 同时重写getter、setter方法,Use of undeclared identifier错误
- 原生js 对象属性监听,对象重写,defineProperty getter setter
- iOS中@Property声明的属性同时重写getter和setter方法报错问题
- 关于重写getter的方法和setter方法
- 深刻理解属性、getter及setter
- ECMAScript5中getter和setter的使用
- getter和setter方法的作用和好处
- Webkit IDL中自定义[命名]属性的获取(Getter)以及设置(Setter)函数
- 002 - Getter和Setter
- KISSY 对属性 getter、setter 的实现,是基于Base完成的