

An introduction to the JavaScript Module Pattern - jackfranklin
http://javascriptplayground.com/blog/2012/04/javascript-module-pattern

======
tkaemming
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>

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

~~~
ronaldj
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?

~~~
andybak
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.

------
grannyg00se
Or if ECMAscript 5 is an option checkout

object.defineProperty

allows specification of getter, setter, and writable flag (among others).

~~~
ronaldj
The syntax is ugly. They should've made it a little less verbose.

~~~
Cushman
I'm sure CoffeeScript will adopt a much more elegant syntax for the feature :)

~~~
epidemian
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/issues/451>

<https://github.com/jashkenas/coffee-script/issues/64>

<https://github.com/jashkenas/coffee-script/issues/322>

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

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

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

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

~~~
MatthewPhillips
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.

