6 ms·

An introduction to the JavaScript Module Pattern

36 points by jackfranklin 15y ago

mcmire 15y ago
Nice site. I really appreciate that people are promoting better JavaScript practices these days. There can't be enough articles about that in my opinion -- there's still plenty of terrible JavaScript code out there. Keep up the good work.
lukeholder 15y ago
Does anyone else think it would be a good idea to also name the internal methods/functions with an underscore?
- MatthewPhillips 14y ago
  There's no advantage or disadvantage to underscores. It somewhat makes sense on an exposed object to denote to the consumer that they shouldn't call/use the property. otherwise it doesn't matter.
grannyg00se 14y ago
Or if ECMAscript 5 is an option checkout object.defineProperty allows specification of getter, setter, and writable flag (among others).
- ronaldj 14y ago
  The syntax is ugly. They should've made it a little less verbose.
  - Cushman 14y ago
    I'm sure CoffeeScript will adopt a much more elegant syntax for the feature :)
    - epidemian 14y ago
      That might be a quite distant future. See: "Unsupported features" at https://github.com/jashkenas/coffee-script/wiki/FAQ https://github.com/jashkenas/coffee-script/wiki/FAQ https://github.com/jashkenas/coffee-script/issues/451 https://github.com/jashkenas/coffee-script/issues/451 https://github.com/jashkenas/coffee-script/issues/64 https://github.com/jashkenas/coffee-script/issues/64 https://github.com/jashkenas/coffee-script/issues/322 https://github.com/jashkenas/coffee-script/issues/322
mistercow 14y ago
I've always felt that going out of your way to enforce information hiding in programming was kind of silly. Establish in your documentation what is public and what is private and then don't worry about it. If someone wants to hack on your private variables, you aren't going to stop them with this or any other pattern, and if they want their code to work properly, a comment that says "private" will tell them what not to mess with.
- Lazare 14y ago
  Agreed, completely. And if you want to go further, a convention that anything starting with an underscore is private, and probably shouldn't be accessed or called without good reason and the understanding that it may break or change at any time is a good idea. (This is how Python works.) In the real world, enforcing information hiding isn't really useful.
- ronaldj 14y ago
  What if you want a clean API? What if you want the users of your code to be able to instantiate an instance and inspect that object in the console, seeing only the public methods and not having them get lost in a sea of private stuff?
  - bcrescimanno 14y ago
    FWIW, If you want instantiate-able objects, the module pattern is probably the wrong option in that case anyway.
  - andybak 14y ago
    Hmmmm. The Python convention of semi-private methods starting with an underscore would do the trick. I've been burnt in the past with using someone else's javascript code and finding out that something I needed to modify they hadn't deemed public for some weird reason. Forking the code isn't the best pattern for code reuse.
tkaemming 14y ago
It's worth noting that if you're planning on instantiating multiple instances of the same "class" (to use the term generically/loosely) instead of immediately invoking the function, the module pattern has a much more significant memory footprint than prototypical inheritance — total memory usage should increase linearly with the number of objects you're creating, since you're creating new copies of all member functions each time. Jeremy Ashkenas (who knows a lot more about this than I do) explains this in another comment thread here: http://news.ycombinator.com/item?id=2991904 http://news.ycombinator.com/item?id=2991904
jstsch 14y ago
See the previous discussion: http://news.ycombinator.com/item?id=3813598 http://news.ycombinator.com/item?id=3813598
chrisbroadfoot 14y ago
I find it's enough to suffix (or prefix) a method or property with an underscore. If calling code uses it knowingly, then they should know it's bound to break in future. The overhead (cognitive, and possibly execution) of not exposing the property isn't worth it, I think.

36 points by jackfranklin 15y ago

Nice site. I really appreciate that people are promoting better JavaScript practices these days. There can't be enough articles about that in my opinion -- there's still plenty of terrible JavaScript code out there. Keep up the good work.

lukeholder 15y ago

Does anyone else think it would be a good idea to also name the internal methods/functions with an underscore?

MatthewPhillips 14y ago
There's no advantage or disadvantage to underscores. It somewhat makes sense on an exposed object to denote to the consumer that they shouldn't call/use the property. otherwise it doesn't matter.

grannyg00se 14y ago

Or if ECMAscript 5 is an option checkout object.defineProperty allows specification of getter, setter, and writable flag (among others).

ronaldj 14y ago
The syntax is ugly. They should've made it a little less verbose.
- Cushman 14y ago
  I'm sure CoffeeScript will adopt a much more elegant syntax for the feature :)
  - epidemian 14y ago
    That might be a quite distant future. See: "Unsupported features" at https://github.com/jashkenas/coffee-script/wiki/FAQ https://github.com/jashkenas/coffee-script/wiki/FAQ https://github.com/jashkenas/coffee-script/issues/451 https://github.com/jashkenas/coffee-script/issues/451 https://github.com/jashkenas/coffee-script/issues/64 https://github.com/jashkenas/coffee-script/issues/64 https://github.com/jashkenas/coffee-script/issues/322 https://github.com/jashkenas/coffee-script/issues/322

mistercow 14y ago

I've always felt that going out of your way to enforce information hiding in programming was kind of silly. Establish in your documentation what is public and what is private and then don't worry about it. If someone wants to hack on your private variables, you aren't going to stop them with this or any other pattern, and if they want their code to work properly, a comment that says "private" will tell them what not to mess with.

Lazare 14y ago
Agreed, completely. And if you want to go further, a convention that anything starting with an underscore is private, and probably shouldn't be accessed or called without good reason and the understanding that it may break or change at any time is a good idea. (This is how Python works.) In the real world, enforcing information hiding isn't really useful.
ronaldj 14y ago
What if you want a clean API? What if you want the users of your code to be able to instantiate an instance and inspect that object in the console, seeing only the public methods and not having them get lost in a sea of private stuff?
- bcrescimanno 14y ago
  FWIW, If you want instantiate-able objects, the module pattern is probably the wrong option in that case anyway.
- andybak 14y ago
  Hmmmm. The Python convention of semi-private methods starting with an underscore would do the trick. I've been burnt in the past with using someone else's javascript code and finding out that something I needed to modify they hadn't deemed public for some weird reason. Forking the code isn't the best pattern for code reuse.

tkaemming 14y ago

It's worth noting that if you're planning on instantiating multiple instances of the same "class" (to use the term generically/loosely) instead of immediately invoking the function, the module pattern has a much more significant memory footprint than prototypical inheritance — total memory usage should increase linearly with the number of objects you're creating, since you're creating new copies of all member functions each time. Jeremy Ashkenas (who knows a lot more about this than I do) explains this in another comment thread here: http://news.ycombinator.com/item?id=2991904 http://news.ycombinator.com/item?id=2991904

jstsch 14y ago

See the previous discussion: http://news.ycombinator.com/item?id=3813598 http://news.ycombinator.com/item?id=3813598

chrisbroadfoot 14y ago

I find it's enough to suffix (or prefix) a method or property with an underscore. If calling code uses it knowingly, then they should know it's bound to break in future. The overhead (cognitive, and possibly execution) of not exposing the property isn't worth it, I think.