What do you mean? You are wrong, JavaScript is an Object Oriented Programming language!
NO… IT’S… NOT!
If anyone else tries to tell you that, you need to slap them! It has object-oriented like features but it is not object-oriented in nature!
Prove it!
Classical definitions for object-oriented programming languages usually talk about two main features that make a language object-oriented:
1) Encapsulation
In computer science, the principle of information hiding [aka encapsulation] is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). — WIkipedia
JavaScript does not support information hiding. There are neither “true” private nor protected members/methods. Everything is public!
If I create an “Object” in JavaScript, any properties I put in that object can be accessed and modified by anyone who has a handle on that object!
2) Polymorphic Inheritance
More precisely, polymorphism (object-oriented programming theory) is the ability of objectstypes to respond to method calls of the same name, each one according to an appropriate type-specific behavior. The programmer (and the program) does not have to know the exact type of the object in advance, so this behavior can be implemented at run time (this is called belonging to different late binding or dynamic binding). — Wikipedia
Polymorphic inheritance is the main driving reason that gives Java and C++/C# its user base. It allows for an easy way for code reuse and object generalization. From the sub-class, you can access members and methods of the super-class; JavaScript can’t do this.
The reason for this is explained by the differences between HAS-A and IS-A object relationships
IS-A relationships contain a hierarchy of objects where any sub-class of an object IS also a type of the super-class!
When ObjectB extends another ObjectA, the type of the ObjectB is both ObjectB and ObjectA! That way I can make other objects that pass around ObjectA’s which may or may not be my ObjectB!
Think of the classical Shape example. There are a bunch of shapes out there and they all share some properties, but they do have many different properties that they don’t share. Well why not put the shared properties into a super-class and have shapes sub-class them.
// Shape base Object
public class Shape {
protected String name = "Shape";
protected int sides = 0;
public String toString() {
return this.name + " (" + this.sides + " sides)";
}
}
public class Square extends Shape {
public Square() {
this.name = "Square";
this.sides = 4;
}
public String toString() {
return "It's hip to be a " + super.toString();
}
}
public class Driver {
public static void main( String [] args ) {
Shape myShape = new Square();
System.out.println( myShape );
}
}
In the above example we can create a Shape object (myShape) and set it to a new Square. Why does this work? IS-A relationships dictate that since Square extends Shape, Square must also be a Shape. Therefore, we can store sub-classes of Shape into a Shape object reference and it will work fine.
Moreover, when the toString() method is called on myShape, dynamic binding helps to correctly call the Square.toString() method instead of Shape.toString()!
HAS-A relationships exists via a form of object composition (where 1 object contains another object and uses it’s methods).
In JavaScript, “extending an object” (doesn’t really exist) means just appending the super-objects members and methods to the sub-object. It’s really not any more difficult than that; you can’t ask or test a JavaScript Object if it is both the super-object and sub-object types.
This is called prototypal inheritance.
// Shape base Object
var Shape = function() {
this.name = "Shape";
this.sides = 0;
this.toString = function() {
return this.name + " (" + this.sides + " sides)";
};
};
var Square = function() {
this.name = "Square";
this.sides = 4;
};
// Starts the HAS-A relationship
Square.prototype = new Shape();
// Test new Square
alert( new Square() );
If you needed to access anything from the super-object, there is no way of doing that using JavaScript’s object model unless you followed object composition where Square carried around an instance of Shape.
Moreover there is no way create a Shape reference and have it stored as a Square as in the previous Java example because HAS-A relationships dictate that members and methods are only appended to sub-classes.
Why Did You Even Write This Article?
I am tired of people writing stuff in/about JavaScript and calling it Object Oriented without explaining the difference between true object-oriented languages and scripting languages like JavaScript.
OOP Developers trying to learn JavaScript need to understand the fundamental difference between Java and JavaScript (is-a vs. has-a); just because JavaScript has “Java” in the name doesn’t mean it’s anyway related to Java.



> I am tired of people writing stuff in/about JavaScript and calling it Object Oriented without explaining the difference between true object-oriented languages and scripting languages like JavaScript.
And I’m tired of people believing that OO means only one thing.
Is Smalltalk OO? Of course it is–but most implementations have no concept of private variables, instead relying on convention. There’s also instVarAt: and instVarAt:put: messages.
Is Self OO? Of course it is–it’s also a prototypal-inheritance language.
(And what’s a “scripting language”?)