关于iOS开发:iOS开发-简化view-controller

55次阅读

共计 3620 个字符,预计需要花费 10 分钟才能阅读完成。

导语

view controller 通常是一个我的项目中最宏大的文件,因为它外面常常蕴含了不属于它的代码,同时这也使它成为代码中最难以重用的局部。所以为 view controller 瘦身,让其中的代码复用性更强,把相干代码放到正确的中央显得尤其重要。

iOS 开发交换技术群:563513413,不论你是大牛还是小白都欢送入驻,分享 BAT, 阿里面试题、面试教训,探讨技术,大家一起交流学习成长!

将 Data Source 和其余协定拆散

为 view controller 瘦身最无效的办法就是把 UITableViewDataSource 中的代码移动到相干的类中,具体的办法能够参阅《iOS 利用开发 扼要 TableView》中的相干实现。

而更进一步,不只是 TableView,这个办法能够扩大到其余的协定上,比方 UICollectionViewDataSource。如果在开发中抉择应用 UICollectionView 代替 UITableView 时,这个办法能够让你简直不必批改 viewController 中的任何货色,甚至能够让 Data Source 同时反对两个协定,给予了极大的便利性。

将弱业务逻辑移到 Model 中

注:markdown 对代码块的语法是开始和完结行都要增加:“`, 其中 ` 为 windows 键盘左上角

首先是代码,以下的代码是帮忙用户查找优先事项的列表:

-(void)loadPriorities
{
    NSDate *now = [NSDate date];
    NSString *formatString = @”startDate <= %@ AND endDate >= %@”;
    NSPredicate *predicate = [NSPredicate predicateWithFormat:formatString, now, now];
    NSSet *priorities = [self.user.priorities filteredSetUsingPredicate:predicate];
    self.priorities = [priorities allObjects];
}

然而,如果把这些代码移动到 User 类中会让它变得更加清晰,这时 ViewController.m 中会是:

-(void)loadPriorities
{
    self.priorities = [self.user currentPriorities];
}

而 User + Extensions.m 中则是:

-(NSArray *)currentPriorities
{
    NSDate *now = [NSDate date];
    NSString *formatString = @”startDate <= %@ AND endDate >= %@”;
    NSPredicate *predicate = [NSPredicate predicateWithFormat:formatString, now, now];
    return [[self.priorities filteredSetUsingPredicate:predicate] allObjects];
}

将这些代码移动的根本原因是因为 ViewController.m 是大部分业务逻辑的载体,自身代码的复杂度曾经很高,所以这类跟业务关联不大的代码比方日期转换、图像裁剪、设定过滤器等的操作能够拆散到各自的类中实现,一方面为 viewController 减负,另一方面也能增进代码的复用。

对于这个题目的翻译我斟酌了比拟久的工夫,因为在原文中是 “Move Domain Logic into the Model”,意为“把 畛域逻辑 移到 Model 中”。对于“畛域逻辑 ”一词我进行过讲究,大抵意思为“ 稳固的、不会扭转的逻辑关系 ”,同时在原文中也是应用了 NSPredicate 作为例子援用,而我认为其例子中的代码也是与业务相干的,只不过关联性不大,而且不会轻易改变,所以应用了“ 弱业务逻辑 ”一词代替了“ 畛域逻辑”一词。

把数据处理的逻辑移到服务层

一些代码可能没方法很无效的挪动到 model 中,然而这些代码却和 model 中的代码有清晰的关联,对于这种问题,能够应用 Store。比方在上面的代码中,viewController 须要实现从一个文件中获取一些数据,并对其进行操作:

-(void)readArchive 
{
    NSBundle *bundle = [NSBundle bundleForClass:[self class]];
    NSURL *archiveURL = [bundle URLForResource:@”photodata” withExtension:@”bin”];
    NSDate *data = [NSData dataWithContentsOfURL:archiveURL options:0 error:NULL];
    NSKeyedUnarchiver *unarchiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:data];
    _users = [unarchiver decodeObjectOfClass:[NSArray class] forKey:@”users”];
    _photos = [unarchiver decodeObjectOfClass:[NSArray class] forKey:@”photos”];
    [unarchiver finishDecoding];
}

事实上,view controller 不须要分明怎么实现这些货色,而应该将这些解决交给一个 store object 来实现。

通过对代码进行拆散,可能增进代码复用、对代码进行单元测试、放弃 view controller 整洁等。同时可能让 view controller 更多关注于业务自身的内容,把数据的读取、缓存、新建等操作交给服务层来解决。

把网络服务的逻辑移到 Model 层

这与下面提到的十分相似:不要把网络服务的逻辑放到 view controller 中,而应该把它们寄存到不同的类中。

对于 view controller,应该只是应用一个 completion block 来调用这些办法,而把网络申请、错误处理、缓存解决交给这些类来实现

把解决 view 的代码移到 view 层

无论是应用 Storyboard 还是纯代码编写 view,创立简单的 view 的工作不应该交给 view controller。

比方在须要创立一个日期选择器时,更好的办法是把这些代码放到 DatePickerView 中,而不是放到 ViewController 中,和之前一样,是为了复用和简便。至于如何应用 storyboard 对 view 进行设置这里不再赘述。

Communication(通信)

view controller 中最常产生的就是 通信,包含了和 view 层的通信、和 model 层的通信、和其余 view controller 的通信等。只管这是一个 view controller 必须做的事件,这里仍然有方法可能对代码进行缩减。

对于 view controller 和 view、view controller 和 model 之间的通信曾经存在大量的优良教训,比方应用 KVO 键值模式传值,或者应用 Core Data 中的 NSFetchedResultsController 等。然而,对于 view controller 之间的通信的相干办法却比拟少。

比方在我当初做的我的项目中,一个 view controller 须要依据使用者身份的不同(家长/老师)来对 view controller 的 state 进行不同的设置,而这个 view controller 又在不同的 state 下与不同的 view controller 通信,传递不同的值。在这种状况下 view controller 中的代码会变得相当臃肿和凌乱,所以正确的做法是把这些不同的 state 放到不同的 object 外面,再把它们传给 view controller,让它们依据这个 state 来进行设置和批改,使咱们不再须要被累赘的委托办法搞得非常凌乱。

而在另一种状况下,各个 view controller 之间的跳转逻辑十分复杂,存在着重大的横向依赖,在这种状况下就不合适应用一般的页面跳转模式,而应该应用“中介者模式”,创立一个 coordinator controller,让它来治理页面跳转的逻辑。

论断

事实上当初有各种各样的办法为 view controller 减负,它们无一例外都是向着一个指标后退:写出可保护的代码,只有把这些办法灵活运用,熟记于心,能力真正防止弄出轻便而又难以保护的 view controller。

正文完
 0