Tuesday, December 16th, 2008

Interfaces in JavaScript

Category: Java, JavaScript

The UML diagram above is from Matt Prokes as he creates Java-like interfaces for JavaScript.

He has a full example:

An example of an object which requires an implementation of the interface.


  1. //This code is valid, and the execution will be successful.
  2. function executeInterface1(executeThis){
  3.   var castedIface = executeThis.cast('TestInterface');
  4.   castedIface.testMethod1(1,2,3);
  5. }
  7. //This code is valid, but the execution will not be successful.
  8. function executeInterface2(executeThis){
  9.   var castedIface = executeThis.cast('TestInterface');
  10.   castedIface.testMethod2(4,5,6);
  11. }

Alright, lets instanciate, the objects and set them to variables. Feel free to type in the variables and take a look, on the firebug window!


  1. InitedTestObject = new TestObject();
  2. //variable not used in this example, but I thought I would still make it available!
  3. CastedTestInterface = InitedTestObject.cast('TestInterface');

Ok, so lets try it out! We wrap it all up in some simple div tags with onclick events.

  1. onclick="executeInterface1(InitedTestObject)"
  2. onclick="executeInterface2(InitedTestObject)"

Posted by Dion Almaer at 12:51 pm

1.9 rating from 23 votes


Comments feed TrackBack URI

i don`t want to be rude,but why anyone need this?
and also the cast function is quite useless since in Javascript there is no need to cast,is it used for some kind of validation?

Comment by Urielka — December 16, 2008

There is a need for this, you can create systems which validate against the javascript classes being supplied into your system. This is also a better method for creating interfaces than the one outlined in pro javascript design patterns.

Comment by mattprokes — December 16, 2008

Maybe some people are using the wrong tool for their job.
All I want to tell these people is:

Please don’t bloat JavaScript as you did with PHP, please.

Comment by Amenthes — December 16, 2008

Agreed, yet this is a needed component which js doesn’t have yet.. Interfaces would be essential for things like validating mashed content which you want to have plugged into a system. API’s like YUI, and prototype would benefit greatly if they had a decent interface pattern which they could allow them enforce conformity. If you like the ability to mash, and extend content, you should really take interfaces into consideration, this is also a much more lightweight version of a sort-of js inheritance. Please read the document, and understand what it does before you throw the concept out the window.

Comment by mattprokes — December 16, 2008

I would agree that this isn’t the greatest idea. M$ has done the same thing with their AjaxToolkit – that is try to enforce the C# coding paradigm on JavaScript development. In theory it sounds great – C# developers can transition to JavaScript without changing gears. Except for 1) it creates code bloat that can’t be optimized out by a compiler and 2) it perpetuates the idea that server side and client side programming should be approached in a similar manner. This is not always a good idea as evidenced by the C# programmers who create JS code with 30 character variable names – doesn’t cost anything serverside, but it’s big JS no-no. And yeah sometimes it can be compressed down, but that assumes no other coding issues preventing that type of aggressive compression.

Comment by TimR — December 16, 2008

@mattprokes – I wouldn’t say this is a terrible idea, but not necessarily for a production environment. The book you mention, Pro JS Design Patterns, leans towards interfaces as a development tool which can be removed once you know your classes all work as they should. Having this as part of your external API to validate mashup content is probably going over the top.

Comment by kissmyawesome — December 17, 2008

@Tim: we do have interfaces but it’s actually in Microsot Ajax: the toolkit just happens to be built using Microsoft Ajax. But back to the subject at hand.
It’s been often argued that interfaces were not that useful in JavaScript because duck-typing does the trick in most cases. While this is often true, our experience and the experience of several teams at Microsoft building large properties in JavaScript is that interfaces provide something more robust that is often worth the investment. It really depends on the context, the size of the project, its requirements to integrate with unknown entities, the need to manage ambiguity, the level of acceptable risk and many other things.

Comment by BertrandLeRoy — December 18, 2008

@kissmyawesome: you make an excellent point. For example, our version of interfaces are basically a no-op in release mode. They are only applied and checked in debug mode.

Comment by BertrandLeRoy — December 18, 2008

The same could be applied to the pattern here as well, and something to keep in mind that this method of interface is fairly low resource wise, all you are really getting when you cast is an object that has closure access to the one it was casted from. Thus it really is just an empty object with a limited scope of the parent.. This is also an excellent way of doing latent-data-hiding, without the on-load method described in other books. The Nice thing about this method of an interface is you could create a utility class, and then cast several different utilities from it, and essentially get back a custom object meant just for that utility.

This would make coding more clear, and more easy to understand how to use an api. Finally for validation, you can write a library that requires a casted object to work. I don’t outline that in the tutorial, but it is common with many languages that use templated, or interfaced code. Lastly, the cast method is simply a convenience to get back the duck typed closure associated with that object. Its not a actual cast.

Comment by mattprokes — December 18, 2008

Leave a comment

You must be logged in to post a comment.