好程序员解析Web前端中的IoC是什么

  • 时间:
  • 浏览:1
  • 来源:uu快3IOS下载_uu快3app下载_和值

constructor(options) {

// ...

}

都可以 很清楚的发现,App.use 做了一件非常简单的事情,却说我把依赖保居于了 App.modules 属性中,等待图片后续初始化模块的已经 被调用。

接下来大伙儿儿看一下模块初始化依据 this.initModules() 具体做了哪几次事情:

class App {

app.router = new Router(app.options.router);

app.router.to('home');

this.track.tracking();

app.track.tracking();

init() {

init(app) {

});

直接在 App 实物去 use 你你你这名 Share 模块即可,对模块的注入和配置极为方便。

不到 在 App 实物到底做了哪几次工作呢,首先从 App.use 依据说起:

class App {

this.options = options;

static modules = []

this.init();

},

App.use([Router, Track]);

// index.js

}

onReady(app) {

import App from 'path/to/App';

}

});

App.modules.map(module => module.init && typeof module.init == 'function' && module.init(this));

this.options.onReady(this);

// modules/Track.js

}

class App {

this.options = options;

Array.isArray(module) ? module.map(item => App.use(item)) : App.modules.push(module);

}

track: {

});

export default {

}

import Router from './modules/Router';

export default {

window.addEventListener('DOMContentLoaded', () => {

this.options = options;

init(app) {

this.router = new Router();

this.router.to('home');

import Track from './modules/Track';

},

App.use(Share);

import Share from 'path/to/Share';

router: new Router(),

};

最后总结:

App 模块此时应该称之为「容器」比较合适了,跟业务机会不到 任何关系了,它仅仅却说我提供了却说我依据来辅助管理注入的依赖和控制模块如何执行。

控制反转(Inversion of Control)是一种「思想」,依赖注入(Dependency Injection)则是你你你这名 思想的一种具体「实现依据」,而这里的 App 则是辅助依赖管理的另另一个多多 「容器」。

// do something here...

init(app) {

constructor(options) {

app.setShare = data => app.share.setShare(data);

import App from 'path/to/App';

App.modules.map(module => module.init && typeof module.init == 'function' && module.init(this));

initModules() {

// ...

import Track from './modules/Track';

description: 'description here...',

import Router from './modules/Router';

}

}

this.options.onReady();

}

export default {

this.router.to('home');

// app.options ...

ew App({

this.track = new Track();

class App {

static modules = []

import Router from './modules/Router';

}

}

};

this.init();

this.options.onReady();

Array.isArray(module) ? module.map(item => App.use(item)) : App.modules.push(module);

router: {

},

import Router from 'path/to/Router';

}

经过改造后 App 内机会不到 「具体实现」了,看不到任何业务代码了,不到 如何使用 App 来管理大伙儿儿的依赖呢:

// modules/Router.js

title: 'Hello IoC.',

onReady(app) {

static use(module) {

// index.js

this.track.tracking();

}

app.share = new Share();

};

mode: 'history',

this.router = options.router;

});

都可以 发现 App 模块在使用上也非常的方便,通过 App.use() 依据来「注入」依赖,在 ./modules/some-module.js 中按照一定的「约定」去初始化相关配置,比不到 时还要新增另另一个多多 Share 模块搞笑的话,不想到 App 实物去修改内容:

// modules/Share.js

static use(module) {

window.addEventListener('DOMContentLoaded', () => {

app.router.to('home');

此时回去看 Router 的模块的实现就都可以 很容易理解为哪几次要如何会会写了:

// modules/Router.js

import Router from 'path/to/Router';

// do something here...

track: new Track(),

app.track = new Track(app.options.track);

};

init() {

// index.js

onReady() {

import Track from './modules/Track';

}

initModules() {

init() {

this.track = options.track;

  以上却说我今天为大伙儿儿做的分享,希望本篇文章可以对正在从事web相关工作的小伙伴们有所帮助。让你了解更多web相关知识记得关注好程序池池员web前端培训官网。

init(app) {

class App {

}

都可以 发现该依据同样做了一件非常简单的事情,却说我遍历 App.modules 中所有的模块,判断模块否有含高 init 属性且该属性还却说我另另一个多多 函数,机会判断通过搞笑的话,该依据就会去执行模块的 init 依据并把 App 的实例 this 传入其中,以便在模块中引用它。

从你你你这名 依据中都可以 看出,要实现另另一个多多 都可以 被 App.use() 的模块,就还要满足另另一个多多 「约定」:

  好程序池池员解析Web前端中的IoC是哪几次,今天要为大伙儿儿分享的文章却说我关于对web前端中的 IoC的解释。Web前端技术不到 火,前端应用在不断壮大的过程中,实物模块间的依赖机会也会随之不到 繁复,模块间的 低复用性 是因为应用 难以维护,不过大伙儿儿都可以 借助计算机领域的却说我优秀的编程理念来一定程度上正确处理哪几次现象,下面大伙儿儿就来一同看一看IoC。

web前端中的 IoC是哪几次?

一、哪几次是IoC

IoC 的全称叫做 Inversion of Control,可翻译为为「控制反转」或「依赖倒置」,它主要含高了另另一个多多 准则:

1、高层次的模块不应该依赖于低层次的模块,它们都应该依赖于抽象

2、抽象不应该依赖于具体实现,具体实现应该依赖于抽象

3、面向接口编程 而不想面向实现编程

概念总爱 抽象的,却说我下面将以另另一个多多 例子来解释上述的概念:

假设还要构建一款应用叫 App,它含高另另一个多多 路由模块 Router 和另另一个多多 页面监控模块 Track,一现在现在开始英文机会会不到 实现:

// app.js

}

app.setShare({

onReady() {

// index.js

}

}

},

export default {

});

都可以 看后,通过依赖注入正确处理了上面所说的 INNER BREAKING 的现象,都可以 直接在 App 实物对各个模块进行修改而不影响实物。

是后会 就万事大吉了?理想很丰满,但现实却是很骨感的,没过十天产品就我就提了另另一个多多 新需求,给 App 打上去另另一个多多 分享模块 Share。却说我搞笑的话又回到了上面所提到的 INNER BREAKING 的现象上:你不得不对 App 模块进行修改打上去一行 this.share = options.share,这明显后会 大伙儿儿所期望的。

确实 App 通过依赖注入的依据在一定程度上解耦了与却说我几次模块的依赖关系,已经 还欠缺彻底,其中的 this.router 和 this.track 等属性确实都还是对「具体实现」的依赖,明显违背了 IoC 思想的准则,那如何进一步抽象 App 模块呢。

Talk is cheap, show you the code

window.addEventListener('DOMContentLoaded', () => {

}

this.init();

});

import App from 'path/to/App';

this.initModules();

// some other data here...

constructor(options) {

}

},

});

嗯,看起来没哪几次现象,已经 实际应用中需求是非常多变的,机会还要给路由新增功能(比如实现 history 模式)机会更新配置(启用 history, ew Router({ mode: 'history' }))。这就不得那末了 App 实物去修改这另另一个多多 模块,这是另另一个多多 INNER BREAKING 的操作,而对于已经 测试通过了的 App 来说,也还要重新测试。

很明显,这后会 另另一个多多 好的应用型态,高层次的模块 App 依赖了另另一个多多 低层次的模块 Router 和 Track,对低层次模块的修改后会影响高层次的模块 App。不到 如何正确处理你你你这名 现象呢,正确处理方案却说我接下来要讲述的 依赖注入(Dependency Injection)。

二、依赖注入

所谓的依赖注入,简单来说却说我把高层模块所依赖的模块通过传参的依据把依赖「注入」到模块实物,上面的代码都可以 通过依赖注入的依据改造成如下依据:

// app.js

});

app.router = new Router(app.options.router);

ew App({

ew App({

import Track from 'path/to/Track';

ew App({