JavaScript “Code Reuse” — Part 2–2 : Pseudo-classical Classes
[JL’s Coding Bootcamp Story] Series
JavaScript “Scope & Closure”
JavaScript “This”
JavaScript “Call, Apply, Bind”
Summary of CodeSchool’s “Try jQuery”
JavaScript “This” — Advanced
JavaScript “Code Reuse” — Part 1–1: Decorators
JavaScript “Code Reuse” — Part 1–2: Functional Classes
JavaScript “Prototype Chains”
JavaScript “Code Reuse” — Part 2–1: Prototypal Classes
JavaScript “Code Reuse” — Part 2–2: Pseudo-classical Classes (Current)
[library code]
var Car = function(location) {
var obj = Object.create( Car.prototype );
obj.location = location;
return obj;
};
Car.prototype.move = function() { this.location++; };[run.js]
var amy = Car(1);
amy.move();
var ben = Car(9);
ben.move();
Let’s refactor this pure prototypal code into its sister pattern “pseudo-classical.” It tries to resemble the class systems of other languages by adding a thin layer of syntactic conveniences. When making a lot of classes in our programs, there’s a lot of code that would get repetitive.
[library code]
var Car = function(location) {
var obj = Object.create( Car.prototype );
obj.location = location;
return obj;
};
Car.prototype.move = function() { this.location++; };[run.js]
var amy = Car(1);
amy.move();
var ben = Car(9);
ben.move();
Two highlighted lines of codes would get repeated in every prototypal class. They’ll require an instance object to operate on (obj), need to make delegate it to the prototype (Object.create), and return it.
[library code]
var Car = function(location) {
var obj = Object.create( Car.prototype );
obj.location = location;
return obj;
};
Car.prototype.move = function() { this.location++; };[run.js]
var amy = Car(1);
amy.move();
var ben = new Car(9);
ben.move();
To alleviate the issue, JavaScript provides the keyword “new.” Whenever we choose to put it before a function invocation, it runs that function invocation in a special mode called “construction mode.”
“Construction mode” temporary makes your function run as if there were some extra line of code at the beginning and end.
The inserted lines are basically the work you’ll be doing anyway when building instance objects.
Although this code illustrates what happens if you call the same function with and without the keyword new in one program, you’d never purposefully do this. You’ll design some functions to produce instances and others not to.
Therefore, when designing a class in the pseudo-classical style, we’re always going to call a function with the keyword new. Also, we need to refactor our code. Let’s start by taking out the code we wrote to build an object that delegates to Car.prototype, since we trust that will be done for us on the first line that gets inserted.
[library code]
var Car = function(location) {
This = Object.create ( car.prototype );
var obj = _____________________________;
obj.location = location;
return obj;
return this;
};
Car.prototype.move = function() { this.location++; };[run.js]
var amy = new Car(1);
amy.move();
var ben = new Car(9);
ben.move();
In addition to making a new object that will delegate to Car.prototype, the inserted line uses the keyword this to refer to the new delegating object. Since Car is a constructor used to make instance objects, binding this to the new instance supports the general promise about the key word this : that it should refer to a focal object of an “object-oriented” function call.
So, in this case, where JavaScript has made sure that we have an access to a new delegating object in regard of the keyword this, we can throw away all references to the “obj” variable and replace them with references to this.
Because we got rid of the obj variable in favor of using the object provided on behalf of this, the last line(“return this”) looks even more redundant than it did before. So, we can remove it and rely on the inserted one.
[library code]
var Car = function(location) {
this.location = location;
};
Car.prototype.move = function() { this.location++; };[run.js]
var amy = new Car(1);
amy.move();
var ben = new Car(9);
ben.move();
We’ve explored how the code inserted by new will affect our function and refactored our code accordingly. Let’s look at our code the way it would actually appear in the files as we’re editing them. The code above is the completed pseudo-classical version of our Car class.
Notice that pseudo-classical class diagram is exactly same as the prototypal version of the code. That’s because the pseudo-classical pattern is just a thin layer of syntactic convenience on the top of the prototypal pattern.
This code has two distinct sections like many class patterns in JavaScript. This is true in every pseudo-classical, prototypal, and functional-shared class in JavaScript.
[library code]
var Car = function(location) {
this.location = location;
}1. Specify how each instance should be different from others. That will take place inside the body of the constructor function.
Car.prototype.move = function() { this.location++; }; 2. Specify how all instances of a class should be similar. In the case of the pseudo-classical pattern, those similarities are generally stored as properties on the prototype.
For now, this is just an interesting observation about classes. But, knowing that these two categories of code exist for every class will become very important later when we start discussing “subclassing.”
Functional class does not make such distinction. All the code for both categories appear in one place. Depending on perspective, you could call this an asset or a falling of the pattern.
There are many different class patterns in JavaScript. JavaScript takes remarkably few stances and tends to make internal features visibly available to allow programmers to play with. So, rather than “rights” and “wrongs”, there are only “techniques” and “options.” We need to learn advantages and disadvantages of different techniques to decide which pattern to use on a case-by-case basis.
[library code]
var Car = function(location) {
var obj = { location : location };
obj.move = function() { this.location++ };
return obj;
};[run.js]
var amy = new Car(1);
amy.move();
var ben = new Car(9);
ben.move();
For example, one drawback in the code above is the creation of a new method for every instance. On the other hand, we have an advantage of having a class extremely easy to read and explain. Because code clarity is extremely valuable, it is good to use the functional pattern for most classes as long as you don’t create thousands of instances.
[library code]
var Car = function(location) {
var obj = { location : location };
obj.move = function() { obj.location++ };
return obj;
};[run.js]
var amy = new Car(1);
amy.move();
var ben = new Car(9);
ben.move();
Another advantage is that you can avoid using the keyword this.
[library code]
var Car = function(location) {
this.location = location;
};
Car.prototype.move = function() { this.location++; };[run.js]
var amy = new Car(1);
amy.move();
var ben = new Car(9);
ben.move();
The pseudo-classical pattern is another main contender, because it appears to be equally simple. However, the major downside is that what is under the hood is complex.
Since JavaScript debuted in 1995, the pseudo-classical pattern has been publicized. So, it’s deeply rooted in the JavaScript community.
Let’s compare the pseudo-classical version of the code to the functional style to compare their simplicity and legibility.
[library code]
var Car = function(location) {
var obj = { location : location };
obj.move = function() { obj.location++ };
return obj;
};[run.js]
var amy = new Car(1);
amy.move();
var ben = new Car(9);
ben.move();
The functional style code takes up about the same amount of space and requires much less explanation to JavaScript newcomers. For this reason, some people avoid using the pseudo-classical pattern unless it’s required. Be aware that using the functional pattern can draw criticism from old-guard JavaScripters who adhere to the familiar and widely-documented pseudo-classical dogma. Therefore, it’s good idea to use the functional pattern only when you aren’t concerned that you’ll be judged badly for it and you don’t need to create a large number of instances.
[Note] This blog post is written based on a lecture from CodeStates.
Thanks for reading! 💕 If you like this blog post, please clap👏
