iOS开发：关于模块化与路由

说一下iOS应用开发中的模块化跟路由的事情。

前一段时间，一位同事一直怂我折腾这件事，关于组件化。组件化成了今年的热门，然后还有瓜。我大概也看了FRDIntent的邮件的探讨，挺有意思的。

我觉得大家也都认同一点，没有任何一套程序架构是通用的。大家都在谈组件化或者模块化（下文统一用”模块化”），瓜吃到了最后的时候，我觉得争辩的时候都混淆这个了——他们讨论的原本不是同一件事情。一个在说模块化怎么解耦，一个在说路由。

路由是路由，模块化是模块化。二者并不对立。

关于路由

路由本来就是一个提供寻址的功能，你可以使用路由表（或其他映射手段），来减少调用路径的硬编码；如果没有路由，顶多也就是手动写死功能调用的逻辑。但毕竟使用路由，还是可以通过注册/回调来减少一些麻烦。假如用推送的场景举个例子：

在推送的payload中使用一个action的字段来标记推送业务类别，那么可以将各个不同业务的推送消息的处理逻辑，分别抽离成一个个单独的service（遵循特定的推送处理接口），并建立映射表action->service 。当接收到推送时，按约定的格式打包好数据，查找对应的service进行处理即可。

我们建立的映射表也是一种路由。这样的好处是，无论是否添加新的推送业务，推送的核心处理模块无需修改，只需要新增相应的service即可。这是一层解耦。再有，如果旧版客户端接收到了一个新的推送业务，因为映射表查找不到相应的service可以直接忽略了也不会有其他并发症。

跟原先的做法相比，可维护性提高，易于动态调用，并且单独的业务便于测试。

关于模块化

再说到模块化。大家的标题都是“组件化”，但是实际讨论的貌似是“业务模块”或者说“功能模块”？“组件”，Components，更偏向于独立、可重用的系统“零部件”，所以个人觉得业务层面或许称之为“模块”更合适些。按照分层架构，业务模块层会基于下层的基础服务（组件）进行开发。组件处于纵向的层级中，组件的职责相对单一，对上层不能有依赖关系；而业务模块是在整个架构的最上层，模块间存在横向的关系——某种程度来说，业务间存在无可避免的耦合。这个逻辑依赖关系，是业务内置的，是没办法通过软件工程的手段去除的。

这样模块化就更好理解了。要尽量做到高内聚。要面向接口编程，提供接口、依赖接口，尽可能将耦合度降低到内在要求。路由当然也会起到一部分解耦的功用。

说到底，都是通过增加”间接层”来实现。

There is no problem in computer science that can’t be solved by adding another level of indirection.

显式的命名为“Mediator”也好，还是实现成一个“Router”也好，其实不重要。