What’s so funny ’bout pseudo-classical inheritance (in JavaScript)?

February 15, 2010 Davis W. Frank

Our customers are asking for richer interfaces and user experiences. And so we – and by “we” I mean the Rails development community – are writing more and more JavaScript. We’ve gone from ignoring JS (using RJS server-side) to rendering JSON and writing our own jQuery plugins.

But in this transition some of us left our objects & design patterns on the server. Just because you’re writing a click handler in JavaScript doesn’t mean it couldn’t, or shouldn’t, be a method on an object.

If you have a long-lived page, its data are clamoring for object orientation. That data needs to be loaded, reloaded, and paginated via AJAX calls – why build that code (or that interface) more than once?

What about APIs that you’re accessing via AJAX? Wrapping an API in an object means you can more easily mock out the actual service in test and keep all the parameter logic separated from your data models. Or even more exciting, you can reuse your API code on the server (thanks for the timely example, Dion!).

JavaScript already has objects, but how do you organize your code in a more object-oriented way?

I’m a fan of a more Pseudo-classical approach to my JavaScript. (Sorry, Mr. Crockford, but I’m spending nearly all my time in Palm webOS these days and Mojo new‘s my objects). I’m not a fan of Prototype.js’s Class.create$super is awkward, puts too much responsibility on the coder, the errors you get when you forget one are confounding, I don’t need to rename my constructor…the list is a bit longer, but you get the idea.

Instead we use JavaScript prototypes a lot like Ruby’s Classes – objects that implement common “class”-wide behavior. We setup an inheritance graph between child & parent prototypes – much like Google’s Closure. And we explicitly call functions on parent prototypes when we need “super”.

The result is a set of techniques that behaves enough like Classical inheritance for us to be productive. More importantly, we like it and the code we write with it – if there’s demand, I’ll write up an example.

Defining objects for purposes of encapsulation, abstraction and ease of testing (no matter the technique) is not only possible in JavaScript, they (surprise!) offer all the same benefits they do in other languages: less code that’s more robust and that you don’t mind extending & maintaining.

Why else is this important now? THE FUTURE.

Writing HTML5/RIA/MobileWeb applications in JavaScript is different than Rails/MVC web development. In order to make our code manageable we’ll need and want to crib from the object-oriented patterns of desktop client development.

But that’s another post.

About the Author

Biography

More Content by Davis W. Frank
Previous
API Cake
API Cake

A made up conversation with myself: Let's say I have a cool service. Now I want someone to take my cool se...

Next
Second thoughts on initializing modules
Second thoughts on initializing modules

This morning Yehuda Katz posted a response to my previous post, Technique for extending a method from a mod...

Enter curious. Exit smarter.

Learn More