Coordinator and FlowController

[annidy]

Coordinator用于解决App太多View Controller，导致代码难以维护。视频.

通常我们创建一个新的View Controller都是在这种场景

pushViewController在作者看来是一种反设计模式。因为navigationController理论上应该是这个View Controller的父组件，子VC依赖父VC这种不是合理的。我觉得这个说法有些牵强，其实本质问题iOS的这种navigationController的API设计，迫使开发者到处写这种push、present的代码。在视频的开头，作者认为AppDelegate是个不错的地方：全局可访问。不过实际开发时，AppDelegate只限于写苹果定义的delegate，不适合写页面的逻辑。所以在App启动时，引入Coordinator对象管理各个页面的跳转（当然也可以写一些业务逻辑在里面）

Coordinator的职责

在iOS的页面栈设计中，一般都是显示的push出一个VC

线性的VC调用，会出现A依赖B，B依赖C的情况。

改造后，VC不再依赖其它VC。

URLRouter有区别吗？

Router一般只负责把URL解析为VC，不会有业务逻辑。Router一般用在有动态跳转需求的地方，比如WebView。也有一些大型app，也通过这种方式解耦各个业务方。

为了不让Coordinator膨胀以至于难以维护，可以按照业务分拆出各个子对象。

FlowController相比Coordinator，是一种与UIKit联系更紧密的实现方式: Coordinator继承UIViewController/UIResponder = FlowController.

在 onmyway133/blog#106 这篇文章中，有详细对比两种设计方案在实现上的区别。继承UIViewController后，就不需要原有的start方法，因为有很多框架提供的入口可用，比如 viewDidAppear。

FlowController的基本逻辑是利用children controller管理多个子VC，苹果提供add(childController:)接口本意是把一个大页面拆分成多个VC的组合，作者这里借用了这个思想，比如一个页面很复杂，最终可能很大(Big)，但不会Massive(杂乱，依赖混乱)