JS design patterns – Understand a single example pattern

This is the 16th day of my participation in Gwen Challenge

1. Introduction

The singleton mode says it can only be instantiated once, and if it has already been instantiated, it does not need to be instantiated. What I’m thinking about here is the instantiation process, which starts with an object, and that object can only be instantiated once. Objects that exist once in JS include literal direct quantities and modular modular objects with specific functions (this may be an imprecise statement, but this is just my own definition).

Modularity A module object with a specific function

Then we talk about another kind of existence, modularizing module objects with specific functions. I say imprecise because modularized objects can also be instantiated multiple times. So the point of this particular function is that it internally checks if it’s instantiated, and if it’s instantiated, don’t create new objects.

For one thing, requie caches created modules in an array while loading modules, and checks if a module already exists when it is accessed. If it already exists, it will not be created. So this is also a singleton behavior. But the point of this singleton pattern is that require doesn’t want to waste too much memory creating new objects.

Some people might mention creating new objects, which are destroyed when the JS engine detects that the object is no longer in dependent use. The mechanism of garbage collection must be checked (probably more than once) to confirm that the current object is no longer in use, which is also performance related (I suspect).

What is the point of saying the above

Because design patterns are meant to improve code reusability, enhance system maintainability, and solve a series of complex problems. If we use code to create objects without having to do so many times, we actually increase the reusability of objects. We spend memory to create objects to do a function, not to do a job and then walk away. If the modularity requires some memory for interacting with other modules, then the reconstructed object is definitely gone. Of course, you might say that this memory can be handed over to the system module above the module level, but that would not increase the burden of system maintenance, I also need to go to the system object to find.

Here you may feel that said is not too clear, may not be a good example plus my understanding is not deep enough. The above example is used to introduce two key languages. One is that the object is created only once, and the other is a matter of memory.

Now that we move the modular object up to the System level, Requie’s module can determine whether it exists by its array, whereas system’s module can only determine whether it exists by itself, so it has an internal mechanism to determine whether it has been instantiated. For the function of memory, that is possible, after all, it is used to correlate communication between modules, so memory must be needed,

But as a system object, it must have robustness, not other modules can be modified at will, which is also related to the vulnerability of the object direct quantity mentioned above. Because the object of the module can keep its own memory part unexposed. (of course, you might say the object directly amount setter can put your own variables, and their strict control, but if is so complicated, so we should use a complete module to maintain his, because I think if directly using the object directly in the development process, developers do not necessarily spend too much time to think about its maintainability, Robustness, of course, is in the family).

The idea here is that a singleton object is an object that is instantiated only once, remembers its contents, and is robust and maintainable.

​

var SingletonTester = (function () {
    //private property.
    var _property1 = "something".var _property2 = "something else".// options: an object containing configuration options for the singleton
  // e.g var options = { name: "test", pointX: 5};
  function Singleton( options ) {
 
    // set options to the options supplied
    // or an empty object if none are provided
    options = options || {};
 
    // set some properties for our singleton
    this.name = "SingletonTester";
 
    this.pointX = options.pointX || 6;for (var i = Things.length - 1; i >= 0; i--) {
        Things[i]
    }
 
    this.pointY = options.pointY || 10;
 
  }
 
  //flag variable
  var instance;
 
  // an emulation of static variables and methods
  var _static = {
 
    name: "SingletonTester".// Method for getting an instance. It returns
    // a singleton instance of a singleton object
    getInstance: function( options ) {
      if( instance === undefined ) {
        instance = new Singleton( options );
      }
 
      returninstance; }};return_static; }) ();var singletonTest = SingletonTester.getInstance({
  pointX: 5
});
 
 
/* Call the public method to get the instance :*/
Singleton.getInstance().publicMethod();
Copy the code

​

3. The shortcomings

The disadvantages of singleton mode are not flexible and easy to expand. It is easy to scale to a single module object, simply because the singleton pattern applies at the system level.

But I want to say is a system for multiple users to communicate with each other in the module, its function is essentially to the communication between the interaction of various modules, with the increase of the business, about the function in the singleton pattern is likely to increase, more believe that the function of the system level to module communication, rather than for a particular module processing).

If new business is added, the necessary processing should be done in the tools module, and the previous API calls should still be made at the system level. Of course, unless there is an architectural update, the system object can no longer run, in which case it must be added.