如何解决控制器臃肿(Lighter View Controllers)

今天面试某某二线大厂的时候,问到了如何解决控制器臃肿的问题,如何抽离代码,感觉答得不是特别好,所以找了一篇国外大神的文章,拜读翻译一下,当做总结啦。 原文

视图控制器通常是iOS项目中最大的文件,它们通常包含了许多非必须代码。视图控制器几乎总是是代码中可重用性最低的部分。我们将研究如何抽取视图控制器代码,使代码可重用以及将代码移动到更合适的位置。
此问题的示例项目位于GitHub上。

分离出Data Source和其他Protocols

减小视图控制器的最重要的一点是获取UITableViewDataSource代码的一部分,并将其移动到自己的类中。如果您不止一次这样做,您将开始看到模式并为此创建可重用的类。
例如,在我们的示例项目中,有一个类PhotosViewController具有以下方法:

# pragma mark Pragma 

- (Photo*)photoAtIndexPath:(NSIndexPath*)indexPath {
    return photos[(NSUInteger)indexPath.row];
}

- (NSInteger)tableView:(UITableView*)tableView 
 numberOfRowsInSection:(NSInteger)section {
    return photos.count;
}

- (UITableViewCell*)tableView:(UITableView*)tableView 
        cellForRowAtIndexPath:(NSIndexPath*)indexPath {
    PhotoCell* cell = [tableView dequeueReusableCellWithIdentifier:PhotoCellIdentifier 
                                                      forIndexPath:indexPath];
    Photo* photo = [self photoAtIndexPath:indexPath];
    cell.label.text = photo.name;
    return cell;
}

很多代码都与数组有关,其中一些特定于视图控制器管理的照片。因此,让我们尝试将与数组相关的代码移动到自己的类中。我们使用一个block来配置单元格,但它也可能是一个delegate,具体取决于您的喜好。

@implementation ArrayDataSource

- (id)itemAtIndexPath:(NSIndexPath*)indexPath {
    return items[(NSUInteger)indexPath.row];
}

- (NSInteger)tableView:(UITableView*)tableView 
 numberOfRowsInSection:(NSInteger)section {
    return items.count;
}

- (UITableViewCell*)tableView:(UITableView*)tableView 
        cellForRowAtIndexPath:(NSIndexPath*)indexPath {
    id cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier
                                              forIndexPath:indexPath];
    id item = [self itemAtIndexPath:indexPath];
    configureCellBlock(cell,item);
    return cell;
}

@end

视图控制器中的三个方法可以使用,您可以创建此对象的实例并将其设置为表视图的数据源。

void (^configureCell)(PhotoCell*, Photo*) = ^(PhotoCell* cell, Photo* photo) {
   cell.label.text = photo.name;
};
photosArrayDataSource = [[ArrayDataSource alloc] initWithItems:photos
                                                cellIdentifier:PhotoCellIdentifier
                                            configureCellBlock:configureCell];
self.tableView.dataSource = photosArrayDataSource;

现在您不必担心将索引路径映射到数组中的位置,并且每次要在表视图中显示数组时都可以重用此代码。您还可以实现其他方法,例如tableView:commitEditingStyle:forRowAtIndexPath:在所有表视图控制器之间共享该代码。
好消息是我们可以单独测试这个类,而不必担心再次编写它。如果您使用除数组之外的其他内容,则适用相同的原则。
此外,这种方法也扩展到其他协议。比如UICollectionViewDataSource。这为您提供了极大的灵活性; 如果在开发过程中由于业务变更需要换用UICollectionView而不是UITableView,那么您几乎不需要在视图控制器中进行任何更改。您甚至可以使您的数据源支持这两种协议。

将域逻辑移动到模型中

以下是视图控制器(来自另一个项目)中的代码示例,该代码应该为用户查找活动优先级列表:

- (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。然后它看起来像这样View Controller.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];
}

有些代码不能轻易地移动到模型对象中,但仍然明显与模型代码相关联,为此,我们可以使用Store:

创建Store类

在我们的示例应用程序的第一个版本中,我们有一些代码从文件加载数据并解析它。此代码位于视图控制器中:

- (void)readArchive {
    NSBundle* bundle = [NSBundle bundleForClass:[self class]];
    NSURL *archiveURL = [bundle URLForResource:@"photodata"
                                 withExtension:@"bin"];
    NSAssert(archiveURL != nil, @"Unable to find archive in bundle.");
    NSData *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];
}

视图控制器不应该知道这一点。我们创建了一个Store对象来完成这个任务。通过将其分离出来,我们可以重用该代码,单独测试它并使我们的视图控制器保持较小。商店可以处理数据加载,缓存和设置数据库堆栈。此存储通常也称为服务层或存储库。
将Web服务逻辑移动到模型层
这与上面的主题非常相似:不要在视图控制器中执行Web服务逻辑。相反,将其封装在不同的类中。然后,您的视图控制器可以使用回调处理程序(例如,block)调用此类上的方法。好的一点是,您也可以在此类中执行所有缓存和错误处理。

将视图代码移动到视图层(xib)

不应在视图控制器中完成构建复杂的视图层次结构。使用接口构建器,或将视图封装到它们自己的UIView子类中。例如,如果您构建自己的日期选择器控件,将它放入DatePickerView类中比在视图控制器中创建整个事物更有意义。同样,这增加了可重用性和简单性。
如果您喜欢Interface Builder,那么您也可以在Interface Builder中执行此操作。有些人认为您只能将它用于视图控制器,但您也可以使用自定义视图加载单独的nib文件。在我们的示例应用程序中,我们创建了一个PhotoCell.xib包含照片单元格布局的应用程序:

如您所见,我们在视图上创建了属性(我们不在此xib中使用File的Owner对象)并将它们连接到特定的子视图。这种技术对于其他自定义视图也非常方便。

通讯

在视图控制器中发生很多其他事情之一是与其他视图控制器,模型和视图的通信。虽然这正是控制器应该做的事情,但它也是我们希望用尽可能少的代码实现的。
在视图控制器和模型对象(例如KVO和获取的结果控制器)之间进行通信有很多很好的解释技术,但是,视图控制器之间的通信通常不太清楚。
我们经常遇到一个视图控制器具有某种状态并与多个其他视图控制器通信的问题。通常,将此状态放入单独的对象并将其传递给视图控制器是有意义的,然后视图控制器都会观察并修改该状态。优点是它都在一个地方,我们最终不会陷入嵌套的委托回调中。这是一个复杂的主题,我们将来可能会将整个问题专门用于此。

结论
我们已经看到了一些创建较小视图控制器的技术。我们不会尽可能地应用这些技术,因为我们只有一个目标:编写可维护的代码。通过了解这些模式,我们有更好的机会获取笨重的视图控制器并使它们更清晰。

你可能感兴趣的:(如何解决控制器臃肿(Lighter View Controllers))