本文是小编为大家收集整理的关于脚本。模块模式与构造器/原型模式？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我想知道模块模式或构造函数/原型模式是否更适用于我的工作.
基本上我正在使用Unbrotusive JavaScript -HTML文档对.js文件的引用.
我对模块模式的理解:
- 调用初始方法(基本上是我可以使用模块模式创建和返回的公共方法)
- 在INIT方法中，分配所有点击事件等.
这听起来像是我情况的完美模式，因为我不需要创建对象和继承层次结构等.
我对构造函数/原型模式的理解:
- 用于创建对象
- 用于使用继承(即Supertype的子类型)
我是正确的吗，对于提供不引人注目的JavaScript，模块模式是理想的?
推荐答案
构造方法和原型是实施类和实例的合理方法之一.它们与该模型不太对应，因此您通常需要选择特定的方案或助手方法来实现原型. ( JS 类的一些背景.)/p>
模块模式通常用于命名区域，其中您将拥有一个实例作为与组相关的功能和对象的存储.这与原型制作的用例不同.他们并不是真正的互相竞争；您可以很高兴地一起使用两者(例如将构造函数函数放入模块中，并说new MyNamespace.MyModule.MyClass(arguments)).
其他推荐答案
模块图案比原型更容易，更优雅.但是，首先思考移动设备.它不是中/大对象的相关模式，因为初始化需要在开始之前解析整个块.多个关闭还会产生垃圾收集器无法免费的循环依赖性(尤其是IE)，它会导致较重的内存足迹，直到窗口(或TAB)关闭 - 检查Chrome Task Manager以比较 - 加载时间与对象大小相反，使用模块模式，而原型继承不是这种情况. 上面的声明通过这样的多个基准进行了验证:/a>
在上次测试中看到.小物体最好将其初始化为普通对象(没有这些模式).它适用于不需要闭合或继承的单个对象.明智的是评估您是否需要这些模式.
其他推荐答案
原型模式有助于我们扩展功能，而在内存中只有一个函数实例，而与对象数量无关.在模块模式中，每个对象在内存中创建一个新的函数实例，但它提供了私有/公共变量的概念，并有助于封装变量和函数.
问题描述
I would like to know if the module pattern or Constructor/protoType pattern is more applicable to my work.
Basically I am using unobtrusive javascript -- the HTML document has a reference to the .js file.
My understanding of the module pattern:
- call an INIT method (which is basically a public method i can create and return using the module pattern)
- In the INIT method, assign all click events etc.
This sounds like the perfect pattern for my situation, as I don't need to create Objects and inheritance hierarchies etc.
My understanding of the Constructor/Prototype pattern:
- for creating objects
- for using inheritance (i.e. Subtypes of a supertype)
Am I correct, that for providing unobtrusive javascript, the module pattern is ideal?
推荐答案
Constructor-functions and prototypes are one of the reasonable ways to implement classes and instances. They don't quite correspond to that model so you typically need to choose a particular scheme or helper method to implement classes in terms of prototypes. (Some background on classes in JS.)
The module pattern is typically used for namespacing, where you'll have a single instance acting as a store to group related functions and objects. This is a different use case from what prototyping is good for. They're not really competing with each other; you can quite happily use both together (eg put a constructor-function inside a module and say new MyNamespace.MyModule.MyClass(arguments)).
其他推荐答案
Module pattern is by far easier and more elegant than prototype. However, thinking mobile first. It is not a relevant pattern for medium/large objects because the initialization needs to parse the whole block before starting. The multiple closures also create circular dependencies that the garbage collector does not free (especially IE), it results in a heavier memory footprint not freed until the window (or tab) is closed - check chrome task manager to compare- The loading time is inversely proportional to the object size using module pattern while this is not the case for prototypal inheritance. Statements above are verified through multiple benchmarks like this one: http://jsperf.com/prototypal-performance/54
As seen in last test. Small objects are better off being initialized as plain object ( without these patterns). It is suitable for single objects not requiring closure nor inheritance. It is wise to assess if you even need these patterns.
其他推荐答案
Prototype pattern helps us to extend the functionality and there is only one instance of functions in a memory irrespective of the number of objects. In Module patter, each object creates a new instance of functions in memory but it provides with concept of private/public variables and helps in encapsulating the variables and functions.
更多相关问答
联系站长