JLA framework introduction (5) design mode: module and instance Management

Today I want to share with you module management, which is a very important part of the JLA framework. The model introduced in this article will be more controversial than the core of the JLA framework described earlier, frankly speaking, my solution targets complicated design patterns, but does not propose its own solution. At most, it only makes the problem clearer.

 

As we all know, developing a more complexProgramThe idea of OOP alone cannot solve the problem, because OOP solves the problem of inter-class organization and the solution of coupling between various functions, I have not proposed any substantive solutions. There is a widely spread "scalable JavaScript architecture" solution on the Internet, and there is also a PPT. The main idea of this solution

 

 

In general, the sandbox mechanism is used to split the functional logic into modules. Each module is independent of each other and is not coupled with each other, so that each module only knows the sandbox, without knowing other modules, interrupting the relationship between modules ensures the independence of each module, and the execution of the entire architecture will not be affected after some modules are removed.

This architecture can solve many problems. The "Subject + control" Mode I used in previous development actually uses this mechanism to solve the coupling problem, but there is no sandbox.

However, when I was designing the new JLA framework, I found that there are still some problems with this design model. In general, it is as follows:

1. any module is determined to be a module during development. If you want to simply use the functions of a module and do not want to build a large sandbox to adapt, it will be complicated, similarly, if you transform a class into a module, it may take some effort, because although each module is not coupled with other modules, it is too tightly coupled with the sandbox itself.

2. during development, the module assigns its methods and events to the sandbox. If the two modules adopt the same method and event name, it will cause confusion, in this way, when developing each module, you must be careful not to duplicate the names with other classes, affecting the independence of module development.

3. sometimes, the functions on the page are not a simple flat structure and may be more like a tree structure. For example, the whole page is divided into multiple modules, one module is composed of multiple finer modules. The current sandbox mode may be difficult to develop based on this structure.

 

Is there a way to solve these problems?

 

When I began to carefully analyze the relationship between the subject and the module, I found that it is actually the association between various class instances. In fact, the association with the class itself is quite similar, with this in mind, we can consider transforming the sandbox above into a simple instance manager without implementing any other functions. The coupling between modules is similar to JLA. implement the require mode.

Let's take a look at two simple modules.CodeThe following is the first simple module:

 

1
2 JLA. Require ([ " JS. Event " ], 2 , Function (Event ){
3 /* *
4 Module used to record message in JS Architecture
5 @ Class
6 */
7 Function APP ()
8 {
9 }
10 App. Prototype. Log = Function (Message, level)
11 {
12 Event. Trigger ( This , " Message " , [Message, level]);
13 }
14 App. modfactory = Function (Holder, name)
15 {
16 Holder. Require ([], 2 , Function ()
17 {
18 Holder. Set (name, New APP ());
19 });
20 }
21 JLA. Set ( " Test. Logging " , APP)
22 });

 

 

The preceding simple module code shows the following features:

1. This code is a simple class definition. The namespace of this class is"Test. Logging", The only difference is that the modfactory static method is added. When this method is called, it is required to create an instance with the specified name for the specified parameter holder. After the creation is complete, it calls holder. set function Registration

2. If you do not need to use the module mechanism, you can still use this function logic by directly going to the new class.

3. The module does not need to know who the subject is and does not care about its own name in the module system. Therefore, it is no problem to use this module multiple times on a page.

Let's look at the code of another module:

 

JLA. Require ([ " JS. Event " ], 2 , Function (Event ){
Function APP (logging, Div)
{
This . Div = Div | Document. getelementbyid ( " Msgdiv " );
Event. BIND (logging, " Message " , This , This . Showmessage );
}
App. Prototype. showmessage = Function (Message)
{
This . Div. innerhtml = Message | "" ;
}
App. modfactory = Function (Holder, name)
{
Holder. Require ([ " Test. Logging " ], 2 , Function (Logging)
{
Holder. Set (name, New APP (logging ));
});
}
JLA. Set ( " Test. pagelogging " , APP)
});

 

 

This Code uses the coupling between two modules. From this example, we can further understand the following features:

1. the coupling between the two modules does not pass through holder, but directly requests to the instance of the other module from holder. Subsequent operations are carried out directly instead of using holder, no methods or events are added to Holder. Therefore, you do not need to worry about conflict between methods and event names.

2. if you use new test. pagelogging (new test. logging () directly uses these two classes to implement functions. Therefore, the module system is optional for these two classes, whether there is a module system or not, can run and complete coupling

Let's take a look at the simple example code of holder:

 

 JS. Holder

 

 

As long as you inherit the above Js. Holder, you can load your own sub-modules. Based on the above three code examples, you can know:

1. There are no strict format requirements for module development. You only need to implement the modfactory static method, and any class can become a module;

2. Most modules can complete their own functions from the module system. Of course, if the module needs to call the holder. Require method during running, it must work in the module system.

3. A module can inherit Js. Holder to further split its functions.

4. different from the sandbox system that does not allow direct interaction between modules, this mode requires each module to clearly understand the modules to be coupled, and the events and methods of the target module must be clearly understood.

 

Compared with the Sandbox Model above, this mode seems to have its own advantages and disadvantages, but I haven't thought too clearly about which one is better, which is more suitable, and what is the situation, but for the JLA framework, I am very concerned about the reusability and independence of each code unit. Therefore, the model mentioned in this article seems to be better. I hope you can leave your own opinions and discuss them together.