## 瘦身Controller
`MVC`中最大的问题在于`C`层负担了太多的业务，所以导致`Controller`过大。那么将一些不属于的`Controller`业务的逻辑分离到其他层中是主要的解决思路。iOS的`MVC`模式也被称作`重控制器模式`，这是在实际开发中，我们可以看到`V`和`C`难以相互独立，这两部分总是紧紧的粘合在一起的：
[](http://sindrilin.com/images/MVC%E6%9E%B6%E6%9E%84%E6%9D%82%E8%B0%88/3.jpeg)
在iOS中，`Controller`管理着自己的视图的生命周期，因此会和这个视图本身产生较大的耦合关系。这种耦合最大的表现在于我们的`V`总是几乎在`C`中创建的，生命周期由`C`层来负责，所以对于下面这种视图创建代码我们并不会觉得有什么问题：
~~~
//ViewController.m
- (void)viewDidLoad {
[super viewDidLoad];
UIButton *btn = [[UIButton alloc] initWithFrame: CGRectMake(20, 60, self.view.bounds.size.width - 40, 45)];
[btn setTitle: @"点击" forState: UIControlStateNormal];
[btn addTarget: self action: @selector(clickButton:) forControlEvents: UIControlEventTouchUpInside];
[self.view addSubview: btn];
}
~~~
但是按照业务逻辑来说，我们可以在`Controller`里面创建视图，但是配置的任务不应该轻易的放在`C`层。因此，这些创建工作完全可以使用视图的`category`来实现配置业务，对于常用的控件你都可以尝试封装一套构造器来减少`Controller`中的代码：
~~~
@interface UIButton(LXDDesignedInitializer)
+ (instancetype)buttonWithFrame: (CGRect)frame text: (NSString *)text;
+ (instancetype)buttonWithFrame: (CGRect)frame text: (NSString *)text textColor: (UIColor *)textColor;
+ (instancetype)buttonWithFrame: (CGRect)frame text: (NSString *)text textColor: (UIColor *)textColor fontSize: (CGFloat)fontSize target: (id)target action: (SEL)action;
+ (instancetype)buttonWithFrame: (CGRect)frame text: (NSString *)text textColor: (UIColor *)textColor fontSize: (CGFloat)fontSize cornerRadius: (CGFloat)cornerRadius;
+ (instancetype)buttonWithFrame: (CGRect)frame text: (NSString *)text textColor: (UIColor *)textColor fontSize: (CGFloat)fontSize cornerRadius: (CGFloat)cornerRadius target: (id)target action: (SEL)action backgroundColor: (UIColor *)backgroundColor;
+ (instancetype)buttonWithFrame:(CGRect)frame text:(NSString *)text textColor:(UIColor *)textColor fontSize: (CGFloat)fontSize cornerRadius: (CGFloat)cornerRadius target: (id)target action: (SEL)action image: (NSString *)image selectedImage: (NSString *)selectedImage backgroundColor: (UIColor *)backgroundColor;
@end
~~~
此外，如果我们需要使用代码设置视图的约束时，`Masonry`大概是减少这些代码的最优选择。视图配置代码是我们瘦身`Controller`的一部分，其次在于大量的代理协议方法。因此，使用`category`将代理方法实现移到另外的文件中是一个好方法：
~~~
@interface ViewController (LXDDelegateExtension)<UITableViewDelegate, UITableViewDataSource>
@end
@implementation ViewController(LXDDelegateExtension)
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
//configurate and return cell
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
//return rows in section of cell number
}
@end
~~~
这种方式简单的把代理方法挪移到`category`当中，但是也存在着一些缺点，因此适用场合会比较局限：
* 在`category`中不能访问原类的私有属性、方法。这点`Swift`要超出`OC`太多
* 在减少原类的代码量的情况下实际上使得整个项目结构读起来更加复杂
笔者在通过上述的方式分离代码之后，控制器层的代码量基本可以得到控制。当然，除了上面提到的之外，还有一个小的补充，我们基本都使用`#pragma mark`给控制器的代码分段，一个比较有层次的分段注释大概是这样的：
~~~
#pragma mark - View Life
//视图生命周期
#pragma mark - Setup
//创建视图等
#pragma mark - Lazy Load、Getter、Setter
//懒加载、Getter和Setter
#pragma mark - Event、Callbacks
//事件、回调等
#pragma mark - Delegate And DataSource
//代理和数据源方法
#pragma mark - Private
//私有方法
~~~
认真看是不是发现了其实很多的业务逻辑我们都能通过`category`的方式从`Controller`中分离出去。在这里我非常同意[Casa](http://casatwy.com/)大神的话：`不应该出现私有方法`。对于控制器来说，私有方法基本都是数据相关的业务处理，将这些业务通过`category`或者策略模式分离出去会让控制器更加简洁
