IT技术互动交流平台

路由跳转的思考

来源:IT165收集  发布日期:2016-06-14 22:05:40

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

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

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

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

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

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

        • 中间人
        • urlroute
Tag标签: 路由  
  • 专题推荐

About IT165 - 广告服务 - 隐私声明 - 版权申明 - 免责条款 - 网站地图 - 网友投稿 - 联系方式
本站内容来自于互联网,仅供用于网络技术学习,学习中请遵循相关法律法规