Wednesday, June 17, 2009

Design Patterns in Javascript: Part 1 Template Method

The Template Method pattern is good for time when you have an algorithm that is pretty stable except at a specific point. So if you have a task defined as :

var worker = {
doTask : function() {
return done;
done : false

So here we have our basic worker. All our workers repeatedly do 3 steps until done to complete task. Let’s define three different types of workers.

First let’s we will need to take care of a deficiency with Javascript prototypal inheritance model:

if (typeof (Object.create) !== 'function'){
Object.create = function (oldObject) {
function F() {}
F.prototype = oldObject;
return new F();

OK, on to the worker objects:

var oneTimer = Object.create(worker);
oneTimer.doStep1 = function() {
// Step 1...
oneTimer.doStep2 = function() {
// Step 2...
oneTimer.doStep3 = function() {
// Step 3...
this.done = true;

var twoTimer = Object.create(oneTimer);
twoTimer.times = 2;
twoTimer.doStep3 = function() {
// Step 3...
this.done = this.times === 0;

var tireless = Object.create(oneTimer);
tireless.doStep3 = function() {
// Infinite worker
this.done = false;

Now I can call the doTask of the worker object that I need. So if I, by some strange occurrence, need a tireless worker I’d do this:


Not much to implement this pattern, is there? This is just like a C# or Java implementation where worker would be and abstract class.

Tuesday, June 16, 2009

Design Patterns in Javascript: Introduction

I have a bit of extra time on my hands right now so I decided to do a series on design patterns in Javascipt. I know some of you have probably heard rumors that Javascript is an object oriented language, right? Well, that is true.
Now some folks used to tell you that Javascript is not object-oriented. They'll probably say something like it's object-based. They'll reason that Javascript doesn't have true inheritance, encapsulation, or polymorphism. What these people really were (and some may still be) saying is that JS does not have class-based object oriented programming, natively. But, classes are not the only way to implement OOP. JS, Lua, and Perl implement OOP using prototypes.

Now since JS is an object-oriented language, we should find at least some of the GOF design patterns useful.

In the next post we will look at the Template Method pattern.

Sunday, March 1, 2009

A strange fight, indeed.

It was strange to see the cowboy coders and the artisan coders go at it. For those that don't know SO #38 sparked a discussion that has been brewing for some time now. You know you've seen it around the office. That guy who doesn't get why you'd waste your time on using factory pattern instead of a giant switch block to choose which derived classes you should use. Or the chick who is always waxing poetic about the virtues of the current standards. Well these two side have had at it.

The funny thing is that this whole argument about principles in software design/engineering/development/architecture/whatever you want to call it is because of one word, PRINCIPLE. What is a principle? A principle is a comprehensive and fundamental law, doctrine, or assumption. OK, so a principle is a law of some sort. And that is where a lot of people stop in the definition. But what about the other words in that list of possibilities. A doctrine is something that is taught or a set of strategies. An assumption is a fact or statement (as a proposition, axiom, postulate, or notion) taken for granted. Those other to choices don't seem as finite as a law.

OK that all fine, well, and good, but why was it such a big deal about five documents that are about 13 years old. Well, other than the misspoken and rescinded statement of one particular developers credentials, a lot of developer seem to resent being told that their programming doctrine is wrong. (Oops, there is that word again) But what they fell to realize is they them selves are the ones that assumed that it was being criticized. No where does it say you must follow these "principles". Even the author of the referenced papers does not say that you have to. He believes that if you are able to craft good, clean code by some other standards then by all means do so.

Well, one last thing. The word principle probably shouldn't have been used in naming these tenants. It was the authors artistic license to do so. It would seem he wanted to emphasize the importance of them. However, they are not principle in the commonly known sense of being a law. Rather, they are principles in that they are doctrine for a certain style of programming. If you don't subscribe to that style of programming then don't worry about them.

Robert C. Martin, the aforementioned author, has likened our craft to martial arts. You have different dojos, with different ways and motivations for doing what they do. Even in the same style, there are subtle differences. There are also differences in the way individual practitioners of approach the style. The true martial artist doesn't criticize other styles they except it as different. So I think that programmers, software developers, code monkeys, whomever put finger to key for the purpose of solving problems through logic should be able to accept the differences in coding style.