The Node.js Concurrency Paradigm: Asynchronous I/O

Node.js relies on asynchronous Input and Output (I/O) in order to increase the computing efficiency and speed of an application. This article will take a basic look at what asynchronous programming actually means, and why asynchronous I/O is important in a language like Node.js.


For Node.js performance to be actualized, a certain programming paradigm must be followed. Node.js is an event-driven architecture, and relies on asynchronous (non-blocking) input/output calls, along with the Node.js event loop to gain performance. This means that calls made in Node.js to the file system, event loop, or any resource, must be done asynchronously.


Asynchronous programming, informally, means code that is not waiting for a call to return. This is done using callbacks and registering them with an event-listener.


Let’s take a look at the difference between a simple asynchronous (non-blocking) call versus a synchronous (blocking) call.


Simple Synchronous Example:


// synchronous (blocking)
var request = prepareData();

// twiddle thumbs waiting for response
// from remote web service
var response = getRemoteData(request);

// display results
console.log(response);


First, notice the getRemoteData(request) call. If we’re on the client-side, and we make a synchronous call, the user’s browser is in a waiting state and frozen until the call is completed. The rest of the code cannot be executed until this call has returned.


If we’re on the server-side, and in Node.js we have an incoming request added to the event loop, but this request is a synchronous call, then we have a problem. If this synchronous call is to read or write to the file system, when executed, the entire event queue will be blocked and in a waiting state. No other calls in the event queue can be performed, because the server is halted and waiting for the blocking call to finish.

The speed and through-put of our application ultimately depends on how fast each synchronous call is completed. Since Node.js is single threaded the entire application will be blocked and waiting, which is obviously very bad.


Now let’s take a look at the same simple calls, but this time performed asynchronously.


Simple Asynchronous Example:


// Asynchronous (non-blocking)
var request = prepareData();

// call getRemoteData and continue to 
// execute next line of code
getRemoteData(request, function(response){ // pass a callback
  // display results when done
  console.log(response);
};


We begin here again by passing the request to getRemoteData(request, callback), but we also pass a callback as the second parameter. Remember we can do this because JavaScript supports functions as “first class citizens”.

Our inline anonymous callback function will fire, and the response will be passed as a dynamic argument when getRemoteData() returns.

What is important is our code continues to execute the line after getRemoteData() immediately. It does not wait for the call response to return. This is referred to as an asynchronous (non-blocking) call.


Programming in a purely asynchronous fashion is what makes Node.js so powerful.


Now, it is true that many mainstream languages support concurrency. And it is also true, that they also have asynchronous I/O support. However, the problem is that the majority of these languages have only concurrency and asynchronous “features”. In most languages, concurrency support was added long after the language’s release.


Node.js nearly only supports asynchronous programming and was developed purely with the asynchronous paradigm as a fore-front of its design.


And that’s it!
Happy asynch coding and JavaScript all the things!
😀

The Responsibility of the Node.js Event Loop

Everyone always talks about the Node.js event loop and how its important, but what exactly is it responsible for?

Well… Let’s take a look! 😀

The event loop (event queue) in Node.js is a loop that is responsible for processesing incoming requests. This loop “contains” a queue of requests, and each request in the event loop is a callback.


Node.js Event Loop

The Node.js Event Loop

Since the Node.js event loop contains a queue, it processes the requests like a traditional queue First-In-First-Out (FIFO) fashion. Node.js will continue processing each callback in the event loop until there are no more callbacks left to process.


In order to do this, Node.js registers with the Operating System. When an request arrives, Node.js is alerted, and the event loop processes the request. Any other subsequent connections that are made are queued until Node.js has finished with the current request.


The event loop allows Node.js to scale efficiently by accepting (queueing) many requests at once. Efficient scaling is one of the benefits that Node.js (with the event loop) has over traditional web servers. The event loop is single-threaded. This allows Node.js (when used properly) to require far less computational resources than traditional web servers.

Traditional web servers like Apache or Nginx are multi-threaded. Multi-threaded web servers typically cannot scale to the magnitude that Node.js can without greatly increasing the system’s computing resources. Since multi-threaded web servers create a new thread for each incoming request, this increases both CPU and RAM requirements of the system for the same amount of traffic. This increase can be either positive or negative (depending on your application), but the amount of computing resources for multi-threaded web servers will be greater than the requirement for single-threaded ones.


And that’s it on the Node.js event loop for now!

Happy coding! 😀

Review of JavaScript Invocation Patterns

JavaScript Invocation patterns can be tricky for developers new to the language. This tutorial will take a look and review the four different invocation patterns that JavaScript offers, and the behavior that is expected when using them.

A function invocation in JavaScript refers to passing control and parameters to another function during execution. This may not seem very interesting at first, but the functional ability that the developer can gain can be powerful.

If you have programmed in other languages, especially in many of the popular Object Oriented languages that contain the this parameter, you will quickly find that in JavaScript, the context execution of a function can change the functionality of a function in ways that are typically not expected.

Let’s dive into this in detail. Each function in JavaScript contains two implicit parameters, the this parameter that you use to call object properties with, and another parameter called the arguments parameter.

Along with these two implicit parameters, JavaScript also contains four different invocation patterns.


Let’s take a look.


The Four JavaScript Invocation Patterns:

  1. Constructor Invocation
  2. Function Invocation
  3. Method Invocation
  4. Apply Invocation


**Note: Each invocation pattern in JavaScript changes the initialization context of the this parameter.


Let’s take a look at how each pattern works.


The Constructor Invocation Pattern


Again, JavaScript is classless, prototypal inheritance language, but some of the syntax JavaScript uses camouflages its true nature. Some of JavaScript’s syntax makes the language appear to have classical inheritance, but it doesn’t.

When a function object in JavaScript is invoked with the new keyword, then that object is created with a “hidden link” to that function’s prototype member, and the this parameter will be bound to that new object.


Let’s take a look at an example.


Constructor Invocation Example:


// create a constructor function
// called HelloName
var HelloName = function(name) {
  this.say = name
};
// Give all instances of HelloName
// a public method called getSay
HelloName.prototype.getSay = function() {
  return this.say;
};
// create an instance of HelloName
var helloNameObj = new HelloName("Daryl");
// hello Daryl
console.log('hello' + helloNameObj.getSay());

When functions in JavaScript are created with the new keyword, they are called constructors. We add functionality to constructor functions by adding properties to the functions prototype.


**Note: By convention, the first letter of a constructor function is always capitalized.


Constructor functions in JavaScript can be very useful; however, using the “constructor style” method for creating functions is not recommended. JavaScript contains a better method built into the language, that accomplishes the same behavior. This method is to use Object.create, and we will look at why this is a better option later in another tutorial.


The Function Invocation Pattern


A function is not a property of an object when the function is invoked using the Function Invocation Pattern. If the function is invoked with this pattern, the this parameter becomes bound to the global object, and this can become a problem.


**Note: This was considered a design flaw when the language was developed, because binding to the global object is bad. We won’t go into complete detail of why it is bad in this tutorial, but we will look at a commonly used example of why. There are a lot of reasons, so just trust me (or Google it), binding globally is a nightmare waiting to happen.. 😛


OK, let’s first take a look at the Function Invocation Pattern, and then since binding to the global object is bad, we’ll take a look at how a standardized work around is implemented when a function is invoked inside a method.

Function Invocation Example:


// invoked as a function
var addTogether = add(1, 2); // 3
// using our helloNameObj object
// modify helloNameObj to contain a
// moneyMakerAlgorithm method
var helloNameObj.moneyMakerAlgorithm = function() { 
  var that = this; // work around
  var extraMathProcessing = function() {
    // "that" holds the correct "this" value now
    that.value = add(that.value, that.value);
  }
  // invoke as a function
  extraMathProcessing(); // "this" is now bound to global object
}
// invoke moneyMakerAlgorithm as a method
helloNameObj.moneyMakerAlgorithm();
// output result of value
console.log(helloNameObj.value);


The Method Invocation Pattern


As mentioned, when a function is stored as a property of an object, that property is called a method. When a method is invoked, the this parameter is bound to that method, and that method is a function object.


Let’s take a look at an example.


Method Invocation Example:


// create an object literal with 
// a method. The input param is
// optional, but there should be
// validation checking for if input
// is actually of data type number
var helloNameObj = { 
  value: 1,
  increase: function(num){
    this.value += num;
  }
};
helloNameObj.increase(1); // value = 2
helloNameObj.increase(3); // value = 5


The Apply Invocation Pattern


Since JavaScript supports a functional programming paradigm, then functions can be “first-class citizens”, and since functions are objects, then functions can contain other functions, called methods.

The implications of these features are that JavaScript contains an “Apply Invocation pattern”. This pattern, enables the creation of an array of arguments that can be invoked on a function directly. When doing this, we can apply the context of the this parameter to the context of our choosing.


Let’s take a look at some examples.


Apply Invocation Example:


// apply takes two parameters
// first - is the this parameter
// second - is the array of arguments
// to apply on the function
var helloNameArr = [2, 3];
var addTogether = add.apply(null, helloNameArr); // 5

Apply Invocation Example:


// create an object literal with a 
// say property like in the constructor
// invocation pattern
var helloNameObj {
  say: 'hello Daryl'
};
// Unlike above in the constructor
// invocation pattern, helloNameObj
// does not inherit from 
// HelloName.prototype, so
// we do not have a getSay method
// on helloNameObj, but we can
// invoke getSay on helloNameObj
// by using the apply keyword again
var say = HelloName.prototype.getSay.apply(helloNameObj);
// hello Daryl



Now that we went through all the invocation patterns, let’s take a look at an interesting array parameter that JavaScript makes available.


JavaScript Arguments Parameter



JavaScript contains an array parameter, that is implicitly available to functions when they are invoked. The arguments array allows functions to be invoked with extra arguments. This includes ones that are not already defined as the functions parameters. The implications of this, is that functions can be invoked with an unspecified number of arguments.

Let’s take a look.

Arguments Parameter Example:


// invoked as a function
var addStuff = function() {
  var result=0; 
  for(var i=0; i < arguments.length; i++) {
    result += arguments[i];
  }
  return result;
}
console.log(addStuff(1,2,3); // 6


And that's it for the JavaScript invocation review.
Happy coding 😀


Proxy Node.js Application Requests through Apache

Running a Node.js application along side other non node web applications can work well if configured correctly. This tutorial will show you how to easily configure a Virtual Host to proxy Node.js application requests through Apache.


First, we need to make sure that we have Node.js running on a port other than the port Apache is running on (usually port 80). Our goal is to run the Node.js server on a port other than 80, and then use Apache to proxy incoming Node.js application requests to the port that the Node.js server is running on.


First, we need to make sure that Apache has the mod_proxy.so and mod_proxy_http.so modules loaded. If they are not loaded, go uncomment them in the Apache configuration file, and then restart the server.

Next, we need to configure an Apache Virtual Host just like we would any other VHost, except we want to proxy all domain requests for your Node.js application to the Node.js server.


**Note: The process is also the same if only a portion of an application is using Node.js.


Let’s take a look.

Apache Virtual Host for the Node.js Application



    ServerName www.yoursite.com
    ServerAlias yoursite.com
    DocumentRoot /your/site/location
    ErrorLog logs/yoursite.com-error_log
    CustomLog logs/yoursite.com-access_log common

    ProxyRequests off
    
        Order deny,allow
        Allow from all
    
    
        ProxyPass http://127.0.0.1:3000/
        ProxyPassReverse http://127.0.0.1:3000/
    




**Note: This configuration assumes that the node.js server is already running locally on port 3000, but it could be configured to use any unused port and/or an IP, that points to a system that is not the same as the one that Apache is running on.


Next, we need to tell Apache to proxy all node.js requests to node.js. This is done in our location directive with ProxyPass. All domain requests for www.yoursite.com will proxy to the node.js server running locally on port 3000.

Our ProxyPassReverse is used if/when our application performs a redirect, however its usually good practice to add even if your application isn’t redirecting.

For example, if our Virtual Host proxies incoming requests to our node.js application running at localhost on port 3000, and if our application performs a HTTP 301 or 302 redirect for one of those requests, there we be an error.

Our response headers will contain a location of http://127.0.0.1:3000/your/site/location/redirected-location when sent back to Apache.

And as you can tell, if Apache sends this location back to the client, then there will more than likely be an error.


ProxyPassReverse solves this by rewriting the location in our response headers so that Apache sends yoursite.com/redirected-location back to the client’s browser.


After that, save your Virtual Host configuration for your node.js application, and restart Apache.


And that’s it!

All incoming requests to yoursite.com should now be proxied to your node.js application.


Happy Coding! 😀

JavaScript Async and Callbacks versus Promises

JavaScript Async & Callbacks

Asynchronous calls and callbacks are how JavaScript is able to respond to user events that occur after the browser has loaded the DOM. This type of programming is commonly referred to as event-driven programming.

In event-driven programming, once an event occurs, its registered callback to that event fires off its functionality. An event could occur from many varying incidents, such as removing an input field from a web form, or retrieving data from a remote web service.

Let’s take a look

Async call with a Callback


// get data from remote url
getJSON(url, function(err, data){
  // check for errors
  // no errors - process data
  // check data condition
  // check another condition
  // else do this condition
});

The data returned from calling our remote web service, fires the callback function with either the data or an error returned as a dynamic argument.

Using a callback for a simple event is fine. However, if an event contains multiple conditions that need to be checked, then callback functions can become hard to read and maintain. In these more complex cases, JavaScript Promises are the solution.


JavaScript Promises
JavaScript promises are considered a best practice when “calling back”. Promises make callback functionality easier to read by eliminating the need for convoluted error and data conditional checking.

The reason is due to a specific condition will not fire, unless it occurs.

Let’s take a look

Async Using a Promise


// our promise
var promiseData = getRemoteData(url);

promiseData.then(function(data){
  // do something interesting
  // with the returned data  
});

We create a promise variable named promiseData and then call the remote web service like before.


JavaScript promises have a then method defined on them, and this is the location where we create our callback functionality.


If any side effects occur, such as an error, we don’t have to check for this condition, because our then method will only fire the callback if the data is returned. If the data does not return, the then method never executes.


And that’s it! There’s obviously a million other examples between the two, but this gives an simple clear cut practical solution on why you would use promises.

Happy coding! 😀

The Decorator Pattern in Java and Javascript

The Decorator Pattern is a highly used Object Oriented structural design pattern, that gives the ability to attach additional responsibilities to an object dynamically, without sub-classing.


When this pattern is used correctly, it can be extremely powerful due to the flexibility it offers.


So… Grab yourself a cup of coffee, or better yet… Some of THIS and let’s get to work! 😀


Now you’ve probably seen the Decorator Pattern implemented multiple times in many Object Oriented languages, so to change it up a bit, we’ll compare the implementation in both Classical inheritance and Psuedo-Classical inheritance with some Prototype inheritance functionality.


**NOTE:  The JavaScript implementation of the decorator pattern is not pure Prototypal inheritance.

It’s referred to as “Pseudo-Classical” inheritance with a few aspects of Prototypal inheritance. I explain why once we get to the JavaScript implementation.


Before we start, let’s talk about why you would even consider using the Decorator pattern, by giving a practical example.


Suppose we’re designing a system for a restaurant…

Now, in our restaurant’s system, we have a drink application that contains a subsystem which calculates the price of different drinks that this restaurant sells.

However, since we don’t live in a perfect world, we assume that not every customer will want to order a drink exactly the way it’s specified on the menu.

Since declining custom drink orders is bad for business, and the number of possible drink combinations are high, we are going to have to think about our design thoroughly.


As you can probably already see, a typical inheritance hierarchy isn’t going to work by itself…

Sub-classing for every current and future drink type *combination* would become a maintenance nightmare, therefore another approach must be taken.


**NOTE: Before we start, I also want to make a point that this design is not what you would do for any real application, much less a production application.


Why?

Well for one, we wouldn’t just throw all of our concrete subclass “decorations” (Red Bull, Orange Juice, Monster, etc) all into a single hierarchy under the Decorator.

Clearly Red Bull and Orange Juice have nothing in common…

Well, besides being a liquid… But with good Object Oriented Analysis and Design, along with being a production restaurant application, that is clearly not enough.


Well… Now that I think about it…
That’s assuming that this application will *actually* need to be maintained in the future.

If it didn’t, we could just throw everything in one gigantic function…
Maybe main()?
lol.. I kid.. I kid… 😀


Why is it not enough?

Well, what would happen if we wanted to decorate our drink with fruit?
maybe a cherry?
how about a lime?
or what about a napkin?
maybe a straw?


As you can see, those objects aren’t anywhere near related to each other.

The only thing a cherry and a napkin have in common, is that some drinks may use both of them.. lol 😀


So these issues (along with many others) are the reason our Object Oriented design for the entire restaurant system needs to be thoroughly thought out.


The reason I have it implemented like this, is to keep it simple..

By doing so, we can focus all of our attention on the actual Decorator Pattern, and what it is doing, without confusion.


So, without further ado….

*Clears throat… Mic check 1…2…3…* 😀


—- Introducing the Decorator Pattern —-


Decorator Pattern UML
decorator_pattern


Java Output
decorator-ss


The Decorator Pattern implementation in Java (Classical Inheritance)

Drink.java  –  Client Code

public class Drink {

  // Client Code
  public static void main(String[] args) {
  
    // create a drink with brand of vodka
    Vodka drink = new GreyGoose();

    // display vodka brand and price
    System.out.println(drink.getBrand() + 
      " $" + drink.calculatePrice());

    // decorate the drink with a mixer
    // mix the drink with a large Red Bull
    Vodka mixedDrink = new RedBull(drink, "Large");

    // decorate the drink with another mixer
    // mix the drink with a medium Orange Juice
    mixedDrink = new OrangeJuice(mixedDrink, "Medium");
        
    // decorate the drink with yet another mixer
    // mix the drink with a Medium Monster
    mixedDrink = new Monster(mixedDrink, "Medium");

    // Display the type and price of the drink's
    // mixed ingredients, along with the drink total,
    // and format output to 2 places
    System.out.printf("Mixing a drink of " + 
      mixedDrink.getBrand() +
      "\nTotal price is: $%.2f", 
      mixedDrink.calculatePrice());
    }
}

Vodka.java

public abstract class Vodka
{
  protected String brand = "Unknown Vodka";

  protected String getBrand()
  {
    return this.brand;
  }

  protected abstract double calculatePrice();
}

GreyGoose.java

public class GreyGoose extends Vodka
  public GreyGoose()
  {
    this.brand = "Grey Goose";
  }
  
  public double calculatePrice()
  {
    return 32.99;
  }
}

VodkaDecorator.java

public abstract class VodkaDecorator extends Vodka
{
  protected Vodka drink;
  protected abstract double sizePrice(String size);
  protected abstract String getBrand();
  protected abstract double calculatePrice();
}

RedBull.java

public class RedBull extends VodkaDecorator
{
  private String size;
  private double price;

  public RedBull(Vodka drink, String size)
  {
    this.drink = drink;
    this.size = size;
    this.price = this.sizePrice(size);
  }

  protected double sizePrice(String size)
  {
    double price;   
    switch (size) {
      case "Small":
        price = 2.99;
        break;
      case "Medium":
        price = 4.99;
        break;
      case "Large":
        price = 6.99;
        break;
      default: // unknown size - super wings
        price = 8.99;
      }
    return price;
  }

  public String getBrand()
  {
    return this.drink.getBrand() + 
      "\nand a " + this.size +
      " Red Bull which gives you wings for $" +
      this.price;
  }

  public double calculatePrice()
  {
    return this.price + 
      this.drink.calculatePrice();
  }
}

OrangeJuice.java

public class OrangeJuice extends VodkaDecorator
{
  private String size;
  private double price;

  public OrangeJuice(Vodka drink, String size)
  {
    this.drink = drink;
    this.size = size;
    this.price = this.sizePrice(size);
  }

  protected double sizePrice(String size)
  {
    double price;   
    switch (size) {
      case "Small":
        price = .99;
        break;
      case "Medium":
        price = 1.99;
        break;
      case "Large":
        price = 2.99;
        break;
      default: // unknown size - super orange
        price = 3.99;
      }
    return price;
  }

  public String getBrand()
  {
    return this.drink.getBrand() +
      "\nand a " +
      this.size +
      " Monster energy for $" +
      this.price;
  }

  public double calculatePrice()
  {
    return this.price +
      this.drink.calculatePrice();
  }
}

Monster.java

public class Monster extends VodkaDecorator
{
  private String size;
  private double price;

  public Monster(Vodka drink, String size)
  {
    this.drink = drink;
    this.size = size;
    this.price = this.sizePrice(size);
  }

  protected double sizePrice(String size)
  {
    double price;   
    switch (size) {
      case "Small":
        price = 3.99;
        break;
      case "Medium":
        price = 5.99;
        break;
      case "Large":
        price = 7.99;
        break;
      default: // unknown size - super energy
        price = 9.99;
      }
    return price;
  }

  public String getBrand()
  {
    return this.drink.getBrand() +
      "\nand a " + 
      this.size +
      " fruity Orange Juice for $" +
      this.price;
  }

  public double calculatePrice()
  {
    return this.price +
      this.drink.calculatePrice();
  }
}



OK, let’s talk about what’s going on…


First, starting in our client code (Drink.java), we create a new drink by instantiating the concrete subclass Grey Goose as a type Vodka.


Next, we “decorate” our drink of Grey Goose with some Red Bull…

We do this by instantiating a concrete subclass of one of our “decorations”, and then inject our drink object (Grey Goose) into our Red Bull object.

By decorating (wrapping) our drink object, this will allow us to polymorphically call calculatePrice() on both objects (when unwrapping), since both Vodka subclasses and VodkaDecorator subclasses are of type Vodka.


**NOTE: Notice how our VodkaDecorator not only inherits from our abstract base class Vodka, but it also composes a Vodka object.


If you haven’t already seen why, having our VodkaDecorator inherit from Vodka and compose Vodka is extremely important.

Our decorations (RedBull, Monster, etc.) need to have the same “interface” as the object they’re decorating.

With VodkaDecorator, we’re using inheritance in order to gain the same super-type as our drink objects, but we’re using composition in order to gain behavior.


Gaining behavior through composition is where our flexibility comes from. If we didn’t, and gained our behavior through inheritance alone, then any needed behavior would have to be determined at compile time only from what our Vodka base class can offer.
Since we’re using composition we can mix our decorations in any order at runtime!


And that’s really all there is to it.. We can use as many or as few decorations that we need for our drink.

We could pass our drink object to multiple RedBull objects, or one Red Bull, one Orange Juice, and one Monster (like the implementation does), or none at all..




OK, now let’s discuss the implementation in JavaScript…


The decorator pattern isn’t really relevant in JavaScript like it is in statically typed languages like Java.

Extending objects at runtime are common with dynamically typed languages, and this behavior is native in JavaScript.

Because it’s more or less built into JavaScript, the behavior that we’ve seen the decorator pattern provide isn’t really needed.

Furthermore, when JavaScript’s native behavior isn’t sufficient, another pattern called a Mixin is usually much better suited.

However, let’s still take a look at what it looks like in JavaScript…


**NOTE: This JavaScript implementation is referred to as pseudo-classical inheritance, not prototypal.

Even though JavaScript is a classless language, this implementation still simulates classes and treats the simulated classes like a class based heirarchy.


This is why this type of inheritance implementation is referred to as “pseudo-classical”.

In true prototypal inheritance we have no need for classes, whether real or simulated, so abstracting a classical inheritance hierarchy doesn’t make much sense.


The Decorator Pattern implementation in JavaScript


Run output in JSFiddle



Drink.js  –  Client Code

var main = (function() {
  var drink = new GreyGoose('Grey Goose');
  alert(drink.getBrand() + 
  " $" +
  drink.calculatePrice());

  var mixedDrink = new RedBull(drink, "Large");
  alert(mixedDrink.getBrand() +
    "\nTotal price is: $" +
    mixedDrink.calculatePrice());
})();

Vodka.js

var Vodka = function() {
  if (this.constructor === Vodka) {
    throw new Error("Abstract");
  }
};

Vodka.prototype.getBrand = function() {
  if (this.brand === undefined) {
    this.brand = "Undefined Vodka Brand";
  }
  return this.brand;
}

Vodka.prototype.calculatePrice = function() {
  throw new Error("Abstract Method");
}

GreyGoose.js

var GreyGoose = function(brand) {
  Vodka.apply(this, arguments);

  this.brand = brand;
};

GreyGoose.prototype = Object.create(Vodka.prototype);
GreyGoose.prototype.constructor = GreyGoose;
GreyGoose.prototype.calculatePrice = function() {
  return 32.99;
};

VodkaDecorator.js

var VodkaDecorator = function() {
  if (this.constructor === VodkaDecorator) {
    throw new Error("Abstract");
  }
};

VodkaDecorator.prototype.sizePrice = function(size) {
  throw new Error("Abstract Method");
 };

VodkaDecorator.prototype.getBrand = function() {
  throw new Error("Abstract Method");
 };

VodkaDecorator.prototype.calculatePrice = function() {
  throw new Error("Abstract Method");
}

RedBull.js

var RedBull = function(drink, size) {
  this.drink = drink;
  this.size = size;
  this.price = this.sizePrice(size);
}

RedBull.prototype = Object.create(VodkaDecorator.prototype);
RedBull.prototype.constructor = RedBull;

RedBull.prototype.sizePrice = function(size) {
  return function() {
    var price;
    switch (size) {
      case "Small":
        price = 2.99;
        break;
      case "Medium":
        price = 4.99;
        break;
      case "Large":
        price = 6.99;
        break;
      default:
        price = 8.99; // unknown size - super wings
        break;
    }
    return price;
  }(); // private method by closure
};

RedBull.prototype.getBrand = function() {
  return this.drink.getBrand() +
    "\nand a " + this.size +
    " Red Bull which gives you wings for $" +
    this.price;
};

RedBull.prototype.calculatePrice = function() {
  return this.price +
    this.drink.calculatePrice();
};



With the exception of not decorating our drink with as many decorations, the JavaScript implementation is exactly the same as the Java implementation.

Within the confines of JavaScript we use the same inheritance hierarchy, and we add in some prototypal aspects to create the same decorator pattern behavior.


The explanation of prototypal functionality is out of the scope of this tutorial, but using this behavior (and some hacky throwing of errors) we can mimic classical inheritance in JavaScript.

In actuality, implementing the behavior of the decorator pattern in JavaScript (in a non psuedo-classical way) is much simpler.


So there you have it!
The decorator pattern offers powerful flexibility when used appropriately and it will prove itself to be a powerful tool in your Object Oriented toolbox.

Have fun! 😀