在這個標題中,除了 JS 是亂入以外,其它的幾個詞彙都是存在一個共同點的,那就是依賴。ios
那麼,依賴是什麼呢?git
好比,如今我正在寫這篇博客文,可是我得在電腦上編輯,電腦即是我完成這件事的依賴。而在代碼中,最直觀的體現是模塊之間的依賴。如某個模塊依賴另一個模塊,那麼另外的那個模塊就是該模塊的依賴。其實在上篇博客文章《JaVaScript中的模塊》中,咱們也手寫了一個模塊依賴管理器。github
依賴這個理解起來很簡單,但這不表明能夠隨意的依賴。在寫模塊的時候,講究個高內聚低耦合,以提升模塊的可拓展性和可維護性。模塊依賴了誰,怎麼去依賴,都關乎了最終模塊的好與壞。編程
還好在編程界有着提升代碼質量的金科玉律,咱們能夠用理論來指導實踐,寫出更好的代碼。axios
依賴反轉原則(Dependency inversion principle,DIP),是一種特定的解耦形式,使得高層次的模塊不依賴於低層次的模塊的實現細節,依賴關係被顛倒(反轉),從而使得低層次模塊依賴於高層次模塊的需求抽象。———— 維基百科設計模式
該原則規定:fetch
如今用一個例子來解釋一波。ui
// Ajax.js
class Ajax {
get() {
return this.constructor.name;
}
}
export default Ajax;
// main.js
import Ajax from './Ajax';
class Main {
constructor() {
this.render()
}
render() {
let content = (new Ajax()).get();
console.log('content from', content);
}
}
new Main();
複製代碼
剛開始的時候,咱們基於 XMLHttpRequest 對象,封裝了 Ajax 用於請求數據。後來 fetch 出來了,咱們打算跟上時代的腳步,封裝 fetch 以取代 Ajax。this
// Fetch.js
class Fetch {
fetch() {
return this.constructor.name;
}
}
export default Fetch;
// main.js
import Fetch from './Fetch';
class Main {
constructor() {
this.render();
}
render() {
let content = (new Fetch()).fetch();
console.log('content from', content);
}
}
new Main();
複製代碼
從以上能夠看出來,整個替代過程很麻煩,咱們須要找出封裝請求模塊(Ajax、Fetch)的全部引用,而後替換掉。又因爲 Ajax、Fetch 的方法命名也是不一樣,因此也須要對應地作更改。spa
這就是傳統的處理依賴關係的方式。在這裏 Main 是高層次模塊,Ajax、Fetch 是低層次模塊。依賴關係建立於高層次模塊,且高層次模塊直接依賴低層次模塊,這種依賴關係限制了高層次模塊的複用性。
依賴反轉原則則顛倒這種依賴關係,並以上面提到的兩個規定做爲指導思想。
// Service.js
class Service {
request(){
throw `${this.constructor.name} 沒有實現 request 方法!`
}
}
class Ajax extends Service {
request(){
return this.constructor.name;
}
}
export default Ajax;
// Main.js
import Service from './Service.js';
class Main {
constructor() {
this.render();
}
render() {
let content = (new Service).request();
console.log('content from', content);
}
}
new Main();
複製代碼
在這裏咱們把共同依賴的 Service 做爲抽象接口,它就是高層次模塊與低層次模塊須要共同遵照的契約。在高層次模塊中,它會默認 Service 會有 request 方法用來請求數據。在低層次模塊中,它會聽從 Service 複寫應該存在的方法。這在《在JavaScript中嘗試組合模式》中,不管分支對象仍是葉對象都實現 expense()
方法的道理差很少。
即便後來須要封裝 axios 取代 fetch,咱們也只須要在 Service.js 中修改便可。
再次回顧下傳統的依賴關係。
依賴關係建立於高層次模塊,且高層次模塊直接依賴低層次模塊。
通過以上的折騰,咱們充其量只是解決了高層次模塊直接依賴低層次模塊的問題。那麼依賴關係建立於高層次模塊的問題呢?
若是說依賴反轉原則告訴咱們該依賴誰,那麼控制反轉則告訴們誰應該來控制依賴。
像上面的 Main 模塊,它依賴 Service 模塊。爲了得到 Service 實例的引用,Main 在內部靠自身 new
出了一個 Service 實例。這樣明顯地引用其它模塊,無異加大了模塊間的耦合。
控制反轉(Inversion of Control,IoC),經過控制反轉,對象在被建立的時候,有一個控制系統內全部對象的外界實體,將其所依賴的對象的引用傳遞給它。能夠說,依賴被注入到對象中。———— 維基百科
這些話的意思就是將依賴對象的建立和綁定轉移到被依賴對象類的外部來實現。實現控制反轉最多見的方式是依賴注入,還有一種方式依賴查找。
依賴注入(Dependency Injection,DI),在軟件工程中,依賴注入是種實現控制反轉用於解決依賴性設計模式。一個依賴關係指的是可被利用的一種對象(即服務提供端)。依賴注入是將所依賴的傳遞給將使用的從屬對象(即客戶端)。該服務將會變成客戶端的狀態的一部分。傳遞服務給客戶端,而非容許客戶端來創建或尋找服務,是本設計模式的基本要求。
沒看懂?不要緊。這句話講的是,把過程放在外面,將結果帶入內部。在《JaVaScript中的模塊》中,咱們已經用到過依賴注入,就是對於依賴模塊的模塊,則把依賴做爲參數使用
。
因此咱們再次改造下,
// Service.js
class Service {
request() {
throw `${this.constructor.name} 沒有實現 request 方法!`
}
}
class Ajax extends Service {
request() {
return this.constructor.name;
}
}
export default Ajax;
// Main.js
class Main {
constructor(options) {
this.Service = options.Service;
this.render();
}
render() {
let content = this.Service.request();
console.log('content from', content);
}
}
export default Main;
// index.js
import Service from './Service.js';
import Main from './Main.js';
new Main({
Service: new Service()
})
複製代碼
在 Main 模塊中, Service 的實例化是在外部完成,並在 index.js
中注入。相比上一次,改動後的代碼並無看出帶來多大的好處。若是咱們再增長一個模塊呢?
class Router {
constructor() {
this.init();
}
init() {
console.log('Router::init')
}
}
export default Router;
複製代碼
# Main.js
+ this.Service = options.Router;
# index.js
+ import Router from './Router.js'
new Main({
+ Router: new Service()
})
複製代碼
如果內部實例化就很差處理了。可換成依賴注入後,這個問題就很好解決了。
// utils.js
export const toOptions = params =>
Object.entries(params).reduce((accumulator, currentValue) => {
accumulator[currentValue[0]] = new currentValue[1]()
return accumulator;
}, {});
// Main.js
class Main {
constructor(options) {
Object.assign(this, options);
this.render();
}
render() {
let content = this.Service.request();
console.log('content from', content);
}
}
export default Main;
// index.js
import Service from './Service.js';
import Router from './Router.js';
import Main from './Main.js';
import { toOptions } from './utils.js'
/** * toOptions 轉換成參數形式 * @params {Object} 類 * @return {Object} {Service: Service實例, Router: Router實例} */
const options = toOptions({Service, Router});
new Main(options);
複製代碼
由於依賴注入把依賴的引用從外部引入,因此這裏使用 Object.assign(this, options)
方式,把依賴所有加到了 this 上。即便再增長模塊,也只須要在 index.js
中引入便可。
到了這裏,DIP、IoC、DI 的概念應該有個清晰的認識了。而後咱們再結合實際,加個功能再次鞏固一下。
做爲一個功能獨立的模塊,通常都有個初始化的過程。
如今咱們要作的是遵照一個初始化的約定,定義一個抽象接口,
// Interface.js
export class Service {
request() {
throw `${this.constructor.name} 沒有實現 request 方法!`
}
}
export class Init {
init() {
throw `${this.constructor.name} 沒有實現 init 方法!`
}
}
// Service.js
import { Init, Service } from './Interface.js';
import { mix } from './utils.js'
class Ajax extends mix(Init, Service) {
constructor() {
super();
}
init() {
console.log('Service::init')
}
request() {
return this.constructor.name;
}
}
export default Ajax;
複製代碼
Main、Service、Router 都依賴 Init 接口(在這裏就是一種協定),Service 模塊比較特殊,因此作了 Mixin 處理。要作到統一初始化,Main 還須要作些事。
// Main.js
import { Init } from './Interface.js'
class Main extends Init {
constructor(options) {
super();
Object.assign(this, options);
this.options = options;
this.render();
}
init() {
(Object.values(this.options)).map(item => item.init());
console.log('Main::init');
}
render() {
let content = this.Service.request();
console.log('content from', content);
}
}
export default Main;
複製代碼
至此,結束
// index.js
import Service from './Service.js';
import Router from './Router.js';
import Main from './Main.js';
import { toOptions } from './utils.js'
/** * toOptions * 轉換成參數形式 * @params {Object} 類 * @return {Object} * { * Service: Service實例, * Router: Router實例 * } */
const options = toOptions({ Service, Router });
(new Main(options)).init();
// content from Ajax
// Service::init
// Router::init
// Main::init
複製代碼
(以上全部示例可見 GitHub)