@openxy
2016-09-11T19:09:40.000000Z
字数 2272
阅读 1350
实验班
请选择至少10个重点句子或难句进行翻译
请选择至少30个单词进行翻译
译文标题: 无所适从的JavaScript模块化机制
原文标题: The mind-boggling universe of JavaScript Module strategies
来源: https://www.airpair.com/javascript/posts/the-mind-boggling-universe-of-javascript-modules
1.
In brief terms, JavaScript Modules were created in order to apply some classic Object Orientation ideas when building components, once the current JavaScript language support for those ideas isn't as explicit as in other languages as C++, Java and Ruby.
简言之,之所以在构建组件时需要编写JavaScript模块是为了满足传统的面向对象的设计理念,当下JavaScript对这些OOP的语法支持在当初可并不像 C++, Java and Ruby 等那么显而易见
2.
In order to build a module as a special type of object, which strongly needs to leverage encapsulation, we need to add support for declaring private/public attributes and methods inside a single object. Enter the [Module pattern ], where such encapsulation is achieved through function closures, taking advantage of the function scope to publicly disclose only what is necessary through the return of the function.
为了构建一个经过高度封装的模块从而使其如同一个特殊类型的对象,我们需要在单个对象中增加声明私有/公有属性及方法的支持. 请查阅[Module pattern]这篇文章,其中讲述了这类封装是如何通过函数闭包来实现的,即借助了函数作用域的特性(通过函数的返回值仅仅公开暴露必要的信息)
3.
In JavaScript, literal objects' attributes and methods are all public, making it impossible to conceal internal details of objects, which is a real demand for Components, Features, Subsystems and Façades.
在JavaScript中,字面对象的属性和方法都是公有的,这使得隐藏对象的内部细节难以做到,而这正是组件,特性,子系统以及外观(Façade)等设计模式的关键需求
4.
Modules can also be packaged and deployed separately from each other, allowing changes on a particular module to be properly isolated from everything else, therefore mitigating those dreaded side-effects known as the "butterfly effect" (yes, just like the movie).
模块可以被分开独立的进行打包和部署,使得对一个特定模块的改变不会传播和影响到其它模块,从而弱化了部署时常遇的可怕的连锁反应,即所谓的蝴蝶效应
5.
This is definitely not recommended, because it is:
* fragile (as it is possible for any posterior code to modify/redefine your module)
* not scalable (if you need to define 100 modules, all of them will be loaded on the global JavaScript context, even if you end up consuming just 1 out of those 100 modules, making it really bad for performance),
* counter-productive (you have to manually resolve your dependencies, and you would need to remember to bring them altogether if you were to use your module in another application).
以上方法(全局模块)是完全不推荐的,基于如下理由:
* 脆弱性:这使得后续的代码将有可能修改或重定义你的模块
* 不易扩展:假使你需要定义100个模块,所有这些模块将被加载到JS的全局空间,即使你最终只是调用了其中的一个而已,这对于性能就是灾难.
* 低效: 你不得不手工解析和维护依赖,譬如当你打算在另一个应用程序中使用这些模块时,你必须记住把这些相关模关放在一起.
function closures 函数闭包
synchronous 同步的
mind-boggling 令人惊异的
strategies 策略
......