With JavaScript, you can create private methods and properties using what Yahoo describes as the module pattern. Here's the basic construct, including a private method:

MyObject = function(){

  var privateMethod = function(){ /* do stuff */ };
  
  var obj = {
    publicProperty:5,
    publicMethod:function(){ /* do stuff */ };
  };
  
  return obj;
}(); // run it right away

If you're not familiar with this pattern, it's really quite cool. It takes advantage of closures, allowing the public methods to access the private methods. I've been using this approach in my recent work and it feels nice and works well.

Advantages to Private Methods

Private methods seem like a great idea because nobody can mess with them unless they have access to the JavaScript source and feel like rewriting things. It's also handy in that you've really established what your public API should be and there's no two ways about it. No underscores, no documentation. Just use the public methods because that's all you've got.

Having private methods also means that you're not polluting some other namespace with stuff that's never meant to be used by anything but your own code.

Disadvantages to Private Methods

Since they're private, it can make debugging marginally harder. This probably speaks more to my coding style but it's not unheard of for me to have Firebug open and just running a method from my object to see what happens instead of refreshing the page or what have you. But if the methods you want to examine or execute are private, then you have to jump back to the JavaScript source and try again. If you're trying to test this stuff on a server and need to FTP the info up, it just got even harder.

The other major disadvantage is that you've now made it harder for people to extend your code. JavaScript is really cool in that you can extend objects and prototypes at any time without ever having to touch the original code. But if I need to do anything that a private method does, then I need to rewrite that functionality in my own code or modify the original code.

Recommendation

Moving forward, I'll more than likely avoid private methods. I'm never one to go as far as saying, "X considered harmful" but with JavaScript and private methods, I don't think they're necessary.

What I'd recommend then is to create a utility or private object that, while, still public, makes it clear that these functions are really meant to be used within the namespace. There are two ways to which I'd approach this.

Utility Namespace

This one is pretty straightforward: just create a utility module on your namespace:

MyObject.util = {
  privateMethod: function(){ /* do stuff */ };
};

MyObject = function(){
  // shortcutting namespaces is still good
  var util = MyObject.util; 
  
  var obj = {
    publicProperty:5,
    publicMethod:function(){ util.privateMethod(); };
  }
  
  return obj;
}(); // run it right away

You'll notice I've made a shortcut to the utility object using a private property. This is perfectly fine as it makes your code easier to work with while still leaving the utility methods public.

Sub-module Pattern

I call this the sub-module pattern in that I declare everything within the container to take advantage of closures as a way of shortcutting my references.

MyObject = function(){
  var util = {
    privateMethod: function(){ /* do stuff */ };
  }
  
  var obj = {
    publicProperty:5,
    publicMethod:function(){ util.privateMethod(); };
  }
  
  // do my object attachment
  obj.util = util;
  return obj;
}(); // run it right away

Which of these two approaches you take will depend on code dependencies. If your utilities need to be used on multiple projects but everything else within the object doesn't, then declaring things separately makes sense (ala YUI). Otherwise, you can take advantage of the sub-module pattern to keep things clear.

Example Application

I used the sub-module pattern on a recent project. It was a calendar application much like Google Calendar with a small month view along with day, week and month views. Each calendar view became its own object within the calendar namespace that was defined. The great thing about this was that each of the calendars could basically talk to each other while still having access to some core common values like what the currently selected day, month and year was.

Sourcfe: www.snook.ca