目錄整理:
設計模式在vue中的應用(一)
設計模式在vue中的應用(二)
設計模式在vue中的應用(三)
設計模式在vue中的應用(四)
設計模式在vue中的應用(五)
設計模式在vue中的應用(六)
設計模式在vue中的應用(七)css
爲何要寫這些文章呢。正如設計模式(Design Pattern)是一套被反覆使用、多數人知曉的、通過分類的、代碼設計經驗的總結(來自百度百科)同樣,也是想經過分享一些工做中的積累與你們探討設計模式的魅力所在。
在這個系列文章中爲了輔助說明引入的應用場景都是工做中真實的應用場景,固然沒法覆蓋全面,但以此類推也覆蓋到了常見的業務場景vue
適配器至關於和事佬的存在,生活中適配器常見情景:react
經過上面兩個例子應該很容易發現適配器應用於存在不兼容的場景,在代碼中的表現就是多個對象每一個對象要執行的方法不一樣,這時就要經過適配器對要調用的方法進行統一
定義(來自百度百科):android
適配器模式(有時候也稱包裝樣式或者包裝)將一個類的接口適配成用戶所期待的。一個適配容許一般由於接口不兼容而不能在一塊兒工做的類工做在一塊兒,作法是將類本身的接口包裹在一個已存在的類中element-ui
假設在項目中咱們本來使用了Swiper
這個組件,使用方式以下:後端
<swiper :prop-x="px" :prop-y="py" :prop-z="pz" />
複製代碼
後來又有了一個功能更強大,性能更好的滑動組件——NbSwiper,使用方式以下:設計模式
<nb-swiper :prop-x="px" :prop-yy="pz" :prop-z="pw" />
複製代碼
對比能夠發現瀏覽器
Swiper | NbSwiper | 組件data |
---|---|---|
prop-x | prop-x | px |
prop-y | 無 | py |
prop-z | prop-yy | pz |
無 | prop-z | pw |
如今需求是要把項目中全部的Swiper
組件替換爲NbSwiper
如上表:bash
兩個組件處理除了`prop-x`使用相同,另外幾個屬性`prop-y`、`prop-yy`、`prop-z`都有必定的區別。
若是直接在代碼中一個一個的更改,工做量有點大,並且很難保證在處理一些兼容問題上不出現bug
複製代碼
要解決這個問題咱們能夠選擇將Swiper
做爲一個裝飾組件app
// Swiper.vue
// 項目本來使用的Swiper組件會被替換掉,咱們本身封裝一個Swiper組件
<template>
<!-- 進行轉換 -->
<nb-swiper :prop-x="propX" :prop-yy="propZ" :prop-z="propW" />
</tempalte>
<script>
export default {
props: {
// 接受本來Swiper的props和NbSwiper支持的props
propX: String,
propY: String,
propYy: String,
propZ: String,
propW: String,
}
...
}
</script>
複製代碼
如今咱們的工做只需在代碼中增長對NbSwiper
的新屬性值的兼容
定義(來自百度百科):
裝飾模式指的是在沒必要改變原類文件和使用繼承的狀況下,動態地擴展一個對象的功能。它是經過建立一個包裝對象,也就是裝飾來包裹真實的對象
<input />
複製代碼
瀏覽器原生Input沒有驗證功能或者驗證功能比較弱,咱們如今要賦予它比較強的驗證功能怎麼辦——裝飾者模式
element-ui、iView等各種UI框架你們都有用過,這些框架提供的Input組件應該也不會陌生吧,交互友好功能強大。今天咱們的設計會與他們有點不同凡響
// 原生input須要驗證功能,咱們用帶有驗證能力的valid-input包裹
<valid-input>
<input v-model="username" type="text" />
</valid-input>
複製代碼
簡單思考下
valid-input要作驗證須要:
//input 與username進行綁定
<valid-input field="username" options="[{ rule: required, message: '用戶名必須' }]">
<input v-model="username" type="text" />
</valid-input>
複製代碼
若是哪天我不須要驗證功能只需刪掉valid-input,這樣很靈活的實現功能的擴展
具體實現過程(以前寫過一篇相關主題的文章,連接找不到了,代碼實現若是須要後期補上)
checkbox、radio瀏覽器原生長的醜不說並且在不一樣的瀏覽器上還不同,這對於咱們優秀的產品來講是不能忍的
// 常規解決方案,本身經過CSS模式checkbox的交互
<label class="checkbox-wrapper">
<span class="checkbox">
<span class="checkbox-inner"></span>
<input type="checkbox" class="checkbox-input">
</span>
Checkbox
</label>
複製代碼
這樣的場景實現相信你們也不會陌生,如今的問題的是:
我本來使用checkbox只需
<input type="checkbox" class="checkbox-input">
而如今多了這麼多層標籤嵌套,還有不少css樣式,在使用中很難保證不出錯
複製代碼
// stage.vue
// decoratorCheckbox的實現簡化每次使用要寫不少標籤和註明class
<tempalte>
<div>
<decorator-checkbox>
<input type="checkbox" class="checkbox-input">
</decorator-checkbox>
</div>
</template>
複製代碼
具體實現過程(以前寫過一篇相關主題的文章,連接找不到了,代碼實現若是須要後期補上)
先看定義(來自百度百科):
所謂的代理者是指一個類別能夠做爲其它東西的接口。代理者能夠做任何東西的接口:網上鍊接、存儲器中的大對象、文件或其它昂貴或沒法複製的資源。
代理模式和裝飾者模式的UML圖看起來很類似,有什麼區別呢?
懵懂騷年喜歡一位漂亮姑涼
裝飾者模式:無論這位姑涼怎麼化妝,穿長袖仍是短袖(裝飾)騷年每次遠觀看到的終究是姑涼本人
代理模式:騷年按奈不住躁動的心要開始行動了,騷年想到了一個方法首先策反姑涼的好友閨蜜做
爲本身的代理達傳達一些小紙條什麼的,小紙條最終有沒有送到姑涼手中騷年並不能確認
,但是少年依舊通宵寫着紙條。參見電影《你好,之華》年輕之華
複製代碼
咱們從後端拿到了一堆數據
// list.vue
<template>
<div>
<div v-if="isEmpty">數據爲空</div>
<div v-else>
<div v-for="item in data">
... do something
</div>
</div>
</div>
</tempalte>
<script>
export default{
props: {
data: Array
},
computed: {
isEmpty() {
return this.data.length < 1
}
}
}
</script>
複製代碼
能夠發現List
組件作了兩件事:數據爲空的處理、數據不爲空的處理,這種設計是不太友好的
// ProxyList.vue
<template>
<div>
<empty v-if="isEmpty" />
<list v-else :data="data" />
</div>
</tempalte>
<script>
import Empty from './Empty'
import List from './List'
export default{
props: {
data: Array
},
computed: {
isEmpty() {
return this.data.length < 1
}
},
components:{
Empty,
List
}
}
</script>
複製代碼
對於數據data的使用者來講,只需關心拿數據渲染列表,數據爲空是什麼樣的徹底不關心
這篇一次介紹了三種設計模式:適配器模式、裝飾者模式、代理模式,大多時候咱們很容易將他們搞混淆,這也是將他們放在一塊兒的緣由。結合上面的例子再來看一下他們的不一樣點
適配器模式:將多個對象的不一樣方法調用(objA.methodA(),objB.methodB()),適配成統一調
用(objA.methodA(),adapterObjB.methodA())
裝飾者模式:在不修改原對象的基礎上動態的添加功能
功能:擴展功能
要求:裝飾者要實現和被裝飾對象相同的方法
代理模式:爲其餘對象提供一種代理以控制對這個對象的訪問
功能:控制被代理對象的訪問
要求:與裝飾者模式同樣要實現和被代理對象相同的方法
複製代碼
本文實現一樣適用於react,爲何文章以vue作題?vue的template讓咱們在理解一些概念的時候可能會有點不適應,而react的jsx能夠看作就是在寫JavaScript對各類概念實現更靈活 友情提示:設計模式在vue中的應用應該會寫一個系列,喜歡的同窗記得關注下