JavaScript as a Classical OOP Language

Academically a language like JavaScript has its flaws. The one that is brought to my attention most often is the fact that the language is loosely typed. I find JavaScript even more elegant for this very fact. Let me explain why by example. In Java we could handle some string processing this way:

String[] stringarray;
String str = “My name is nobody”;
stringarray = str.split(" ");
str = thing[3];
System.out.println(‘My name is ’ + str);

Now an opportunity to express this in JavaScript.

var str = “My name is nobody”;
str = str.split(“ “);
str = str[3];
alert(‘My name is ’ + str);

While the JavaScript is less descriptive it is more direct. But the difference is just a single line of code saved and programming is not only about efficiency it’s about building general code so we can be free to enhance our libraries. The act of using JavaScript as a functional language is frankly, a waste of our time. The difference between programming and writing JavaScript is the objects. Unlike a classical OOP language like Java, JavaScript is overlooked as a language capable of OOP. In my opinion if it can be written as a function it probably should have been written as a class. To further this concept let us then consider a common OOP structure, the class:

function JSClass (){
  //Properties
  var private_property = ‘private’; //private
  this.public_property = ‘public’;  //public
  //Methods
  var private_method = function(){
    alert(private_property);
  };
  this.public_method  = function(){
    alert(this.public_property);
  };
}

Of course we have to instantiate the class in order to use it but let us save that for later. We should talk about why we need to use a class in the first place. From a traditional standpoint classes give us access to a private namespace. We can safely use “global” variables within the classes scope. Also we can better control the lifespan of our code modules. Better yet we have the option for clean variable replication in the case of struct like classes. We all know that globals are bad news right, so why place a function within the global scope, it can be just as dangerous as a global variable. If we are trying to generate general code it is rare that a single function can do all the work. Thus we commonly end up with a number of small functions which exist in a similar task chain totally unassociated. Another rule, If you have written a helper function that is only called by another function of the same task you should have create a class. To continue, let’s look at how we can manipulate this object. Once the class has been defined we have two ways to add member functions to it. The first is by calling the class by name and giving it a static public member like thus:

JSClass.public_static_method = function(){
  alert(‘Public Static’);
};

I have seen examples like this all over the Internet but I can’t for the life of my figure out why anyone would do it. Especially when we can prototype a function or more importantly another class. My criticism of the above method of adding a public function to a class exists also for prototyping functions to do the job except for the case of adding a function to a built-in JavaScript Object. Let us consider we would like to, albeit trivial, provide a shortcut to alerting the contents of a string. Since we generally do not have access to the String object from a source level we must prototype a new method attached to the object via prototype.

String.prototype.alert = function(){
  alert(this);
};

“Too Convienent”.alert();
var noreally = “too easy”;
noreally.alert();

The real power inherent in prototyping is that it allows us to pass the constructor of an existing class into another object. Prototyping used in this manner gives us the JavaScript implementation of inheritance. Let’s look at a trivial example of prototyping our class from above.

function JSChildClass(){
  this.display_inheritance = function(){
    this.public_method(); //public method from JSClass
  };
}
// Here we extend the orig JSClass
JSChildClass.prototype = new JSClass();
var class = new JSChildClass();
class.display_inheritance();

It really is that easy, the only downside is that like Java, JavaScript can only handle single inheritance. But since better languages then this have failed that test no reason to worry about it. The piece to take away is that there is almost no reason to write a function for single use.

I know I have convinced you to always write JavaScript in Classes. I can feel it, so lets finally cover a few of ways to define and instantiate your class. There are actually a few valid syntaxes for dynamically bind-able class definitions but some are better then others.

//  First Way
function class(){
  this.property = "1";
};  // this is the most basic method
     // it creates a class object that is not anonymous and supports garbage hadeling

// Second way  Same features as the first
var class = function class(){
  this.property = "1";
}; // This creates a dynamic class with an alias for a name
    // I have named them the same but only way to instantiate this class is with the alias
    // defined by the var

// Avoid using this Third way
var class = function(){
  this.property = "1";
}; // This is only a variation from the second example but because we did not name the function as wee
    // it is considered anonymous and is not subject to garbage collection.
    // in general this structure should be avoided

// For all three of these options the instantiation is dynamic and identical
var classobj = new class;
alert(classobj.property);

It is easy to make the mistake of using anonymous functions as the base of a class definition but we should avoid this upon the class level. I am a little looser when defining class methods by leaving them anonymous because they exist in a garbage collected namespace of the class object and will be eventually handled. The last kind of binding is static, this is accomplished by effectively starting the definition off dynamic bound using the new operator.

var class = new function class(){
  this.property = "1";
};  // Garbage collected Public static class

var class = new function(){
  this.property = "1";
};  // this static object like the third example above should be avoided because the dynamic bind that the
     // static object is based off of is anonymous and will not be properly garbage collected

// there is no instantiation of these classes as you did it when they were defined so access is like this
alert(class.property);

My advice is to treat JavaScript like Java. If it needs to be done it can be written as a class. Consider the power of Java due to the endless supply of generic modular packages. If JavaScript was always written this way we would have no end to the modules to expand the language. I know that others out there share my sentiments or we would not have frameworks like jQuery and Prototype JS but that is not enough, and in the case of wastefully creating single use scripts that seem to exacerbate the problem, I respond with my motto is, “just cause it’s the Write Less Do More library doesn’t mean we actually have to write less”.

Additional resources:
http://blog.webcom.it/articles/2006/05/24/private-static-members-in-javascript/

http://mckoss.com/jscript/object.htm