Home > Article > Web Front-end > Use prototypes and closures to complete component methods
Java code
var Player = (function(){
Player = function(){ //This is just an empty shell
throw new Error("Can not instantiate a Player object.");
};
Player.MIN_EXTENDED_TIME = 1;
Player.MAX_EXTENDED_TIME = 3;
Player._player = false;
Player.getInstance = function(){
if(!Player._player){
alert("Init...");
Player._player = {
return Player._player;
};
return Player; //Return the repaired Player component method
})();
//var player = new Player(); //new Player() will throw Exception
var player1 = Player.getInstance();
var player2 = Player.getInstance();
player2.setName("RealPlayer");
alert(player2.toString()); //Output RealPlayer
Finally defined A component method is implemented using prototypes. Take a look at this:
Java code
function Player(name){
Player.MIN_EXTENDED_TIME = 1;
Player.MAX_EXTENDED_TIME = 3;
this._name = name;
};
Player.prototype.setName = function(name) {
this._name = name;
};
Player.prototype.toString = function(){
return "Player: " + this._name;
};
var player = new Player("WindowsMediaPlayer");
alert(player.toString()); //Output WindowsMediaPlayer
player.setName("RealPlayer");
alert(player.toString()); //Output RealPlayer
alert(Player.MAX_EXTENDED_TIME);
Well, yes There are encapsulation, constants, and the toString method that overrides Object. As for things like inheritance, we will talk about it later. At first glance, it looks good. However, this kind of component method definition is not elegant and intuitive enough. The methods are defined in independent locations and are not placed together with the original component method. Wouldn't it be better if it could be defined like Java?
By the way, it can be implemented using closures. Give it a try:
Java code
function Player(name){
Player.MIN_EXTENDED_TIME = 1;
Player.MAX_EXTENDED_TIME = 3;
this._name = name;
this.setName = function(name){
this._name = name;
};
this.toString = function(){
return "Player: " + this._name;
};
};
var player = new Player("WindowsMediaPlayer");
alert(player.toString ()); //Output WindowsMediaPlayer
player.setName("RealPlayer");
alert(player.toString()); //Output RealPlayer
alert(Player.MAX_EXTENDED_TIME);
Unlike Groovy, closures are used It has been strengthened to a large extent, including support for new syntax; JavaScript closures are very simple closures. It has no special syntax that requires additional learning. As long as any function contains unbound variables, these variables is defined in the context to which the function belongs, then this function is a closure. By the way, isn't the opposite of a closure a functional code that doesn't contain any unbound variables?
I finished writing it, but then I thought, there should be only one copy of Player and it is a singleton. It would be best if I could create a singleton mode like Java :), but things didn’t work out and I couldn’t do it. JavaScript makes a private constructor. It seems not feasible to implement the singleton pattern using this idea...
What should I do?
However, there is always a way, I can’t control your new Player object, but I can control the properties and behavior of your new Player object! When you need to use your new Player object, you find that it can't be done at all, or it is just an empty shell! The real thing still depends on the classic getInstance method in the singleton:
Java code
function Player(){
throw new Error("Can not instantiate a Player object.");
}; //This is just an empty shell
(function(){ //This is the real thing
Player.MIN_EXTENDED_TIME = 1;
Player. MAX_EXTENDED_TIME = 3;
Player._player = false;
Player.getInstance = function(){
if(!Player._player){
alert("Init...");
Player._player = {
_name : name ,
}
};
}
return Player._player ;
};
})();
//var player = new Player(); //new Player() will throw an exception
var player1 = Player.getInstance();
var player2 = Player.getInstance( ; (); will throw an exception, so nothing will be obtained. Only the object obtained by the getInstance method is the real Player object. As a result of the entire execution of the above code, the "Init..." dialog box pops up only once, indicating that the real "constructor logic" is only called once.
I have achieved this, but there is still a small regret. The definition of Player is still split into two parts, one part defines an empty shell, and the other part is an anonymous function to define Player’s constants and getInstance method. Can't these two parts be combined into one?
Yes. You only need to use a small anonymous function. If you have the patience to read this from the beginning, you will definitely understand:
At this point, I am finally relieved, have a deep understanding of JavaScript object-oriented, and make good use of the two sharp weapons of prototypes and closures. Only in this way can you write excellent front-end code. Some colleagues communicated with me privately. I will try my best to post concise code later. I hope colleagues with a basic object-oriented and JavaScript foundation can benefit from it.