-
1 # 天涯學館
-
2 # 前端小白說
我覺得最重要的是你需要細化出來你到底需要怎麼樣的元件或者模組,分的越細,耦合度越低,你的程式碼重用的就越高。
-
3 # 獨綻2018
包裝可重用的JavaScript程式碼有多種方法,我說一下我常用的2種方法。舉例說明吧,這樣容易理解一些。
案例:封裝一個授課老師的物件。這個老師有一些屬性,比如名字,性別,課程;擴充套件方法是輸出這位老師授課的名稱。
第一種是採用new宣告的方式
方法步驟:
1.建立這個老師這個物件,以及初始化
function Teacher (name,sex,course){
this.name = name;
this.sex = sex;
this.course = course;
this.doing = function() {
console.log("3")
}
}
2.我們還可以給這個Teacher物件擴充套件方法,將方法掛載到Person的prototype屬性上,那麼就可以繼承這個方法如下:
Teacher.prototype.teach = function() {
console.log(this.course);
}
3.前兩步將封裝完畢,如何使用呢?用new的方式,這個應該都不陌生。
duzhan.doing() // 3
duzhan.teach() // vue
第二種是採用object.create()宣告的方式
方法步驟:
1.建立一個老師的物件,這樣就完成了封裝。
var Teacher = {
sex: "女",
course: "vue",
teach: function() { //方法
console.log(this.name);
}
}
2.使用封裝好的這個物件
var duzhan = Object.create(Teacher);
//duzhan繼承了Teacher的所有屬性,並指標指向duzhan,也就日this指向了duzhan
duzhan.teach();
看你哪種喜好了,任選一種了〜
-
4 # 小鄭搞碼事
謝謝邀請!關於前端如何包裝自己的程式碼。其本質說的就是一個元件化的問題,目的就是最大程度上提升開發效率。下面我就前端如何更高效的進行元件化開發,談一下前端如何包裝自己的共享程式碼。專案開發方式分元件化和非元件化。先講講元件化。畢竟主流一、元件化元件化開發分同一個業務內和不同業務之間如何包裝共享程式碼問題。1. 同一個業務內:話不多說,先來看一張圖。如上圖所示:其實任何一個專案都是由一個或者兩個或者N個頁面組成,在元件化的開發模式下,每一個頁面的開發過程,其本質就是變成了,將一個頁面如何拆分成不同的業務元件,這其中,有兩種情況:(業務元件)比如一個元件,它是和業務還是有關係的,被多個頁面所引用的話,我們是可以把它抽離成一個公共元件的。另外一種(公共元件),完全和業務沒有關係的,不旦在業務內可以使用,而且可以跨業務使用,可以抽離成更基礎的元件。接著往下就是基礎模組,它屬於這種非UI的模組,涉及到一些功能型元件,如格式化時間資料,登入,上報程式碼等。最後一層,也是最底層就是專案的構建層,包括打包依賴資源安裝升級部署等等。如此看來,對於業務內如何包裝共享程式碼就一目瞭然了。只要按照這幾個層次來劃分(在業務內封裝可重用元件,至於如何來封裝一個更優的元件,也是有些詳細的講究,這個主題回頭也可以開篇來詳述),即使多人合作開發也不會出亂。穩中有序。2. 不同業務之間同樣先來看一張圖:如上圖所示:如果兩個不同業務之間,出現相同的功能及相同業務元件需要複用的話,就會出現不停的被COPY。一旦元件出現改動,就需要開啟多個專案進行個性,出現遺漏還得背鍋。copy這種方式也極其容易出錯。不是一個有效的工作方式。因此,我們可以將這公用元件程式碼包裝成一個NPM安裝包(公共元件,基礎元件),將專案初始架構包裝成一個腳手架。這樣在新開一個業務需要複用這些東西的時候,只需命令式安裝和組裝,然後改改UI就完事了。當然,這裡會涉及到NODE命令列工具的開發及NPM安裝包的封裝,具體封裝細節下回也可以詳細來講講。二、非元件化如果你的JS程式碼是一個大檔案,找機會把可以重用的功能提取到自包含的物件中,放入到一個單獨的庫中。若發現已經有了在所有專案開發中重複使用的一組函式,考慮將它們打包,以透過一個物件直接量來重用。下面舉一個簡單的例子:下面這段程式碼,包含三個可以在各個業務中高度複用的功能。可以將上面這段程式碼寫在一個字面量裡自由呼叫。當然,有時間或者有興趣的可以自己來封裝一個類似於JQ的庫,一個屬於自己呼叫的基礎庫,也是一種極其優越的程式碼包裝方式。總結一下:程式碼包裝也可以根據實際的場景來做,在你的業務場景的複用性極高的功能都可以包裝成一個公共JS方法,或者元件,或者安裝包,總之,我們最終的目的就是提升二次開發效率。
回覆列表
在設計的時候先考慮把大的功能劃分到不同服務中。這樣各個大功能之間的耦合就只存在在服務間的介面契約中。再來看同一個服務(大功能)內部如何設計。核心還是低耦合,高內聚。理想情況是把一個大功能實現需要實現的小功能點拆分成一個個小功能點,由一個主要業務類處理一個業務功能點。如果小功能點之間需要互動,也可以考慮用主要業務類對外暴露的介面進行契約約定(例如只能呼叫介面)而不是直接主要業務類之間直接的任意程式碼呼叫。至於如何約束所有開發做到,可以透過靜態程式碼掃描等方式。另外一些典型的面向切面的需求可以考慮用AOP來做。
多參考一些經典的JS外掛庫,平時的時候多嘗試自己去封裝一些js外掛。這樣可以迅速提高自己的js開發能力。