DI is about pushing object creation and wiring as high up in the application as possible, which gives you one central location for the flow of logic.

Code components have dependencies, whether you’re using Java or Javascript. When your UI widget needs to make a server request to fetch some content, you depend on some code to carry that out. There are usually three approaches.

1. Use a global symbol, such as $.ajax in the world of jQuery.

2. Use a service locator, something like:

function updateCustomer(locator) {
  var server = locator.server();
  server.get("...");
}

Or having the locator being a global variable.

3. Only pass in what you need, like this:

function updateCustomer(server) {
  server.get("...");
}

The first option is the simplest. $.ajax is just a global function that anyone can use. This is also why it’s the most problematic, because if anyone can use it anywhere, you will end up with no idea of which parts of your application is making Ajax calls. You’re basically saying “use any tools you like, I don’t care” to your function.

The second alternative passes in a service locator instead, which is better because you have control over what functionality you expose through your locator. It’s like saying “here’s a bag of tools, you can’t use any other than these, but do what you want with any of these in the bag”.

The third is the most straight forward. It’s like saying “here’s a screwdriver, it’s what you’re gonna use”. Since we’re just exposing the server object, there is no risk that other features using other objects will be added to our function. That is a risk with the other two solutions, since they expose more functionality than needed. Another benefit is that it’s very easy to spot what dependencies your objects have, since they are declared in the constructor. With a locator or with globals, you might have dependencies hidden in large chunks of code that are easy to miss. You are forced to think very hard about how your application is layed out, because it becomes very easy to spot if an object is doing to much, if it requires too many dependencies. You also have to think about how to pass these dependencies around.

Dependency injection is hard

So if the third solution is so great, how come most people use the first two? Simply because it’s hard to achieve. Using a locator is simpler, since you just pack a bag with lots of things and pass it around. But if you use the third option, you have to keep track of who wants the different tools, and make sure that they get them. You also need to make sure that everyone can’t ask for anything.

In other languages, there are frameworks that help you with these things. Automating object creation in a language like Java or C# is somewhat simple, because you have type hints in the constructors. You can inspect a constructor and find out what it wants. But there is no way to do that in Javascript, since it doesn’t have types or type hints. Because of this, making a DI container in Javascript is bound to get messy, because you need to define construction rules for all objects. This is problematic because new objects can’t be added to your application without modifying the wiring code.

A shot at an automated container in Javascript

So we now basically know what we need. A container that is semi-smart and can assemble hierarchies of objects. It needs to be able to create objects by convention instead of configuration.
To achieve this, we have a few options. First off, we can cast a constructor to a string which gives us the whole method body and then parse out the argument variable names and use them to map to objects. This is a brittle and error prone idea, since someone might rename a variable and that might take down the entire application. Another option is to add a sort of type hints. Something like this:

function Server() {
  return {
    get: function(...) {}
  };
}

function updateCustomer(server) {
  server.get("...");
}
updateCustomer.dependencies = ["Server"];

It’s a little unorthodox and perhaps not so Javascripty, but it makes our object more self contained. Our function still isn’t grabbing Server direcly as with a Service Locator, it’s merely saying that it would like to get some implementation that behaves like Server does. But it isn’t very pretty, because the type hints are below the function body, which can be an issue with a more lengthy function. So here’s some syntactic sugar:

var updateCustomer = dependant(
  ["Server"],
  function(server) {
    server.get("...");
  }
);

The dependant function just maps the function together with the type hints, and it also gives you a simple way to check who has which dependencies.

So now it’s just a matter of inspecting the dependencies array of a constructor to be able to map it together. Here’s a proof of concept:

var dependant = function(dependencies, func) {
    func.dependencies = dependencies;
    return func;
}

var Container = function() {
    var namespaces;
    var instances;
    var constructors;

    return {
        _init: function() {
            namespaces = [];
            instances = {};
            constructors = {};

            return this;
        },
        addNamespace: function(namespace) {
            namespaces.push(namespace);
        },
        get: function(klass) {
            if(!instances[klass]) {
                if(constructors[klass]) {
                    instances[klass] = constructors[klass]();
                } else {
                    instances[klass] = this.create(klass);
                };
            };
            return instances[klass];
        },
        create: function(klass) {
            for(var i = 0; i < namespaces.length; i++) {
                if(namespaces[i][klass] && typeof namespaces[i][klass] == "function") {
                    var constr = namespaces[i][klass];
                    if(constr.dependencies) {
                        var args = [];
                        for(var j = 0; j < constr.dependencies.length; j++) {
                            args.push(this.get(constr.dependencies[j]));
                        };
                        return constr.apply(namespaces[i], args);
                    } else if(constr.length == 0) {
                        return constr();
                    };
                };
            };
            throw "Cannot create '"+ klass +"' because there isn't a registered instance or \
                   constructor, and there was no way to auto wire it.";
        },
        registerConstructor: function(klass, creator) {
            constructors[klass] = creator;
        },
        registerInstance: function(klass, instance) {
            instances[klass] = instance;
        }
    }._init();
};

And some usage code:

var ns = {};
ns.Alerter = function() {
    return {
        alert: function() {
            alert("Mjello!");
        }
    }
}

ns.MyObject = dependant(
    ["Alerter"],
    function(alerter) {
        return {
            doStuff: function() {
                alerter.alert("Mjello!");
            }
        }
    }
);

var cn = Container();
cn.addNamespace(ns);

var o = cn.get("MyObject");
o.doStuff();

I haven’t used this type of DI in a Javascript application yet, so I can’t really say if it’s any good, but I get a good vibe from it so I’m planning on using it for a Javascript application that I’m about to create.

An added benefit here is that the dependencies array can contain anything, not just strings with function names. It could contain CSS selectors to let you decouple DOM access, and maybe even remove the tight coupling with a library such as jQuery or YUI. It could also contain an array of method names, something like:

ns.MyObject = dependant(
    [["alert"]],
    function(alerter) {
        return {
            doStuff: function() {
                alerter.alert("Mjello!");
            }
        }
    }
);

This says, “I need one object, and I need it to have an alert method”, which is basically a flirt with a structural type system that is a very good fit for Javascript.

Conclusion

Javascript is a very open language. You can choose to go OO or procedural, and you can even choose which type of OO you want to use, classical, prototypal or parasitic. It’s only natural then that there are also a number of different ways to manage dependencies in an application. So when you start a new project in Javascript, you have a smörgåsbord of ways to write code. There’s no wrong or right, there’s only what is appropriate for your application. But when you’ve decided which way to go, stick with it.

By using parasitic inheritance, you can avoid using the new operator all together. The new operator isn’t evil, but it’s problematic in that if you write a function and you expect it to be called with the new operator but someone forgets it, wild thing can happen, and it can be really hard to debug. Let’s take an example:

function greet() {
  alert("Welcome, everyone!");
}
function Greeter(name) {
  this.name = name;
}
Greeter.prototype.greet = function() {
  alert("Welcome " + this.name);
}
function Person(name) {
  this.name = name;
  this.greet();
  return this;
}
Person.prototype = new Greeter();
Person.prototype.toString = function() {
  return "I am " + this.name;
}

// Example 1
var name = "Andy";
var person = new Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

// Example 2
var name = "Andy";
var person = Person("Coffeescripter"); // alerts "Welcome Andy"
alert(name); // alerts "Coffeescripter"

This way of writing a class and saying that Person inherits from Greeter is rather ugly, so check out John Resigs implementation for some eye candy: http://ejohn.org/blog/simple-javascript-inheritance/

If you’re not familiar with how this works in Javascript, this may blow your mind. But it’s perfectly valid code, it’s just that the this variable points to different places depending on whether you used the new operator or not. When the new operator is used, this points to the new instance that was created. When you’re not using the new operator, this points to the object that the function was executed in, which in this case was the window object, and that is why this.name = name is overriding the value of the global variable name. This because var name = "Andy"; here is technically the same as window.name = "Andy";.

You can’t tell from inside the function if the new operator was used or not, so you can’t throw an exception if the new operator was omitted. You could just say that “all functions that begin with a capital letter should be called with the new operator, or else you’re stupid” and be done with it. And while that might be true, you’re still going to be the one debugging for an hour or so when the new guy who doesn’t know Javascript that well forgets about the new operator.

Parasitic Inheritance

So how about that parasitic inheritance then? It works like this instead:

var Greeter = function(name) {
  return {
    greet: function() {
      alert("Welcome " + name);
    }
  };
};
function Person(name) {
  var obj = Greeter(name);
  obj.greet();
  obj.toString = function() {
    return "I am " + name;
  }
  return obj;
}

// Example 1
var name = "Andy";
var person = new Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

// Example 2
var name = "Andy";
var person = Person("Coffeescripter"); // alerts "Welcome Coffeescripter"
alert(name); // alerts "Andy"

The behaviour is the same if you call Person with the new operator or not. And because of that, it simpler just to forget about the new operator. To me, this code is more straight forward and less magical than the first example, which is always a good thing. One issue people is having with this approach is that for every Person you create, you also create new versions of the greet and toString functions. With the first example, all Person objects share the exact same greet function. That of course means less memory usage, but it also introduces a somewhat scary thought. If all Person objects share the same greet function, what happens when someone decide to replace a persons greet function, it doesn’t just affect that object, it affects all person objects.

This trouble with parasitic inheritance

Something I kept running into with parasitic inheritance was how I didn’t have access to the created object in the beginning of the function, like this:

function Person() {
  var bazooka = Bazooka(this);
  return {
    shoot: function() {
      bazooka.shoot();
    }
  };
}

var Bazooka = function(parent) {
  return {
    shoot: function() {

    }
  }
}

Disregarding that we have a cyclic reference here between Person and Bazooka, the problem is that this in var bazooka = Bazooka(this); isn’t pointing to the person object that we are creating, but the object that the Person function is running in; the window object. So how do we get around this? We could do something like:

function Person() {
  var obj = {
    shoot: function() {
      bazooka.shoot();
    }
  };
  var bazooka = Bazooka(obj);
  return obj;
}

But that’s about as pretty and clear as VB’s let’s-use-a-variable-with-the-same-name-as-the-function-as-the-return-mechanism-because-function-names-never-change-and-nobody-will-forget-to-update-all-references-to-the-return-variable-when-the-function-is-renamed. So yeah, we can do better. Something like this:

function Person() {
  var bazooka;
  return {
    _init: function() {
      bazooka = Bazooka(this);
      return this;
    },
    shoot: function() {
      bazooka.shoot();
    }
  }._init();
}

It looks a lot better, and if you’re used to classical inheritance, you’re probably used to looking for property declarations at the top, a constructor right after that, and methods down below. If you’re the suspicious type, you might have noticed that by doing this, we are exposing the _init function to be called again. Which is true, there is nothing stopping you from doing: var p = Person(); p._init(); But if this means the end of the world for you, you can always add this._init = undefined; as the first line in the _init function, which makes it impossible to call it twice.

Privileged functions

In the first example, there is no way to have a private function that all your public functions can call, not even with John Resigs prettier version. But with parasitic inheritance, it’s very natural to hide variables and functions through closures, like this:

function Person(name) {
  var bazooka;
  var greet = function() {
    alert("Hi! I'm " + name);
  };
  return {
    _init: function() {
      bazooka = Bazooka(this);
      if(name == "Andy") {
        greet();
      }
      return this;
    },
    shoot: function() {
      if(name != "Andy") {
        bazooka.shoot(name);
      }
    }
  }._init();
}

Through the closure that the function call to Person creates, both shoot and _init has access to greet, bazooka and name.

Conclusion

The key difference between classical and parasitic inheritance is that the classical way is much more focused on an objects type. Change one object, and all other objects of that same type get’s changes. Parasitic inheritance doesn’t care about types. It’s more about assembling functions and properties to create a logical unit. Instead of caring if an argument to your function is of the type Person, you only care about whether or not it has the function greet. There is no right or wrong here, and the two can happily co-exists, but the thing that makes me use parasitic inheritance is how it’s aligned with the dynamic nature of Javascript.

So let’s say you have code like this:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name) {
    this._name = name;
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

var fred = new User('Fred');
var mike = new User('Mike');
var jennifer = new User('Jennifer');
var sara = new User('Sara');

fred.addFriend(jennifer.name());
fred.addFriend(sara.name());

mike.greetFriends();

You would expect that Mike who nobody seems to like would just alert “Hi !”, but he alerts Freds friends as well. And that’s because objects in Javascript (arrays are objects as well) are passed by reference. So all of Freds friends also become Mikes friends, since they share the same friend array.

So to get away from this, the trick is to declare your properties in the constructor, like this:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name) {
    this._name = name;
    this._friends = [];
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

Since the constructor (init) is called every time a new user object is created, the friends array is set for only that instance. But sometimes you might forget to reset the variable in the constructor, so I usually do this:

var User = Class.extend({
  _friends: false,
  _name: '',
  init: function(name) {
    this._name = name;
    this._friends = [];
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

Just to make sure that there’s no risk of a shared array. You might even skip the declaration at the top, but I’m used to looking there for property declarations, so I set them at the top.

I’m sure that you already thought about this by know, but this feature in Javascript makes it possible to have “static” properties that are shared between all instances of the same class. I would advise you to use such a strategy sparsely though, as it’s not very obvious that it’s a shared variable. But the good thing about it is that this Javascript version of static properties doesn’t suffer the same problems that statics do in Java/PHP, since the static can be turned into a local just by resetting it in the constructor, without it affecting other objects. Something like:

var User = Class.extend({
  _friends: [],
  _name: '',
  init: function(name, share_friends) {
    this._name = name;
    if(!share_friends) {
      this._friends = [];
    }
  },
  name: function() {
    return this._name;
  },
  addFriend: function(friend) {
    this._friends.push(friend);
  },
  greetFriends: function() {
    alert('Hi '+ this._friends.join(', ') +'!');
  }
});

var fred = new User('Fred', true);
var mike = new User('Mike', false);
var jennifer = new User('Jennifer', true);
var sara = new User('Sara', true);

fred.addFriend(jennifer.name());
fred.addFriend(sara.name());
mike.addFriend(fred.name());

mike.greetFriends();
sara.greetFriends();

This code now tells us that Mike only has Fred as a friend, whereas Sara shares friends with Fred, and has both herself and Jennifer as her friends.

Happy coding!

I decided from the start that I wanted to use jQuery, and Object Oriented Javascript. To mimic OO inheritance, I once again used John Resigs Simple Javascript Inheritance.

So the first thing to do was to model the entities I needed in the game. I started out with the obvious one, the Unit class. Added a few methods to it, and moved on to the Map class, because I wanted to get something at least partially working very fast. So I made a Map class that generated a map of tiles that could hold units. I greated a Tile class, and the Map class would hold all instances to the tiles. A tile has a “height” property, which defines the altitude of it (1 is deep water, 6 is low land, and 10 is oh-my-god-that’s-high-mountains). For now, I’m just randomizing the heights of the generated tiles, but that doesn’t make a very realistic map, so that’s on my TODO-list.

To get something working, I needed a way to connect unit to tiles. At first, I thought about letting the Unit hold an instance to the Tile it was on, but soon realized that it wouldn’t be a good idea. Instead, I created a UnitLocations class, which holds all units and all tiles, and connects them.

I also needed to be sure that units can’t move over the map as they like, land units can move over water (except the JesusUnit, which will be covered in part 23 of this series). So I created a LandUnit, and a WaterUnit, derived from the Unit base class. For now, when you try to move a unit, the game.Tile::canTake(game.Unit unit) method is queried to see if the unit can be moved to that tile. I’m pretty sure I have to move that logic to somewhere else at a later stage, but it’s good enough for now.

So I had a map, and I had a couple of units on it, that could move around. Then I remembered that Civilization is turn based. And my ambition is to let players play against each other over the series of tubes that we call the Internets. But sitting and waiting for other players to make their move can be tiring at best, so I needed another solution. Instead, i decided that Units has a “move_points”. Let’s say that LandUnit has 3 move_points, and moves over three tiles. Then move_points becomes zero, and that unit has to rest for a couple of seconds before it can move again. Right now, it’s accomplished by an interval running in every unit that adds move_points every two seconds. Each unit type also has a “max_move_points” property, so you wouldn’t be able to move the unit over a gazillion tiles if you waited long enough.

So I was quite excited about this, and wanted to move on and make more features. But then I stopped and thought some more about it, and realized that I need an event architecture to move on. And I hear you, Javascript already has events, and jQuery allows you to trigger custom events that you define on your own, but I wasn’t quite satisfied with how that worked. So I’m going to get cracking on a way to define and trigger my own events, and that will be part 2 of this series.

You can find the game here for now: http://dev.online.nu/game/.
When you want to move a unit (a unit is one of those pretty red squares), just click on it, then move it by using your keyboard arrows.

Til then, happy coding!

I’m using John Resigs Simple Javascript Inheritance to emulate class inheritance in Javascript, so you might want to check that out.

So the first step is to create a base class that takes care of the getters and setters for us.

var DomainObject = Class.extend({
  init: function() {
    /**
     * Generating getters and setters for the domain object by looping over
     * all properties that start with _ and automatically creating getters/setters
     * If the property is "_first_name", the getter will become "firstName()", and
     * the setter will become "setFirstName()"
     */
    for(var key in this) {
      createGettersAndSetters(key, this);
    }
    function camelize(str) {
      var ret = '';
      for(var i = 0; i < str.length; i++) {
        var chr = str.charAt(i);
        if(chr != '_') {
          ret += chr;
        } else {
          i++;
          ret += str.charAt(i).toUpperCase();
        }
      }
      return ret;
    }
    function createGettersAndSetters(key, context) {
      if(key.indexOf('_') === 0 && typeof context[key] != 'function') {
        var set_method = 'set'+ camelize(key);
        // Make sure we don't override an existing setter
        if(!context[set_method]) {
          context[set_method] = function(value) {
            context[key] = value;
          }
        }
        // Using substr to remove the starting _, since we don't want the
        // string to start with a capital letter, as we do with the setters
        var get_method = camelize(key.substr(1));
        // Make sure we don't override an existing getter
        if(!context[get_method]) {
          context[get_method] = function() {
            return context[key];
          }
        }
      }
    }
  }
});

So now that we’ve got our class that handles the magic, we need to test it!

var User = DomainObject.extend({
  _id: false,
  _name: '',
  setId: function(id) {
    if(validUserId(id) {
      this._id = id;
    }
  },
  sayHello: function() {
    alert('Hi! My name is '+ this.name());
  }
});

var usr = new User();
usr.setName('Anders');
// Will alert "Hi! My name is Anders"
usr.sayHello();

So what is does is that it takes all properties of the “class” that begins with an underscore, and generates getters and setters for them, if a getter/setter isn’t already defined. The format for the methods are setProperty() and property(), so if you have a property called “_first_name”, the setter becomes “setFirstName”, and the getter becomes “firstName”.

Happy coding!