Javascript: Module Pattern vs Constructor/Prototype pattern?

Question

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?

Touchy

Answer 1

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)).

Joijoice

so in my case i don't really want to create instances so the module pattern is probably ideal for what i want. When you say namespacing.. How do i namespace in a module pattern? I saw one way using YUI - but is it really necessary? – Touchy

There's no particular trick, you just use a JavaScript Object as a lookup. Either create an object literal directly like var MyModule= { someProperty: 3, someFunction: function() { ... }, somethingElse: null }; or assign to MyModule.someFunction= function() { ... };. If you want private variables you do it in an immediately-called-function-expression and have that return an object in a closure... personally I find ‘real’ private variables a complete waste of time. – Joijoice

The idea that js has classes can be very misleading - this is an excellent book on the subject You Don't Know JS | This & Object Prototypes - despite the fact that ES6 has support for "classes", these are mostly just a mask over prototypal functionality and thinking of these as classes in the sense that you would think of classes in Java or C# will lead you down the path to confusion . When using the prototype, I suggest the OOLO pattern as described in ch6 of the above linked book. – Salomo

I would also suggest the idea of inheritance in js is somewhat of a misnomer and delegation is a better term: chipersoft.com/p/inheritance . I agree the module pattern is useful for keeping complex applications neatly separated, but there are plenty of good cases to use the module pattern for composition / augmentation especially if you are working with devs who are not so familiar with js - it's likely easier for them to understand what an IIFE is vs. (really) understanding the prototype: adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html – Salomo

@Joijoice I know you posted this a LONG time ago, but why do you find real private variables a waste of time? – Ergonomics

Answer 2

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.

Consumption

Answer 3

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.

Acridine

What about Douglas crockfords privileged class method that allows use of private members? – Hyperborean