Chapter 7. Modularity

 

1.  To make interdependence of code easier to keep track of, we need to divide their programs into modules, each with its own task, and minimize the amount of “coupling” between these modules—the amount of detail the modules have to “know” about each other.

 

2.  A module can be any collection of functions and values that, together, fulfill some specialized role. A module should expose an interface just like an object does. In fact, a module can consist of just a single object (and its interface).

 

3.  One obvious way to separate modules is by putting every module in a different file. This makes it clear which code belongs to which module.

 

4.  In JavaScript, “top-level” variables all live together in a single space. When a lot of code is loaded into an environment, it becomes hard to keep track of which variable names are used, which makes it very easy to accidentally use a name that was already used for something else. Big modules should try to use as few top-level variable names as possible and not put their internal variables into the top-level environment.

 

5.  The standard trick for hiding variables from the rest of the world is to use a function as a local module namespace. The whole module is written inside a function, and the interface of the module is explicitly put into the top-level environment. It does that by setting properties in the window object, which is an object whose properties represent the top-level variables. (in the browser environment):

function provide(values) {
  forEachIn(values, function(name, value) {
    window[name] = value;
  });
}
(function() {
  var names = ["January", "February", "March", "April", "May", "June", "July",
               "August", "September", "October", "November", "December"];
  provide({
    getMonthName: function(number) {return names[number];},
    getMonthNumber: function(name) {
      for (var number = 0; number < names.length; number++) {
        if (names[number] == name) return number;
      }
    }
  });
})();

 

6.  Some modules export so many variables that it is a bad idea to put them all into the top-level environment. You can represent the module as a single object whose properties are the functions and values it exports. 

 

7.  When there is another module or part of the standard JavaScript functionality that does something similar to what you are implementing, it might be a good idea to make your interface resemble the existing interface. That way, people who know the existing interface will feel right at home.

 

8.  In your interfaces, try to use the simplest data structures that work and make functions do a single, clear thing—if possible, they should be pure functions.

 

9.  When designing an interface for a complex piece of functionality, Often the solution is to provide two interfaces: a detailed “low-level” one for advanced use and a simple “high-level” one for straightforward situations. The second one can usually be built very easily using the tools provided by the first one.

 

10.  Wrapping the optional arguments in an object make the invoking codes more readable (no need to skip the argument by setting it to null). However, it has become harder to figure out which arguments are supported. You should put the comment before the function, listing the optional arguments.

 

11.  jQuery, YUI, Prototype, and ExtJS are toolkits libraries.