Unlock the Da Vinci Code in AJAX technology life

Now that Ajax technology is developing rapidly, developers have built a system that invokes a large number of client JavaScript, growing, and complexity. As a result, trying oo technology on JavaScript becomes a means of managing complexity. In the process, most developers quickly realized that JavaScript is a prototype (prototypical) language that lacks the many conveniences the OO itself brings.

Almost every developer who tries to apply object-oriented technology when developing JavaScript is more or less asking itself a question: "How do I call the parent class (Super Class) method?" This problem rarely occurs until Ajax technology is so hot, because most developers use JavaScript only for client form validation or simple dhtml/dom operations. In those simple solutions, functional programming (functional programming) is meaningful, and object-oriented programming is in the second most important position.

Now that Ajax technology is developing rapidly, developers have built a system that invokes a large number of client JavaScript, growing, and complexity. As a result, trying oo technology on JavaScript becomes a means of managing complexity. In the process, most developers quickly realized that JavaScript is a prototype (prototypical) language that lacks the many conveniences the OO itself brings.

The gist of OO design and some of the topics about it are very large, but focus on the definition of class, which I think is the first choice for JavaScript developers to try to solve the problem. So you can find a number of different problem-solving cases on the Internet, but I'm disappointed when I read them--these cases are applied on an occasion, not universal. My interest in this topic comes from the impact of my team's development of the ThinWire Ajax Framework.

Because this framework generates requirements for client-side code, we are "forced" to implement a reliable OO pattern that supports parent-class method invocations. By invoking the parent class, you can further rely on the inheritance characteristics of the class to core the common code, making it easier to reduce repetitive code and remove the bad taste of client code.

Here's a list of some of the solutions I've encountered during my research. In the end, I didn't find a solution that I could accept, so I had to implement a solution of my own, which you'll see at the end of this article.

However, the parent class invocation is the most important OO mechanism here, so I need a corresponding mode of work, and because the stereotype is ugly in my view, I need a more natural way to define classes using JavaScript.

More Solutions:

Well, let's go into the discussion. As developers realize, it's easy to implement basic inheritance in JS, and there are actually some well-known ways:

The Ugly Solution:

There is no simple inheritance to invoke the parent class:

Pre-written JavaScript class definitions and inheritance
Of course, this code is ugly and emits a bad smell of code.
function BaseClass () {
BaseClass constructor Code goes here
}

BaseClass.prototype.getName = function () {
return "BaseClass";
}

function Subclass () {
Subclass constructor Code goes here
}

Inherit the methods of BaseClass
Subclass.prototype = new BaseClass ();

Override the parent ' s GetName method
SubClass.prototype.getName = function () {
return "Subclass";
}

Alerts "Subclass"
Alert (new Subclass (). GetName ());

solution that leads to IE memory leaks:

This implementation can lead to memory leaks in IE, and you should try to avoid:

JavaScript Class definition and inheritance at run time
Looks very traditional, but these scripts can cause memory leaks in Internet Explorer.
function BaseClass () {
This.getname = function () {
return "BaseClass";
};

BaseClass constructor Code goes here
}

function Subclass () {
GetName method for overloading the parent class when an object instance is established
This.getname = function () {
return "Subclass";
}

Subclass constructor Code goes here
}

Inherit the methods of BaseClass
Subclass.prototype = new BaseClass ();

Alerts "Subclass"
Alert (new Subclass (). GetName ());

As I noted in the first implementation, the first implementation is a bit ugly, but it's preferred compared to the second way to cause a memory leak.

The reason I put these two methods here is to point out that you should not use them.