來到倒數第二篇
按照第24天介紹是方法管理

這一篇就是簡單介紹用js的特性進行方法管理
與協做方法彈性

那麼一如往常地來介紹幾篇時下流行的東西吧

Java 與 Kotlin 入門 系列

那時接到維護案子對方說適用kotlin做的
他看了看我的履歷說我是java出身的
維護起來應該不會有問題
那時心想著:也太看得起我，我沒學過耶

然而接到案子，開始學kotlin怎麼裝怎麼寫
然後把安裝環境看完，開始看變數與方法宣告
....
然後我就把網頁關起來開始維護了

....這該怎麼說呢?-`д´-
這東西好像python(的宣告)+js(的設計風格)+java(的運行環境)混起來的東西

反正就這樣大致上妥妥的把案子維護完了
是個如果看官們吃飽撐著可以快速學起來的語言

然後工程師必備懶人工具
爬蟲始終來自於墮性 系列

多虧了這東西，雙11被少騙了許多錢
各家電商網站都打著自己最便宜
所以我就很懶，乾脆把關鍵字打進去
然後去飛比比價網查
去各家電商網站把蟲放下去
(但我只寫了樂天、MOMO、pchome)
然後各家評價、保固、附贈品通通幫我爬出來

買了條折了一千多的ram
折了快兩千的耳機
折了兩百多的快速碟
收獲頗豐，但看看自己買的東西
一個為工作而活的人呀(´_ゝ`)

累人的重複工跟耗眼力的東西就交給電腦去扮吧
我們去抵抗誘惑就可以了

那我們今天來倒數第二篇吧

今天我們來實現一個js簡單的...
我忘記是中介者模式Mediator Pattern）
還是建造者模式了(Builder Pattern）

今天分享的東西有三層
是為了因應現在越來越複雜的API設計
這東西出來的原因有三

1. 多支API由各個前端工程的呼叫
2. 為了商業化每個應用程式而沒客製化的API
3. 複雜的頁面業務邏輯架構

啥意思?

來介紹一下有甚麼角色
一個後端工程師與三個前端工程師

今天後端工程師熬夜爆肝掉頭髮
寫出了十支API
其中驗證登入與產品明細三個前端工程師都會用到

今天A工程師這個頁面拿了這兩個API做了兩件事

1. 驗證如果沒登入，塞入變數只顯示部分資料
2. 拿那個變數去後端摳產品明細資料

然後B工程師的頁面也拿這兩個API做了兩件事

1. 驗證如果沒登入，跳至登入畫面
2. 然後產品明細清空

最後C工程師又拿了這兩個API做了兩件事

1. 驗證如果登入了，跳折價券視窗出來
2. 對應折價券，顯示可用的產品明細

好的
今天這兩支API被三個工程師拿去做了各種不同的事

所以方法不能共用
但都是這兩支API那該怎麼辦呢?

這時候我們把東西分成三層

第一層--最底層共用源代碼

對外API共用接口

function baseAPI(url, datas, sFn, fFu) {
    $.ajax({
        type: "post",
        url:  url,
        data: datas,
        dataType: "json",
        success: function (result) {
            ...dothing
            sFn(result);
        },
        error: function (err) {
           ...dothing
            fFn(result);
        }
    });
}

還記得js可以傳方法嗎?
我們判斷js連線成功後
做了這個應用程式每支API都必須做的事情
例如驗證登入，CSS變化等等等
然後將這個API傳回來的結果放入第二層

那麼第二層是甚麼呢?

第二層--中層API物件管理

var Login = {
    login: function (id, pwd, sFu, fFu) {
        ...dothing 
        baseAPI("apipag/login.action",data,
            function(result){
                dothing..
                sFu(result);
            },
             function(result){
                dothing..
                fFu(result);
            }
        )
    },
    checklog: function (sFu, fFu) {
        ...dothing 
        baseAPI("apipag/login.action",data,
            function(result){
                dothing..
                sFu(result);
            },
             function(result){
                dothing..
                fFu(result);
            }
        )
    },
};

好了我們這邊一次傳達了兩個觀念

1. 物件方法包個管理
   • 架構很清楚，這個Login就是所有關於登入的api方法
   • 在頁面邏輯的html裡只要有導入這一包
     vsCode會自動幫你找這個物件裡面有甚麼
     你的方法名露露長，也不用擔心會打錯(如下圖)
2. 這支API必做事情
   • 例如login我們從前面頁面傳入邏輯後，加密是必須的，加密後我們再由最底層API送出，因此加密的邏輯就以不用重複寫
   • 回傳後還有sFu與fFu這是因為還有頁面邏輯傳入的需要做方法，我們在把這支API所傳回的結果在往第三層拋
     

第三層---最上層頁面邏輯層

 var mainVm = new Vue({
            el: "#app",
            data: {
              
            },
            created: function () {
               Login.checklog(
                   function(res){
                       this.getProduct();
                   },function(res){
                       location.href="index.html"
                   }

               )
            },
            methods: {
                getProduct: function () {
                    Product.porductList(
                        pid,
                         function(res){
                        },function(res){
                            location.href="index.html"
                        }
                    )
                }
            }
         
        })

終於來到最後一層，我們以vue來說

• 好的，我們一進入頁面我們來看看我們做了甚麼
  1. vue的created一進入頁面來判斷是否登入
  2. 在這個頁面邏輯上如果沒登入返回首頁叫使用者登入
  3. 如果登入了，則去摳產品明細那支API

那我們就完成了B工程師的需求
今天假設一個D工程師只要把baseAPI寫完
然後把api物件管理也寫完
那們ABC工程師只需要專注於頁面邏輯
不需要管裡面在幹嘛

符合了軟體工程
開閉原則，與里式替換原則 以及單一職責原則

如果搭配ES6方法可以設定預設值變數，可以寫得更簡單
然而ES5也有

var value = "function(){}"||sfu;

這種預設變數方法
就看看官們怎麼使用了

好的希望今天介紹的東西有實用到
接下來我們明天最後一天見