This blog focuses on some of the patterns that JavaScript uses to create objects. Want to in-depth detailed understanding or suggest you read a book.
Speaking of creating objects, normally I should talk about creating girlfriends. But want to think I am female, also have no special interest, so I still don’t create girlfriend. Ok, here we go :older_man: that’s angel: God. : Older_man: I’m going to have a baby.
First I made an Adam, then an Eve. Print it out. I’ve made it.
They had children named Cain and Abel, and went on to make Cain and Abel, and it worked.
But do you see the problem? It’s a lot of duplicate code. Older_man: It would be exhausting to make six billion people. So, I have to do with nuwa, with vines with soil, to the ground a shake, the mud point point can adults. So I went into factory mode.
The factory pattern
A factory pattern is a function wrapper that creates objects in a particular pattern
:older_man: Encapsulates the creation object with a function.
Instead of eight lines of code for two people, now eight lines of code for two people
Instead of 16 lines of code for four people, 10 lines of code for four people.
It’s not enough to make people. I have to make animals. Snake lured Eve into eating an apple, and Abel Cain got a sheep. I’m going to start making animals.
Ok, so now I’ve built them, but the question is, even though I used three functions to build them, why do they all output the {} form of normal object? All things are equal? Older_man: No, all things are equal and I made man. So I have to separate them. This is where the constructor pattern comes in.
Constructor pattern
The constructor pattern uses a constructor to create an object of a particular type
The constructor looks like this:
/ / declare
functionThe function name (parameter){function body}/ / use
letInstance =newFunction name (parameter)Copy the code
And then I create it as a constructor. You see, we’re missing declaration objects and return values.
But here’s the problem again. Is that easy? Isn’t that a lot of duplicated code? This. Name this. Gander. So I’ll just keep simplifying. This is where the archetypal pattern comes in.
All right, now let them give us a shout. The problem is, if I want the sheep to beep and the snake to beep, won’t that be a lot of the same code? This can be solved using a prototype pattern.
The prototype pattern
Every function we create will have the Prototype property, which is a pointer to an object containing various methods and properties shared “by all instances of a particular type.”
So an instance is let instance = new function name () and this thing that you’re declaring is an instance. This is abstract and concrete. Your function is abstract, and your instance is concrete.
If you want to know more about the prototype, you can see this JavaScript detailed illustration of the prototype.
I’m not going to go into the prototype, I’m going to go into the method.
Since :older_man: wants to write a little less code, I’ll just write the same things directly into the prototype. The end of the prototype chain is Object, so I’m just going to write Object.
Just add the same method to a stereotype and use it as long as the instance is in the stereotype chain. I don’t have to declare every function.
Then you might ask, why don’t you just include name and Gander in the prototype.
It could be, but it doesn’t reduce the amount of code. Because you’re going to assign a value to these properties, you’re going to take it out and assign it again.
You see it. The methods that don’t change are written in the prototype, so the functions don’t have to be written. But the method that needs to be changed, you write in the prototype, it doesn’t matter if you don’t assign a value to it in the body of the function. That’s why we use a combination of the constructor pattern and the prototype pattern.
Use a combination of the constructor pattern and the prototype pattern
This is the most common way to create custom types. Common methods and properties that do not need to be reassigned can be written to the stereotype, while specific properties can be written to their respective function bodies.
All the creatures in the picture below say ‘I am made by God’, which is an attribute that doesn’t need to be changed, so it can be added to the prototype.
Dynamic prototype mode
Check for the existence of a method to determine if the prototype needs to be initialized.
For example :older_man: adds the speak method to the Person prototype.
Older_man: Suddenly don’t want to be God again. You can have it.
But when you get my code, you want them to say “I am XXX,” but you don’t know if I have this method in it. So what do we do? We use dynamic prototyping.
Guess if the code below prints “I am XXX” or “ha ha ha I am XXX” after it is used?
The answer is:
The red box is to dynamically add the prototype, and determine if the method is in the function prototype before adding it. I’ve already written the speak method for Person, so I’m not going to add it.
The parasitic constructor pattern
If you compare this to the factory model, you’ll see that there’s only one new
Safe constructor pattern
The safe constructor pattern creates an object instance method that does not reference this and does not use the new operator.
Safe objects: objects that have ‘no public properties, and methods that do not reference this’
Secure objects are best used in secure environments or to prevent data from being altered by other applications.
Today, I also succeeded