Object-oriented JavaScript
by Greg Brown
|
Pages: 1, 2, 3
Polymorphism
Polymorphism refers to the ability of a caller to invoke a particular method or set of methods on an object without regard to the object's type. For example, we might want to add a speak() method to our Pet class, to allow our Pets to answer the phone when we are not at home; the caller on the other end of the line will not necessarily know or care which Pet is answering the phone, as long as it is able to speak():
In C#:
// C# Pet class
public class Pet
{
// ...
public virtual void Speak()
{
System.Console.WriteLine(GetName() + " says...");
}
}
// C# Dog class
public class Dog : Pet
{
// ...
public override void Speak()
{
base.Speak();
System.Console.WriteLine("woof");
}
}
// C# Cat class
public class Cat : Pet
{
// ...
public override void Speak()
{
base.Speak();
System.Console.WriteLine("meow");
}
}
In JavaScript:
// JavaScript Pet class
// ...
Pet.prototype.speak = function() {
alert(this.getName() + " says...");
}
// JavaScript Dog class
// ...
Dog.prototype.speak = function() {
Pet.prototype.speak.call(this);
alert("woof");
}
// JavaScript Cat class
// ...
Cat.prototype.speak = function() {
Pet.prototype.speak.call(this);
alert("meow");
}
Note that the same call() function used to invoke the base class constructor functions is also used to invoke method on the base class:
Pet.prototype.speak.call(this);
In this case, however, the target function name is the fully qualified name of the base class method, Pet.prototype.speak.
Invoking the methods is the same as before:
C#:
p = new Dog("Max");
p.Speak();
p = new Cat("Fluffy");
p.Speak();
JavaScript:
p = new Dog("Max");
p.speak();
p = new Cat("Fluffy");
p.speak();
The output of this program should be the following (see Figures 3-6):

Figure 3. Output is "Max says..."

Figure 4. Output is "woof"

Figure 5. Output is "Fluffy says..."

Figure 6. Output is "meow"
Although it may not offer features as powerful as C# or Java, JavaScript is more capable than many web developers may know, and it can be used to provide the structure of object-oriented development to the growing number of AJAX applications currently being deployed on the web.
Share your experience in our forums.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- Great help
2009-11-08 21:59:50 Abhijit Roychoudhury [Reply]
Thanks Greg. It's been a great help to get a quick knowledge on classes in JavaScript. The comparative explanation with C# has made it extremely easy to understand for those who are familiar with OOPs. Now I can have a look at Crockford without any confusion.
- Good and basic article
2008-05-30 10:46:26 Atul Jindal [Reply]
Good and basic article.
This article provides basic information to developers who are in familiar with object oriented programming in javascript
- Douglas Crockford would disagree
2006-06-08 06:27:20 joshua.gitlin@gmail.com [Reply]
Check out http://javascript.crockford.com
He explains classic inheritance, protoypical inheritance, multiple inheritance, closures, public/private/priveleged member visibility and more.
- Nice articles, but a major imprecision
2006-06-08 00:17:16 andrea.campi [Reply]
I like the comparative approach with C#, as it helps ensure more and more people can appreciate the support JavaScript provides for writing good code.
But when the author suggests that "JavaScript does not support any concept of method or property visibility: every property and method is always public", well... he's completely wrong.
Sure, it may not have some nice built-in way to do that (although you could argue prototype isn't nice either), but there is plenty of experience in data hiding in JavaScript, both at instance and class level (static variables and functions).
For reference, you can have a look at http://www.crockford.com/javascript/private.html, but there is much more around. You may also want to look at a post on my blog where I compare several different approaches, and I also provide links to more people who have solved this problem: http://www.webcom.it/blog/articles/2006/05/24/private-static-members-in-javascript
Andrea
- Nice articles, but a major imprecision
2006-06-08 06:47:49 Greg.Brown [Reply]
Using closures in the constructor function to create "private" methods and member variables is an interesting technique that I hadn't considered. As noted in the Crockford article, closures are not especially well documented or well understood, which can lead to confusing or buggy code. Closures can also cause memory leaks if not used properly (see http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp). Nonetheless, it is a potentially powerful and useful option if used properly.
Greg
- Nice articles, but a major imprecision
2006-06-08 07:23:35 jdodds [Reply]
Using closures for information hiding in a JavaScript object that uses only JavaScript native objects doesn't pose a memory leak risk. Memory leaks are not inherent in using closures.
The IE memory leaks have three pre-conditions:
1.) IE,
2.) a circular reference (which may be created by a closure),
3.) a host object implemented as a COM object.
It's not closures that are the problem but the way that COM based host objects are garbage collected by IE.
I recently wrote about closures on my blog:
http://jrdodds.blogs.com/blog/2006/05/javascript_clos.html
- Nice articles, but a major imprecision
2006-06-08 07:40:35 Greg.Brown [Reply]
All true. Which is why I said they "can" cause memory leaks "if not used properly". :-)
I suppose it would have been more accurate to say that they "can cause memory leaks in IE if not used properly". I just didn't want to get into the details in my reply, which is why I included the MSDN reference.
Greg
- Nice articles, but a major imprecision
- Nice articles, but a major imprecision
- Nice articles, but a major imprecision
