IT技術(shu)互動交(jiao)流平台

三分pk10官网

來源︰IT165收集  發布日期(qi)︰2020-02-20 05:55:40

一切脫(tuo)離業務需求的結構設計都是耍流氓(meng)(我覺得我們這小打小鬧完全談不(bu)上架(jia)構這個詞)

那我們先梳理一下我們現在的業務場景

目前我們有一個首要問題是跳轉

  • 書(shu)架(jia)banner是個運營位置(zhi),需要靈活可配(pei)的 各種(zhong)跳轉
  • 開機(ji)彈框(kuang)也(ye)是個運營位置(zhi),依(yi)然需要 各種(zhong)跳轉
  • push,更別說了(liao), 各種(zhong)跳轉
  • H5書(shu)城,運營活動H5落地頁,通過Bridge還(huai)需要 各種(zhong)跳轉

    我們現在是怎麼做的呢(ne)?拿書(shu)架(jia)banner舉例

    服(fu)務器會(hui)下發一個type號(hao),(隨便假(jia)設)1代表打開webview,2代表打開圖(tu)書(shu),3代表打開個人中xing)hellip;等等,相關參(can)數會(hui)隨著(zhou)type的不(bu)同,下發不(bu)同字段,因此代碼會(hui)長這樣

    switch (type) { case 1: { //jumping code //NSString *url = /*解析(xi)對應url字段*/ //NSString *title = /*解析(xi)對應title字段*/ //NSString *ydwebview = [[ydwebview alloc]init]; ydwebview.url = url; ydwebview.navititle = title; [self.navigationController pushViewController:ydwebview animated:YES]; } break; case 2: { //balabalaba } break;

    可以看下我們的switch有多恐怖(bu)

    • 書(shu)架(jia)banner跳轉有6個switch,其中第一個switch有4種(zhong)子switch
    • 開機(ji)彈窗有2個switch,支(zhi)持(chi)能力(li)弱
    • push,這可了(liao)不(bu)得有20個switch
    • H5bridge跳轉,有10+個switch

      那我們每次新增(zeng)加(jia)一個功能模塊的時候改怎麼辦呢(ne)?

      假(jia)設新作(zuo)一個模塊叫”英式沒品笑(xiao)話百科”(我很愛看的一個微博號(hao)(_))

      我們就(jiu)需要在書(shu)架(jia),彈框(kuang),push,H5Bridge,四處核心(xin)跳轉點全都新增(zeng)代碼,先要import “EnglishJoke.h” ,然後還(huai)要新增(zeng)一個switch,新增(zeng)一坨跳轉viewcontroller的代碼

      有沒有感覺?what the fuck!

      我們的代碼就(jiu)好像是這樣,一團亂麻。

      假(jia)如(ru)A模塊是書(shu)架(jia),它本身含有書(shu)架(jia)banner的跳轉代碼,所(suo)以他需要耦合各種(zhong)跳轉目標。比(bi)如(ru)跳轉到(dao)B模塊書(shu)城,形(xing)成了(liao) A==>B

      假(jia)如(ru)B模塊是書(shu)城,它本身含有書(shu)城H5Brdige的跳轉代碼,所(suo)以他也(ye)需要耦合各種(zhong)跳轉目標,比(bi)如(ru)跳轉到(dao)A模塊書(shu)架(jia),形(xing)成了(liao) B==>A

      假(jia)如(ru)所(suo)有xin)?槎加(jia)姓庵zhong)蛋(dan)疼的跳轉其他模塊的需求,他們之間相互跳來跳去(qu)(沒錯,有時候需求就(jiu)是這麼的不(bu)講道理),那麼我們的代碼結構就(jiu)會(hui)如(ru)圖(tu)一樣,隨著(zhou)業務結構的逐漸龐大(da),就(jiu)會(hui)變成一張復雜的蜘蛛網,難以維護。

      三分pk10官网

      仔細思(si)考一下,我們的業務需求的最(zui)直接痛點所(suo)在就(jiu)是 各種(zhong)跳轉 ,但往(wang)深層考慮一下,這里面其實是耦合的問題,這里說的不(bu)是業務 邏輯耦合 ,而是 引用耦合 。

      • 邏輯耦合,作(zuo)為程(cheng)序員,作(zuo)為面向對象開發的基本思(si)路,一個業務邏輯模塊,做到(dao)模塊化,不(bu)把自己自身的業務邏輯與(yu)外部不(bu)相干的模塊進(jin)行(xing)混雜,所(suo)有都以接口(kou)的形(xing)式提供給外部調用,這是一個最(zui)基本的設計理念,這是沒有xing)侍猓 ye)是必(bi)須要做到(dao)的
      • 引用耦合,被(bei)抽象成一個模塊,外部要使用的時候勢(shi)必(bi)要import這個模塊的頭(tou)文件,再(zai)根據(ju)頭(tou)文件的api,進(jin)行(xing)調用,這無(wu)可厚(hou)非,但是如(ru)果(guo)發生(sheng)這種(zhong)處理需要統一跳轉多個不(bu)同模塊的邏輯的時候,引用耦合就(jiu)會(hui)顯得混亂ye)緩霉芾p>但是面對這種(zhong)當引用耦合一團亂麻的情況下,在業務逐漸壯大(da),我們面對著(zhou)一張復雜的如(ru)同蛛網一般的引用關系的時候,我們又該如(ru)何去(qu)處理?

        其實有兩種(zhong)方案,都在被(bei)普遍使用

        • 中間人
        • urlroute
Tag標簽(qian)︰路由  
  • 三分pk10官网

About IT165 - 廣(guang)告服(fu)務 - 隱(yin)私聲明 - 版權申(shen)明 - 免責條款 - 網站地圖(tu) - 網友投稿 - 聯系方式
本站內容來自于互聯網,僅供用于網絡技術(shu)學習(xi),學習(xi)中請遵循相關法(fa)律法(fa)規
三分pk10官网 | 下一页