SoFunction
Updated on 2025-04-13

From shallow to deep understanding of JavaScript class page 2/2

We have often talked about javascript's OO recently, but please remember that javascript is not an "object-oriented" language, and can only be said to be "object-based".
It is difficult for me to find simple and accurate words to describe the difference between "object-oriented" and "object-based".
When it comes to "object-oriented", we may first think of C++, followed by java, and then dot net, (We will not discuss other non-gate languages ​​here)
In fact, c++ is not as good as java in implementing the "object-oriented" idea, because it still has a lot of "process"-type things. Java has abandoned "compromising and unpractical" things such as multiple inheritance and heavy load operators, and focused its design on interface (interface), which not only simplifies the cumbersomeness of the programmer's work, but also makes the entire framework look clearer. The most important thing is that everything in java exists in the form of a class, and there is no second form. As for the later c# in dotnet, it looks like java with the ms brand.

Going far, go back to javascript
Saying Javascript is not object-oriented is not just saying that it does not really implement object-oriented functions such as abstract objects, inheritance, overloading, etc.
Instead, it is said that "class" in javascript is not the concept of "class" in a truly broad sense. A class is originally just an abstract definition, but a class defined by "Function" in JavaScript is essentially an "object"!

Moreover, the syntax domain of javascript is not the entire IE process, but is based on Window objects.
The same Function definition under different Window objects is not the same "class".

for example:
In you define a class A function A(){}, and in you define the same class A function A(){}

In , you created an instance: var a = new A();
You get the handle to winAhandle in
Then you get a reference to the instance in a
var a = ;
You will find that a instanceof A is false, if it is replaced with a instanceof, it is true
The reason is very simple. Class A in , is not the same as Class A in , and the syntax domain of this "class" is limited to the same Window object (the same Window object does not only refer to the same page)

This is obviously contrary to the concept of class being a broad abstract definition.

Those who know VB should also understand: this is also the case after VB4, the classes in previous VBs (including VBS), although it is defined in the Class.
For example, if you put new A in the session and take it out from the session next time, it will not be the original object.
In fact, because the syntax domain is different, the class defined in the previous time cannot be retained until this time. The parser does not know what it is, so it cannot be restored.

By the way, the inheritance method in javascript is adopted. Prototype inheritance is introduced in detail. You can go to this book to read it.

《Design Patterns Elements of Reusable Object Oriented Soffware》
The Chinese version seems to be called "Reusable Object-Oriented Design Pattern"
A good book! ! !

There is no multiple inheritance in javascript. Multiple inheritance is not necessary in object-oriented. Although multiple inheritance has better reusability, it will cause the relationship between classes to be too complicated.
Generally speaking, we can usually think that a thing is mainly a derivative of a certain type of thing, and single inheritance is enough. As for other characteristics, we can use the help of interfaces to define it.
There is no concept of interfaces in JavaScript. JavaScript does not require interfaces because it is an interpreted language and does not pre-check the types of actual parameters. As a parameter object, if there is a method, it does not check during loading, until it is run, it will be called if there is, and if there is no, it will be exception if there is no. There is no need to mandatory declaration of which interface to be invoked as a parameter.

But in reality, we still need to design some interfaces, mainly for view considerations, and the entire framework is easy to understand!