转载

路由跳转的思考

一切脱离业务需求的结构设计都是耍流氓（我觉得我们这小打小闹完全谈不上架构这个词）

那我们先梳理一下我们现在的业务场景

目前我们有一个首要问题是跳转

书架banner是个运营位置，需要灵活可配的 各种跳转
开机弹框也是个运营位置，依然需要 各种跳转
push，更别说了， 各种跳转
H5书城，运营活动H5落地页，通过Bridge还需要 各种跳转

我们现在是怎么做的呢？拿书架banner举例

服务器会下发一个type号，（随便假设）1代表打开webview，2代表打开图书，3代表打开个人中心…等等，相关参数会随着type的不同，下发不同字段，因此代码会长这样

switch (type) {
  case 1:
  {
    //jumping code
    //NSString *url = /*解析对应url字段*/
    //NSString *title = /*解析对应title字段*/
    //NSString *ydwebview = [[ydwebview alloc]init];
    ydwebview.url = url;
    ydwebview.navititle = title;
    [self.navigationController pushViewController:ydwebview animated:YES];

  }
        
    break;

  case 2:
  {
    //balabalaba
  }
    break;

可以看下我们的switch有多恐怖

书架banner跳转有6个switch，其中第一个switch有4种子switch
开机弹窗有2个switch，支持能力弱
push，这可了不得有20个switch
H5bridge跳转，有10+个switch

那我们每次新增加一个功能模块的时候改怎么办呢？

假设新作一个模块叫”英式没品笑话百科”(我很爱看的一个微博号╮(╯_╰)╭)

我们就需要在书架，弹框，push，H5Bridge，四处核心跳转点全都新增代码，先要 import “EnglishJoke.h” ，然后还要新增一个switch，新增一坨跳转viewcontroller的代码

有没有感觉？what the fuck！

我们的代码就好像是这样，一团乱麻。

路由跳转的思考

假如A模块是书架，它本身含有书架banner的跳转代码，所以他需要耦合各种跳转目标。比如跳转到B模块书城，形成了 A==>B

假如B模块是书城，它本身含有书城H5Brdige的跳转代码，所以他也需要耦合各种跳转目标，比如跳转到A模块书架，形成了 B==>A

假如所有模块都有这种蛋疼的跳转其他模块的需求，他们之间相互跳来跳去（没错，有时候需求就是这么的不讲道理），那么我们的代码结构就会如图一样，随着业务结构的逐渐庞大，就会变成一张复杂的蜘蛛网，难以维护。

结构梳理

仔细思考一下，我们的业务需求的最直接痛点所在就是 各种跳转 ，但往深层考虑一下，这里面其实是耦合的问题，这里说的不是业务 逻辑耦合 ，而是 引用耦合 。

逻辑耦合，作为程序员，作为面向对象开发的基本思路，一个业务逻辑模块，做到模块化，不把自己自身的业务逻辑与外部不相干的模块进行混杂，所有都以接口的形式提供给外部调用，这是一个最基本的设计理念，这是没有问题，也是必须要做到的
引用耦合，被抽象成一个模块，外部要使用的时候势必要import这个模块的头文件，再根据头文件的api，进行调用，这无可厚非，但是如果发生这种处理需要统一跳转多个不同模块的逻辑的时候，引用耦合就会显得混乱不好管理

但是面对这种当引用耦合一团乱麻的情况下，在业务逐渐壮大，我们面对着一张复杂的如同蛛网一般的引用关系的时候，我们又该如何去处理？

其实有两种方案，都在被普遍使用