首页 ›运维› 网络学院 › 查看内容

路由跳转的思考

2016-6-13 10:57 1609 0

摘要: 一切脱离业务需求的结构设计都是耍流氓（我觉得我们这小打小闹完全谈不上架构这个词）那我们先梳理一下我们现在的业务场景目前我们有一个首要问题是跳转书架banner是个运营位置，需要灵活可配的各种跳转开机弹框也是 ...

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

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

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

书架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，进行调用，这无可厚非，但是如果发生这种处理需要统一跳转多个不同模块的逻辑的时候，引用耦合就会显得混乱不好管理

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

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