JavaScript_javascript tips for embracing modularity

We are once again enveloped in the term and concept of computers.
backbone, emberjs, spinejs, batmanjs and other MVC frameworks invaded.
CommonJS, AMD, NodeJS, RequireJS, SeaJS, curljs Wait for modular JavaScript to come.
The concept of modular JavaScript is particularly strong, and it seems to be catching up with the Ajax trend in 2007.
1. Writing functions (procedural)
Before 2005, no one paid much attention to JavaScript, and it was only used in a small number of applications such as form validation. At that time, you could only write a few lines of JS code on a web page, and 1,000 lines was considered very complicated. At this time, the way to organize the code is a process, and there is no need to write even a single function for dozens of lines of code. A little more requires abstracting a function, and a more complex one requires more functions, and the functions call each other.


2. Writing classes (object-oriented)
In 2006, Ajax swept the world. JavaScript is taken seriously, and more and more back-end logic is placed on the front-end. The amount of JS code in web pages has increased dramatically. At this time, writing functions to organize a large amount of code seems to be insufficient. Sometimes when debugging a small function, you may jump from one function to the Nth function. At this time, the way of writing classes appeared, and Prototype took the lead in becoming popular. Use it to organize code and write classes one by one. Each class is created by Class.create. There are also heavyweight frameworks such as YUI and Ext. Although they have different ways of writing classes, their design ideas are all to meet the development of a large amount of JavaScript code.

3. Writing modules (now, future?)
In 2009, Nodejs was born! This server-side JavaScript adopts modular writing method and quickly conquered the browser-side JSer. Excellent people have followed suit one after another, and various specifications for writing modules are also emerging one after another. CommonJS wants to unify the writing methods of front-end and back-end, while AMD believes that it is suitable for the browser side. Well, no matter what the style of writing modules is, writing modular JavaScript has become popular. Are you ready? (Uh, provocative)

Hey, what is modular JavaScript? Is this another silver bullet we’ve invented? No matter what it is, just study it. As for whether it is suitable for use in projects, it is up to each individual to decide.

Writing this, I didn’t say anything about a “module”. In fact, in the computer field, the concept of modularity has been promoted for nearly forty years. The overall structure of the software embodies the idea of ​​modularization, that is, the software is divided into some independently named components, and each component is called a module. When all the modules are assembled together, a solution to the problem can be obtained.

Modularization is based on the divide and conquer method, but does it mean that we can subdivide the software without limit? In fact, when the division is too fine and the total number of modules increases, the cost of each module does decrease, but the cost of the module interface increases. To ensure reasonable segmentation of modules, it is necessary to understand information hiding, cohesion and coupling.

Information Hiding
Modules should be designed so that the information they contain (processes and data) is not visible to modules that do not need to use it. Each module only completes an independent function and then provides an interface for this function. Modules are accessed through interfaces. In JavaScript, you can use functions to hide, encapsulate, and then return interface objects. The following is a module event that provides event management.

Copy code The code is as follows:

event = function() {
// do more
return {
bind: function() {},
unbind: function() {},
trigger: function() {}
};
}();

In order to implement the desired interfaces bind, unbind, and trigger within the function, you may need to write a lot of code, but these codes (process and data) do not need to be made public to other modules. As long as the interfaces bind, unbind, and trigger can be accessed externally, Can.

The benefits of information hiding for module design are very obvious. It not only supports the parallel development of modules, but also reduces the workload of testing or post-maintenance. If you want to modify the code in the future, the hidden parts of the module can be changed at will, provided that the interface remains unchanged. For example, when the event module was first implemented, a lot of IE Special code was written in order to be compatible with the old version of IE and standard browsers. One day the old version of IE disappeared (in the year of the monkey and the month of the horse), and it only needed to be deleted calmly.

Cohesion
Cohesion refers to the internal implementation of the module. It is a natural extension of the concepts of information hiding and localization. It marks the close integration of the components within a module. degree. The benefit is also obvious, it is much easier to read when related tasks are grouped.
When designing, module cohesion should be improved as much as possible to achieve higher module independence.

Coupling degree
Cohesion refers to a measure of the internal implementation of a specific module, while coupling degree refers to a measure of the degree of association between modules. The degree of coupling depends on the complexity of the interface between modules, the location where the module is entered or called, etc. In contrast to cohesion, loosely coupled systems should be pursued when designing.