前言

对于单元测试一开始我是拒绝的。单元测试是一个什么东东，因为我喜欢做iOS开发是因为喜欢写APP的啊，一切和这一目标不相干的东西我没兴趣啊，所以从事iOS开发几年都没去深入学习过单元测试（主要是之前单位没这要求）。看到我的优点木有：目标性很强，嗯，记住我的优点，请忽略我拒绝学习边缘知识的缺点。但是最近被总监要求负责单元测试的探索和落地，我义（勉）不（为）容（其）辞（难）地扛起了夺取桥头堡的重任。我愿意把单元测试比作一位好姑娘，随着对这个姑娘的不断的了解和接触，我发现自己逐渐爱上了她，她有着独立知性的气质，有着完美丰满的身材，有着自我成长过程中不断丰富而且深刻的阅历。她是如此地完美的，让我神魂颠倒，夜不能寐，我想为她写诗（可惜没有文学细胞），我想为她写歌（可惜没有艺术细胞），我想为她写书立传（可惜没有写作天赋）。讲真：有木有有眼无珠的出版社愿意邀约？我真的想写一本单元测试的书，我先写几篇关于的她的文章，您看看我有没有出这本书的潜力。

我先来给你介绍下这位姑娘。

单元测试的魅力

每个男人都有过自己喜欢的女孩，可能还有多个，他们可能有你喜欢的共同特质，比如有人喜欢个子高的，有人喜欢小巧的，也有喜欢丰满的，有人喜欢可爱的，有人喜欢野蛮的，也有喜欢……此处省略各种奇葩极端偏好，毕竟人各有所好嘛。但身为一名合格的程序员，你理想的中的女神，如果她有如下优点，一定会让你爱的无法自拔：

1.她能让你更自信。帮助你编写高质量代码、减少bug。

如果大家分析一下我们bug原因的构成，我想有会有一部分bug的原因是开发人员在编写工作代码的时候没有考虑到某些case或者边际条件。造成这种问题的原因很多，其中很重要的一个原因是我们对工作代码所要完成的功能思考不足，而编写单元测试，特别是先写单元测试再写工作代码就可以帮助开发人员思考编写的代码到底要实现哪些功能。例如实现一个简单的用户注册功能的业务类方法，用单元测试再写工作代码的方式来工作的话开发人员就会先考虑各种场景相关，例如正常注册、用户名重复、没有满足必要的填写内容……等等，之后就会编写相关的测试用例。编写单元测试代码的过程就是促使开发人员思考工作代码实现内容和逻辑的过程，之后实现工作代码的时候，开发人员思路会更清晰，实现代码的质量也会有相应的提升。

2.她能提提升你的战斗力。帮助你提升代码的反馈速度，减少重复工作，提高开发效率。

开发人员实现某个功能或者修补了某个bug，如果有相应的单元测试支持的话，开发人员可以马上通过运行单元测试来验证之前完成的代码是否正确，而不需要反复通过编译运行simulator、等待应用启动、通过输入数据等繁琐的步骤来验证所完成的功能。用单元测试代码来验证代码和通过发布应用以人工的方式来验证代码这两者的效率差很多，所以单元测试其实还能节约人力成本。

3.她的存在让你轻松愉快。保证你最后的代码修改不会破坏之前代码的功能。

项目越做越大，代码越来越多，特别涉及到一些公用接口之类的代码或是底层的基础库，谁也不敢保证这次修改的代码不会破坏之前的功能，所以与此相关的需求会被搁置或推迟，由于不敢改进代码，代码也变得越来越难以维护，质量也越来越差。而单元测试就是解决这种问题的很好方法（不敢说最好的）。由于代码的历史功能都有相应的单元测试保证，修改了某些代码以后，通过运行相关的单元测试就可以验证出新调整的功能是否有影响到之前的功能。当然要实现到这种程度需要很大的付出，不但要能够达到比较高的测试覆盖率，而且单元测试代码的编写质量也要有保证。

4.她能为你排忧解难，永远做你的依靠。让你的代码维护更容易。

由于给代码写很多单元测试，相当于给代码加上了规格说明书，开发人员通过读单元测试代码也能够帮助开发人员理解现有代码。很有Open Source的项目(如，AFNetworking, FMDB,喵神的VVDoucment等)都有相当量的单元测试代码，通过读这些测试代码会有助于理解生产源代码。

5.她甘心做你坚强的后盾，在你卖命打拼时无后顾之忧。她有助于改进代码质量和设计。

除了那些大拿们编写的代码，我相信很多易于维护、设计良好的代码都是通过不断的重构才得到的。虽然说单元测试本身不能直接改进生产代码的质量，但它为生产代码提供了“安全网”，让开发人员可以勇敢地改进代码，从而让代码的clean和beautiful不再是梦想。

我这么辛苦把它吹的这么有魅力，要是你作为程序员还不想见见她，wakao,我猜你不正常，有必要做个自身能力检查。如果你跟我一样是一个正常人，下面我就暂不收费，带你远远的瞧上一瞧这位美女，看看她到底长什么样子。

iOS单元测试初探

维基百科上的对她解释：“在计算机编程中，单元测试（又称为模块测试, Unit Testing）是针对程序模块（软件设计的最小单位）来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中，一个单元就是单个程序、函数、过程等；对于面向对象编程，最小单元就是方法，包括基类（超类）、抽象类、或者派生类（子类）中的方法。”。

通常来说，程序员每修改一次代码就会修改某个单元，那我们就可以对这个单元做修改的验证（单元测试），在编写程序的过程中前后很可能要进行多次单元测试，以证实程序达到软件规格书（产品需求）要求的工作目标，而且没有程序错误。虽然单元测试不是什么必须的，但也不坏，这牵涉到项目管理的政策决定（说白了，你没有她也能活，但是只能自己左手写代码，右手……当然也是写代码，作为程序员怎么可以一只手敲代码呢）。

1.了解XCode中的单元测试

在XCode7中新建一个工程的时候，会默认带一个用于单元测试的target，其名字为工程名加Test后缀，并且文件名也以Test结尾。你会发现已经有了一个默认的测试用例。

创建项目后，默认会给我们创建一个和bundle名称+Tests.m的测试类，它包含的默认代码含义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

  - (void)setUp {
       [super setUp];
       // Put setup code here. This method is called before the  invo cation of each test method in the class.
      //初始化的代码，在测试方法调用之前调用
}

- (void)tearDown {
        // Put teardown code here. This method is called after the invocation of each test method in the class.
       // 释放测试用例的资源代码，这个方法会每个测试用例执行后调用
       [super tearDown];
}

- (void)testExample {
           // This is an example of a functional test case.
           // Use XCTAssert and related functions to verify your tests produce the correct results.
           // 测试用例的例子，注意测试用例一定要test开头
       
}

- (void)testPerformanceExample {
         // This is an example of a performance test case.
         // 测试性能例子，有Instrument调试工具之后，其实这个没毛用。
         [self measureBlock:^{
         // Put the code you want to measure the time of here.
         // 需要测试性能的代码
          }];
}

2.写一个简单的测试用例

在testExample方法中输入

1
2
3
4
5
6
7

- (void)testExample {
    // This is an example of a functional test case.
    // Use XCTAssert and related functions to verify your tests produce the correct results.
    NSLog(@"开始爱上单元测试的第一个单元测试测试");
    NSString *test = @"这是我的第一个单元测试";
    XCTAssertTrue([test isEqualToString:@"初来乍到，就想测试成功，没门"]);
}

然后按快捷键Command + U进行单元测试，这个快捷键是全部测试。可以看到如下结果界面：

由于我们使用了断言XCTAssetTrue,它用来比较一个表达式是否为真，显然这个表达式是返回false的，所以这个测试用例肯定通过不了嘛。

我们也可以点击播放按钮，测试某个测试用例。

3.XCTest常见的断言

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

XCTFail(format…) 生成一个失败的测试；
 
XCTAssertNil(a1, format...)为空判断，a1为空时通过，反之不通过；
 
XCTAssertNotNil(a1, format…)不为空判断，a1不为空时通过，反之不通过；
 
XCTAssert(expression, format...)当expression求值为TRUE时通过；
 
XCTAssertTrue(expression, format...)当expression求值为TRUE时通过；
 
XCTAssertFalse(expression, format...)当expression求值为False时通过；
 
XCTAssertEqualObjects(a1, a2, format...)判断相等，[a1 isEqual:a2]值为TRUE时通过，其中一个不为空时，不通过；
 
XCTAssertNotEqualObjects(a1, a2, format...)判断不等，[a1 isEqual:a2]值为False时通过；
 
XCTAssertEqual(a1, a2, format...)判断相等（当a1和a2是 C语言标量、结构体或联合体时使用,实际测试发现NSString也可以）；
 
XCTAssertNotEqual(a1, a2, format...)判断不等（当a1和a2是 C语言标量、结构体或联合体时使用）；
 
XCTAssertEqualWithAccuracy(a1, a2, accuracy, format...)判断相等，（double或float类型）提供一个误差范围，当在误差范围（+/-accuracy）以内相等时通过测试；
 
XCTAssertNotEqualWithAccuracy(a1, a2, accuracy, format...) 判断不等，（double或float类型）提供一个误差范围，当在误差范围以内不等时通过测试；
 
XCTAssertThrows(expression, format...)异常测试，当expression发生异常时通过；反之不通过；（很变态） XCTAssertThrowsSpecific(expression, specificException, format...) 异常测试，当expression发生specificException异常时通过；反之发生其他异常或不发生异常均不通过；
 
XCTAssertThrowsSpecificNamed(expression, specificException, exception_name, format...)异常测试，当expression发生具体异常、具体异常名称的异常时通过测试，反之不通过；
 
XCTAssertNoThrow(expression, format…)异常测试，当expression没有发生异常时通过测试；
 
XCTAssertNoThrowSpecific(expression, specificException, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过；
 
XCTAssertNoThrowSpecificNamed(expression, specificException, exception_name, format...)异常测试，当expression没有发生具体异常、具体异常名称的异常时通过测试，反之不通过

特别注意下XCTAssertEqualObjects和XCTAssertEqual。
XCTAssertEqualObjects(a1, a2, format…)的判断条件是[a1 isEqual:a2]是否返回一个YES。XCTAssertEqual(a1, a2, format…)的判断条件是a1 == a2是否返回一个YES。对于后者，如果a1和a2都是基本数据类型变量，那么只有a1 == a2才会返回YES。

结尾

点到为止，入门就是入门，让你稍微有个了解。就像给你介绍一个美女，我会给她带朦胧的面纱，等你开个好价钱（点个赞）之后我才会一步一步揭开它的面纱，(bie四声)着急，好东西就要一点点的看看才有味道嘛。后面我会陆续推出单元测试进阶，单元测试实战，单元测试中的各种技巧等系列的文章。

参考文章：

《Using Unit Tests》

《iOS开发：XCTest单元测试（附上一个单例的测试代码》

前言

这款插件曾经被我扔到了垃圾堆，直到最近UI部门要联调App,为了改一个像素，改个颜色，我不得不修改代码，停止运行，再重启模拟器，再一个页面页面的跳转到调试所在页面，其实崩溃的不是代码不是代码，是我是我是我。。。还好我想起了它，还好有Github，否则我将追悔莫及，恨一万年都不够。今天就跟大家介绍这款神级插件injectionforxcode。

神奇之处

在程序运行过程中插入OC/Swift代码，不需要重启模拟器就可以查看模拟器运行效果。

开门请神

跟安装其他插件的方式一样，推荐使用Alcatraz插件管理器安装。
打开Xcode我们可以看到Product菜单下多出了如下两个选项代表你请神成功了。

召唤神

1.在APP运行过程中修改代码，比如在controller中加入以下方法

1
2
3
4

- (void)injected
{
    NSLog(@"I've been injected: %@", self);
}

2.按下ctrl + =，有没有出现一个加载的进度？？？有的话，说明你插件安装成功，马上你就可以看到控制台打印了I’ve been injected 。是不是很神奇，如果你不这么觉得我就敢说你是神经病。

拜拜神，给你带来财富

现在你可以尝试在在代码插入任何代码了，记住按ctrl + =召唤神，让模拟器立刻响应你的代码变化吧，看看神是如何神奇地提高你的调试效率的。

它为什么这么神

它通过解析应用的build日志来判断源代码文件上次是怎么被编译的。然后会把这些重新编译一遍包在一个已经通过动态加载器（dynamic loader）注入到应用的bundle里。这个时候其实有两个版本的类在app里，一个原始的和一个修改过的版本。修改过的版本通过转发"swizzled"作用在原来的类上来产生效果。
这个swizzling技巧事实上利用了OC的运行时绑定方法调用和方法实现的来达到目的。这个也可以在Swift中没有标记为final或者private的方法（比如可以被override的方法）。

原理图

提供的技能

它提供了三个实现回调的方法
1.- (void)injected实例方法。它可以让我们按下ctrl + =更新一个类。比如在该方法里调用viewDidLoad方法，就可以再次调用控制器的viewDidLoad方法。
2.+ (void)injected类方法，可以让我们更新全局函数。
3.监听名为INJECTION_BUNDLE_NOTIFICATION的通知，因此我们可以让其他类监听该通知。
4.使用tunable_parameters

神是万能的

• 1.我其实还支持Storyboard Storyboard-based iOS projects.
• 2.我其实也可以可视化的调整颜色 collection of tunable parameters
• 3.当你开始注入时，我会在同一个目录下生成一个项目文件：iOSInjectionProject 或者 OSXInjectionProject。这个项目用于注入你的修改到原项目。建议加入.gitignore。
• 4.ctrl+=的快捷键可以在 “Tunable App Parameters”面板里自定义
• 5.如果想在一台设备上使用，参考这个文档patch to your project..
  低调低调，你知道我很神就行了。

神仙下凡时

我再神也要下凡的啊，不要笑话就行啊，看看就得了，敢笑话我？我就让你写的程序一直有bug,一直有一直有Z Z Z 。

• 1.为了防止出现两个单例（之前提到swizzle会创建一个相同的类），shared前缀修饰的类方式不能注入代码。
• 2.dispatch_on_main方法不能注入。
• 3.第三点我看不懂，不知道怎么翻译，可以去Github看起官方原文，不好意西。

找到此神

GitHub :Injection Plugin for Xcode
作者twitter :@orta
作者亲自录的教程（英文） :
https://www.youtube.com/watch?v=uftvtmyZ8TM&feature=youtu.be

补充

给你介绍这么好的东西，你不需要谢谢我，不要给我打赏，千万不要，你要是打赏了，我一定不会。。。手软。

前言

　　最近在看大神Casa的文章《跳出面向对象思想(一) 继承》，脑洞大开。文章给我们展示了一个随着产品需求不断变化的例子，该例子中通过继承实现不同页面的搜索视图和搜索逻辑的代码复用，随着产品需求的演变，最后导致继承的搜索功能层级越来越深，相互依赖越来越严重，最后导致拔出萝卜带出泥，又随着个性化需求的发展，最后代码变得越来越混乱。相信有经验的开发人员都经历过这方面的痛苦。继承对代码复用来说非常好用，但同时继承复用的思路随着产品经理的需求变化会导致项目紧耦合，牵一发而动全身。继承做面向对象的三大特性之一，当然宅正确的时候使用它能发挥巨大价值，但如果不加思索的使用也会带来代码维护和扩展上的灾难。那我们应该在什么情况下使用继承，什么情况下又需要避免滥用继承，并能够有其他方案替代继承实现代码复用的目的呢，这是作为架构师需要掌握的内功，最终达到十八般武艺，样样精通，需要时信手拈来的境界。

适用继承的场合

大神Chris Eidhof的文章[《subclassing》](https://www.objc.io/issues/13-architecture/subclassing/)提到需要自定义UITableViewCell等View视图的时候我们可以使用继承来创建自定义View,这些代码放入子类更合理，不光代码得到更好的封装，也能得到一个可以在工程中重用的组件。Chris Edihof还提到model可以继承来实现了 isEqual: 、hash 、 copyWithZone: 和 description 等方法的类。

Chris Eidhof说的只是继承的几个应用场景，他没有说使用继承的界限。 Casa还提到是否使用继承需要考虑三个点：

• 1. 父类只是给子类提供服务，并不涉及子类的业务逻辑
• 2. 层级关系明显，功能划分清晰，父类和子类各做各的。
• 3. 父类的所有变化，都需要在子类中体现，也就是说此时耦合已经成为需求

在我看来一个很重要的原则就是我们不能脱离cocoa框架开发，所以我们可以继承cocoa的类，以达到快速开发的目的，但是如果没有特殊原因我们写的代码要控制在继承链不增加两层。

不适合继承的场景

我比较同意Casa的观点。当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了，第三层继承正是滥用的开端。确定有必要之后，再进行更多层次的继承。Chris Eidhof也有类似的观点：`In a lot of projects that I’ve worked on, I’ve seen deep hierarchies of subclasses. I am guilty of doing this as well. Unless the hierarchies are very shallow, you very quickly tend to hit limits.`（ 在我工作的许多项目中看到过一些深度继承的项目。当我也这么干的时候，总会感到内疚。除非继承的层次非常浅，否则你会很快发现它的局限性。）

替代继承解决复用需求的解决方案

1.协议（protocols）

　　我经常使用继承来使得对象能够响应某个方法，假设一个APP有播放器（player）对象，它拥有播放（play）方法播放视频，如果APP希望支持YouTube，需要相同几个播放（player）接口，但是方法的实现不同，通过继承实现的代码如下： 　　

1
2
3
4
5
6
7
8
9
10

@interface Player : NSObject

- (void)play;
- (void)pause;

@end

@interface YouTubePlayer : Player

@end

　　这两个类并没有太多共用的代码，它们只不过具有相同的接口。如果这样的话，使用协议可能会是更好的方案。可以这样用协议来写你的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@protocol VideoPlayer <NSObject>

- (void)play;
- (void)pause;

@end

@interface Player : NSObject <VideoPlayer>

@end

@interface YouTubePlayer : NSObject <VideoPlayer>

@end

　　这样，YouTubePlayer类就不必知道 Player类的内部实现了。

2.代理（delegation）

　　再以上面的例子为例，player对象希望在播放的时候执行一些自定义的行为，使用继承也可以轻易的实现：创建个player对象的子类，然后重写play方法，再调用[super play]，再跟着希望执行的行为。但是我们也可以通过的代理的方式更有优雅的实现这个需求：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@class Player;

@protocol PlayerDelegate

- (void)playerDidStartPlaying:(Player *)player;

@end

@interface Player : NSObject

@property (nonatomic,weak) id<PlayerDelegate> delegate;

- (void)play;
- (void)pause;

@end

　　现在在player对象的play方法里，我们可以通过代理属性调用 playerDidStartPlaying：方法，任何使用Player类的对象，可以遵守代理协议，就可以实现自定义的playerDidStartPlaying：方法了，player类依然保持它的通用性和独立性，方便为对外提供服务。代理是非常强大技巧，苹果本身就经常使用。像 UITextField这样的类，有时候你还会想把几个不同的方法分组到几个单独的协议里，比如UITableView—— 它不仅有一个代理（delegate），还有一个数据源（dataSource）。

3.类别（category）

　　我们有时候会给对象添加方法，通过集成的方式当然可以实现，但是不如category的方式来的方便和容易使用，不增加新的类，可复用的价值也更高。 比如我们需要给NSArray添加一个arrayByRemovingFirstObject方法，通过category的方式我们就可以这么做：

1
2
3
4
5
6

@interface NSArray (OBJExtras)

- (void)obj_arrayByRemovingFirstObject;

@end

　　在用类别扩展一个不是你自己的类的时候，在方法前添加前缀是个比较好的习惯做法。如果不这么做，有可能别人也用类别对此类添加了相同名字的函数。那时候程序的行为可能跟你想要的并不一样，未预期的事情可能会发生。

　　使用类别还有另外一个风险，那就是，到最后你可能会使用一大堆的类别，连你自己都会失去对代码全局的认识。假如那样的话，创建自定义的类可能更简单一些。

4.组合（composition）

　　Casa提到我们尽可能用组合替代继承。组合是最强大的替代组合的选项。如果你想复用已经存在的代码，并且不想共享同样的接口，组合是最佳选择。举个例子，假设你要设计一个缓存类：

1
2
3
4
5
6
7

@interface OBJCache : NSObject

- (void)cacheValue:(id)value forKey:(NSString *)key;
- (void)removeCachedValueForKey:(NSString *)key;

@end

　　一个简单的做法就通过继承NSDictionary并且通过调用字典的方法来实现这上面两个缓存方法。

1

@interface OBJCache : NSDictionary

　　但是这样做会带来一些问题。它本来是应该被详细实现的，但只是通过字典来实现。现在，在任何需要一个 NSDictionary 参数的时候，你可以直接提供一个 OBJCache 值。但如果你想把它转为其它完全不同的东西（例如你自己的库），你就可能需要重构很多代码了。 　　

　　更好的方式就是组合了。创建一个缓存类，并添加一个字典的私有属性，对外还是暴露这两个接口，实现的时候就可以通过调用字典属性的方法实现我们使用字典的方法了，这样做可以灵活改变其涉嫌，而该类的使用者恩不用进行重构。

1
2
3
4
5

@interface OBJCache :NSObject

@property (nonmatic, strong) NSDictionary cacheDict;

@end

总结

　　代码复用，尽管他们都可以通过继承实现，但是我们为了在没有耦合需求的时候尽量不要使用继承，而是根据不同场景采用不同复用代码的方式。如果只是共享接口，我们可以使用协议；如果是希望共用一个方法的部分实现，但希望根据需要执行不同的其他行为，我们可以使用代理；如果是添加方法，我们可以优先使用类别（category）；如果是为了使用一个类的很多方法，我们可以使用组合来实现。，如果当初只是出于代码复用的目的而不区分类别和场景，就采用继承是不恰当的。当你发现你的继承超过2层的时候，你就要好好考虑是否这个继承的方案了，第三层继承正是滥用的开端。确定有必要之后，再进行更多层次的继承。我认同Casa的看法：万不得已不要用继承，优先考虑组合等方式。

参考文章：

《跳出面向对象思想(一) 继承》、《subclassing》

前言

　　古老的MVC架构是容易被iOS开发者理解和接受的设计模式，因此在项目中也是应用最多。但是由于iOS开发的项目功能越来越庞大，项目代码也随之不断壮大，MVC的模糊定义导致我们的业务开发工程师很容易把大量的代码写到视图控制器中，行业中对这种控制器有个专业词汇Massive ViewControler（臃肿的视图控制器）。代码臃肿导致可读性可维护性差，而且这种不清晰的设计还有许多的副作用，比如代码重用性差。作为架构师需要关注项目的代码质量。指导业务开发工程师写出高质量，高健壮性，高可用的代码也是很重要的工作。因此需要知道一些为控制器瘦身的技巧，并在项目中帮助业务开发工程师合理的运用它们。本文翻译一篇国外优秀文章：Lighter View Controllers。
示例代码下载地址：JackieHoo’s GitHub

分离数据源(Data Source)等协议(Protocol)

　　瘦身控制器的有效方法之一就是将实现 UITableViewDataSource 协议相关的代码封装成一个类(比如本文中的 ArraryDataSource )。如果你多用几次这个设计，你就会创建复用性高的封装类。
　　举个例子，示例工程中的类 PhotosViewController实现如下数据源方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#pragma mark Private Method

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

# pragma mark UITableViewDataSource

- (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;
}

　　上面示例的数据源的实现都与 NSArray 有关，还有一个方法的实现与 Photo 有关(Photo 与 Cell 呈一一对应关系)。下面让我们来把与 NSArray 相关的代码从 控制器中抽离出来,并改用 block 来设置 cell 的视图。当然你也可以用代理来实现，取决于你的个人喜好。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

@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

现在我们可以控制器中的三个数据源代理方法可以干掉，并且把 控制器的 dataSource 设置为 ArrayDataSource 的实例。

1
2
3
4
5
6
7
8

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;

通过上面的方法，你就可以把设置 Cell 视图的工作从 控制器中抽离出来。现在你不需要再关心indexPath如何与 NSArrary 中的元素如何关联，当你需要将数组中的元素在其它 UITableView 中展示时你可以重用以上代码。你也可以在 ArrayDataSource 中实现更多的方法，比如tableView:commitEditingStyle:forRowAtIndexPath:。

这样做还能带来额外的好处，我们还可以针对这部分实现编写单独的单元测试。不仅仅针对NSArray，我们可以使用这种分离思路处理其他数据容器（比如NSDictionary）。

该技巧同样适用于其他 Protocol ,比如UICollectionViewDataSource 。通过该协议，你可以定义出各种各样的 UICollectionViewCell 。假如有一天，你需要在代码在使用到 UICollectionView 来替代当前的 UITableView，你只需要修改几行 控制器中的代码即可完成替换。你甚至能够让你的 DataSource 类同时实现 UICollectionViewDataSource 协议和UITableViewDataSource协议。

把业务逻辑移至 Model

　　下面是一段位于 控制器中的代码，作用是找出针对用户active priority的一个列表。

1
2
3
4
5
6
7
8

//ViewController.m
- (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 的 Category 中，控制器中的代码将会更简洁、更清晰。

将以上代码移到User+Extension.m中

1
2
3
4
5
6
7

//User+Extension.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 中的代码可以改成这个鬼样子，是不是明显要简洁许多，可读性强很多呢。

1
2
3
4

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

　　实际开发中，有些代码很难移至 model 对象中，但是很明显这些代码与 model 对象有关。针对这种情况，我们可以创建一个 store 类，并把相关代码迁移进去。

创建Store类

　　在这个示例项目工程中，我们有一段用于从本地文件加载数据并解析的代码:

1
2
3
4
5
6
7
8
9
10
11
12
13

- (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 对象来负责。通过将这些代码从 控制器中抽离出来，我们可以更容易复用、测试这些方法、同时让控制器变得更轻巧( Store 对象一般负责数据的加载、缓存、持久化。Store 对象也经常被称作 Service Layer 对象，或者 Repository 对象)。

将网络通信（Web Service）逻辑移至Model层

　　这与上一个主题非常相似：别把 Web Service 相关的代码写在 控制器中，应该把这部分代码抽离出来。并通过方法的回调对数据进行处理。

　　不仅如此，你还可以把处理异常情况的工作也转交给 Store 对象负责。

把视图相关的代码移至View层

　　同样构建视图（尤其是复杂视图）的代码也不应该写在 View Controller （关我毛事啊，我只负责调度和通信啊）中。要么使用Interface Builder ，要么封装一个 Vew 的子类来完成这部分工作。假设现在需要实现自定义一个日期选择器。我们应该新建一个 DatePickerView 的子类来完成构建视图的工作，而不是把这部分工作放在 View Controller中完成。同样的，这将是你的代码更简洁，复用性更强。

　　除了用 code 的形式来实现自定义视图，你也可以使用 Interface Builder 来完成构建自定义视图的工作。很多人都认为 Interface Builder 只能用于为 View Controller 构建视图，其实不然，你可以通过单独的 nib 文件来加载在 Interface Builder中构建的自定义视图。在示例工程当中，我们创建了一个包含了 Photo Cell 视图的 PhotoCell.xib 文件。

如图所示，我们在 view 中创建了属性(无需设置 File’s Owner 对象)并把它们与 Interface Builder 中的视图关联起来。这个方法同样适用于构建其它自定义视图。

通讯

我们在控制器中经常需要与其它控制器、Model 、 View 进行通讯。虽然这本来就是 控制器应该负责处理的事情，但我们依然可以用尽可能少的代码完成我们控制器的负责的工作。

现在已经有很多成熟的方案来建立 控制器与 View 的通讯(例如 KVO 和 fetched results controllers)。然而 控制器之间的通讯目前还没有类似的方案可以借鉴。

在实际开发中，我们经常需要把 遇到需要把控制器持有的一些状态信息，传递到多个控制器的需求。通常我们会将这些状态信息保存在一个对象中然后传递给其他的视图控制器。这部分的瘦身技巧比较复杂，我留在以后再专门讲解吧。

结论

我们已经展示了一些瘦身控制器的方法。作为架构师我们不可能完全照搬这些设计技巧，但我们需要清楚我们这么做的目的，我们只有一个目标:使得代码更易于维护，只要架构师在review代码时时刻关注这个目标，我们可以就可以扩展这些技巧，灵活运用到项目中。通过了解这些方法，我们能够更好的处理好复杂的视图控制器，并且让这些视图控制器的代码更整洁，更清晰。