JavaScript OOP: encapsulation, durable objects, parasitic inheritance and the decorator pattern

I've been working to eliminate this and its associated complexity from my JavaScript vocabulary. I haven't written an articulate blog post about the difficulties this causes but there are many and perhaps I will write that article some day. I've gone on and off with my quest over time and made another push this past week to rid my life of this. I think that after just over two years of experimenting and blogging about JavaScript OOP, I may have finally seen the light.

In my search for the great OOP solution, I was really looking for something that allowed for proper encapsulation and structured code reuse without any hint of type declarations. I wasn't necessary searching for a message passing OOP system or to simulate class. I was searching for whatever it is that JavaScript does most naturally. JavaScript's prototypal inheritance system is interesting and more flexible than classical inheritance schemes; however, even the prototypal system is difficult going most of the time. I imagine all JavaScript programmers have struggled to make the prototypal system work for them. The prize waiting for me was, of seems to be usual, rooted in the wonders of closures (a.k.a lambdas or just function in JavaScript).

Douglas Crockford has written about durable objects and parasitic inheritance which concern encapsulation and code reuse, respectively. Along my exploratory path I had read his articles and watched his talks on the web about these and other topics. I knew they were all good concepts for one thing or another but I didn't see how the durable object and parasitic inheritance concepts in particular comprised most of the solution I sought. I pursed various OOP styles. When I arrived at what feels like the end of my search, I realized I had essentially combined these two concepts which Douglas has evangelized.

I now also see that parasitic inheritance is really The Decorator Pattern in disguise. The decorator pattern gives the benefits of code reuse supplied by extends-type inheritance without the drawbacks of the template pattern also supplied by extends-type inheritance. Adding the decorator pattern explicitly into the mix with durable objects and parasitic inheritance is a powerful and natural fit.

Below is a small code snip which shows the essential concepts. I modified an example from the decorator pattern chapter of Head First Design Patterns by Freeman, Freeman, Sierra and Bates (which, by the way, is a great book and more accessible than the more in depth and classic Gang of Four Design Patterns by Gamma, Helm, Johnson and Vlisides.) The Head First book has its examples in Java which is a class-based language. Most books on design patterns use class-based languages which makes it more difficult to find the natural way to write JavaScript programs. Where are all the books on design patterns for closure-based languages? Ok, on to the example...

// makes base item
var makeHouseBlend = function() {
  return {
    toString: function() {
      return 'House Blend';
    },
    toDollars: function() {
      return 0.89;
    }
  };
};

// makes different base item
var makeEspresso = function() {
  return {
    toString: function() {
      return 'Espresso';
    },
    toDollars: function() {
      return 1.99;
    }
  };
};

// Decorate (actually modifies by wrapping certain properties)
// a base item or a base item that has already been decorated.
// Cream costs extra.
var decorateWithMilk = function(beverage) {
  var originalToString = beverage.toString;
  beverage.toString = function() {
    return originalToString() + ', Milk';
  };
  var originalToDollars = beverage.toDollars;
  beverage.toDollars = function() {
    return originalToDollars() + 0.20;
  };
  return beverage;
};

// Decorate a beverage with a different condiment.
// Sugar is free.
var decorateWithSugar = function(beverage) {
  var originalToString = beverage.toString;
  beverage.toString = function() {
    return originalToString() + ', Sugar';
  };
  return beverage;
};

// Watch the changes as my coffee is made in stages.
// House blend with milk and sugar
var myCoffee = makeHouseBlend();
myCoffee.toString(); // 'House Blend'
myCoffee.toDollars(); // 0.89
myCoffee = decorateWithMilk(myCoffee);
myCoffee.toString(); // 'House Blend, Milk'
myCoffee.toDollars(); // 1.09
myCoffee = decorateWithSugar(myCoffee);
myCoffee.toString(); // 'House Blend, Milk, Sugar'
myCoffee.toDollars(); // 1.09
    
// double milk espresso
var yourCoffee = 
      decorateWithMilk(decorateWithMilk(makeEspresso()));
yourCoffee.toString(); // 'Espresso, Milk, Milk'
yourCoffee.toDollars(); // 2.39

Suppose a house blend coffee with milk and sugar is a very common order. writing decorateWithSugar(decorateWithMilk(makeHouseBlend())) or pressing three buttons on the cash register for each order is a bit tedious. It may be worth our while to write a special maker function for this particularly common drink and map it to a key on the cash register.

var makeSugarMilkHouseBlend = function() {
  decorateWithSugar(decorateWithMilk(makeHouseBlend()));
};

var myCoffee = makeSugarMilkHouseBlend();
myCoffee.toString(); // 'House Blend, Milk, Sugar'
myCoffee.toDollars(); // 1.09

The above maker function does the same job that one of Douglas' parasitic inheritance maker functions does. I haven't seen an example before of parasitic inheritance where its decorator pattern nature has been explicitly extracted. The examples I have seen would have the decorating happening directly in the makeSugarMilkHouseBlend function which reduces the reusability of the decorating logic. The decorator pattern used this way also hints towards Ruby's mixin. It also displays the characteristics of the bottom-up style of programming.

I'm working on an article which shows how all of these concepts fit together in a browser scripting environment with the whole works from XMLHttpRequest up through DOM manipulation. If I was writing a book on browser scripting, the article would be the last chapter: the chapter which uses all the concepts from all the previous chapters to write a full client-side application with some sort of MVC-equivalent architecture. My JavaScript Widgets without this article is peak at some of the view-related concepts.

This seems like a very comfortable JavaScript OOP solution that will work well for the majority of browser scripting task. I certainly feel like the major struggle is behind me and I am now at peace with JavaScript OOP.