設計模式在vue中的應用（一）

前言

目錄整理：
設計模式在vue中的應用（一）
設計模式在vue中的應用（二）
設計模式在vue中的應用（三）
設計模式在vue中的應用（四）
設計模式在vue中的應用（五）
設計模式在vue中的應用（六）
設計模式在vue中的應用（七）

爲何要寫這些文章呢。正如設計模式（Design Pattern）是一套被反覆使用、多數人知曉的、通過分類的、代碼設計經驗的總結（來自百度百科）同樣，也是想經過分享一些工做中的積累與你們探討設計模式的魅力所在。
在這個系列文章中爲了輔助說明引入的應用場景都是工做中真實的應用場景，固然沒法覆蓋全面，但以此類推也覆蓋到了常見的業務場景

---

---

最近須要維護一個老項目，裏面有個需求以下：
有一個頁面要根據路由參數type分別渲染三個表單，三個表單中有相同的輸入項也有不一樣的輸入項其中某些輸入項又會有一個對應的xstatus來判斷需不需顯示。

一，需求

需求很簡單就如文章開篇，公司項目暫時不方便貼出來，只好強行意淫一個場景幫助理解。

假設：我如今要將登錄、手機註冊、郵箱註冊經過一個路由用參數type標識渲染那個表單；登錄過程當中若是帳號密碼輸入錯誤次數超過3次就須要輸入圖像驗證碼，經過codeStatus進行標識。

二，代碼

當咱們接手維護一個老項目時遇到各類問題老是會抱怨別人家的代碼，好，咱們先來看一下別人家的代碼

這種代碼實現想必你們都身經百戰了，就不貼詳細實現了。邏輯很簡單，按需求每一個form根據type作 if判斷，而後input根據status作 if操做。

我接手的老項目需求要比這個複雜的多，內部實現就是這麼搞的，僅template就近500多行。我要處理的需求很簡單——修改其中一個input對應的字段名，看着這個文件我是萬臉懵逼，關鍵是提測後沒有經過，因爲對這個文件處理的業務邏輯不熟，須要修改的這個input在兩個表單裏面分別由兩個不一樣的status來判斷顯示狀態，而我只改了一個地方的

吐槽誰都會，吐槽完了就得優化這塊邏輯了

三，優化一

無腦操做：

既然有三個表單咱們就封裝三個form組件，每一個組件負責本身的渲染邏輯

爲何說是無腦操做呢，寫過vue的coder這種方式已經深刻咱們的血脈了，哈哈哈哈哈。
看下效果怎麼樣——

假設項目本來採用這種方式組織代碼，我要去完成改input字段名的需求，我仍是可能只改了register-mobile遺漏掉register-email，最終結果提測不經過，有bug了

老實說這種方式只是將500+行代碼分紅了三個文件而已，至於優化還談不上，說代碼美化還差很少

四，優化二

設計模式登場，先看代碼
目錄結構：

文件Login.vue

文件RegisterMobile.vue

文件./input/ImgCode.vue

怎麼作的呢，咱們在 優化一的基礎上將每一個input也組件化了，每一個input組件接受 type、 status兩個屬性， form以組件的形式使用input，這樣咱們對input的修改會自動更新到全部引用了的form，input是否顯示的邏輯在input組件內部有本身控制
看下效果怎麼樣——

假設項目採用這種代碼組織方式，我要去完成改input字段名的需求。找到對應的input組件，徹底不用關心對type、status的判斷邏輯，只需修改字段名。由於兩個form使用了同一個input，自測register-mobile沒問題，那麼register-email一樣不會有問題，就算業務不熟悉，也不會出現前面尷尬的情況——bug。提交測試。轉身就下樓喝咖啡，就是這麼自信。

效果好像很贊。這節開頭就提到了設計模式，那到底用到了什麼設計模式呢。先來點理論知識：

外觀模式：爲子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。引入外觀角色以後，用戶只須要直接與外觀角色交互，用戶與子系統之間的複雜關係由外觀角色來實現，從而下降了系統的耦合度

Login、RegisterMobile、RegisterEmail定義了三個外觀角色，每一個input組件做爲子系統。外觀角色只關心使用那些子系統，子系統對status的邏輯在子系統內部處理，這樣就下降了系統的耦合度

五，優化三

取名字終究是一件比較傷腦的事，根據上面的實現咱們須要三個form組件Login、RegisterMobile、RegisterEmail這一下要取三個名字，頭疼！！！
就不能一個組件Form.vue嗎

將全部的input組件註冊到form組件上，由於input組件內部有經過 type、 status來判斷本身需不須要顯示，咱們的需求一樣達到了
看下效果怎麼樣——

將本來的三個組件簡化成一個組件，在這個點上確實達到了優化的效果。可是有一個缺點，當業務邏輯很複雜順着這個規則寫下去，可能在form組件裏面註冊很是多的input組件，若是咱們想知道那些input組件會在手機註冊時用到，單從form組件是沒法判別的，須要從這些input組件的內部邏輯一個一個看下去，才能獲得咱們想要的結果，不得不說這個過程是痛苦的。

六，優化四

優化三的問題是在某個給定的type下實例化了不少無用input，雖然它們有內部邏輯判斷不會顯示。若是咱們要什麼組件就給咱們那個組件就行了。

我想要iphoneX，大佬能造一個嗎？大佬：好
我想要mete20，大佬能造一個嗎？大佬：好
我想要小米，大佬能造一個嗎？大佬：好
複製代碼

大佬這麼牛逼，大佬是誰呀？答：富士康——手機工廠

工廠模式

首先造一個input factory，專門用來生成input：

啓用工廠生產：

7、結尾

爲了完成文章開篇這個小需求，咱們使用了設計模式中的外觀模式、工廠模式。相比於系統本來的實現方式，優化後的方案系統解耦程度更高，可維護性更強。

---

本文實現一樣適用於react，爲何文章以vue作題？vue的template讓咱們在理解一些概念的時候可能會有點不適應，而react的jsx能夠看作就是在寫JavaScript對各類概念實現更靈活 友情提示：設計模式在vue中的應用應該會寫一個系列，喜歡的同窗記得關注下