Getters and Setters in JavaScript

This is the fourth article in the series of Object Oriented Javascript. Following our discussion on inheritance and it's integration with modular design pattern, I'd like take a deeper look into encapsulation and usage of mutator methods. Getters and setters allow you to build useful shortcuts for accessing and mutating data within an object.

__defineGetter__ and __defineSetter__

If you had searched for the information over the internet, you would have probably encountered recommendations, mostly from Microsoft :), to use __defineGetter__ and __defineSetter__. You may have also found some hacks for IE7 and even IE6. Even from a look at them you can smell something fishy. JavaScript is not C and doesn't encourage usage of underscores. Your gut feeling is right.

This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Do not use it in old or new projects. Pages or Web apps using it may break at any time.

For the aforesaid reasons, I'm not going even to discuss these methods. Trying to polyfill and redefine them will only make things worse and you should stop yourself before starting such madness.

Object.defineProperty

The method defines new or modifies existing properties directly on an object, returning the object. Besides defining property accessors, the method also allows to define some neat features like writable to make the property read only, enumerable to show the property during enumeration process over object's properties and others like defining default values and ability to delete the property. You can have a look a the whole list here. Let's have a look at how it's used. I'll be showing a simple scenario without the extra features.

(function () {
   'use strict';
   function Room() {
      var temperature = null;

      Object.defineProperty(this, "temperature", {
         get: function() {
            console.log("get!"); 
            return temperature; 
        },
        set: function(value) { 
            console.log("set!"); 
            temperature = value; 
        }
    });
  }
})();

Here we declared the temperature property along with it's accessors. Take a look at line 4 - it's important to define the property before calling Object.defineProperty, otherwise you'll get an error. Once we've defined it, let's try to use it - actually you won't notice any difference:

var r = new Room();   
r.temperature = 1;
console.log(r.temperature);

The output will be:

set!
get!
1 

You'll encounter into problems once run on IE8 (of course :). Even though it supports it, there is some bad blood between the two - it could only be used on DOM objects. There is a workaround though - Object.defineProperties. It offers the same functionality as Object.defineProperty, however it is not supported by IE8 at all. How does it solve our problems? We can define it's polyfill and get full featured support in all browsers.

get and set

As of ECMAScript 5, a new syntax was introduced to help with the mess and make things cleaner - get and set. Let's see our previous example using the new syntax:

function Room() {}

Room.prototype = {
   get temperature() {
      console.log("get!");
      return this._temperature;
  },
  set temperature(temp) {
      console.log("set!");
      this._temperature = temp;
  }

};

The code of course produces the same results. You may not notice, but pay attention to the access to private member _temperature in lines 6 and 10. The attribute is created implicitly for us by runtime engine.

The problem with last solution is that it cannot be mimicked on not supporting browsers. Instead you'll get a syntax error. This is something you should take with yourself if you're willing to take such risks.

The old way

If you really need the IE support and don't like the idea of Object.defineProperties, you can always go back to creating your accessors manually:

function Room() {
   this._temperature = null;
}

Room.prototype = {
   getTemperature: function() {
      console.log("get!");
      return this._temperature;
  },
  setTemperature: function(temp) {
      console.log("set!");
      this._temperature = temp;
  }
};

And surely change your usage habits:

var r = new Room();   
r.setTemperature(1);
console.log(r.getTemperature());

Hope the article sheds some light onto the dark bog of JavaScript accessors. Be glad to here some comments.

Modular Design Patterns and Inheritance

Last week we talked about JavaScript inheritance and if you recall we had talked about modular design patterns in JavaScript just a month ago. I would also like to talk about how to connect both modules and class inheritance. We've already discussed that modules are classes. So if we can link classes by inheritance relationship, the logical half of our brain suggests that we should be able to link modules as well. The logic prevails - we can.

AMD and inheritance

I'll be using the classes we defined in the inheritance article, Mammal and Dog, and create modules from them. Let's start with our super class:

(function () {
    'use strict';
 
 define(function() {
  
  function Mammal() {
    this.age = 0;
    console.info("Mammal was born");
  }
   
  Mammal.prototype.grow = function() {
      this.age += 1;
      console.log("Mammal grows");
  };

  return Mammal;
 });
}());

Let's use it in our entry point JavaScript file. Just to remind you this file is declared in data-main attribute.

(function () {
    'use strict';
 require(["Mammal"],
     function(Mammal) {
         var m = new Mammal();
         m.grow();
     }
   );
})();

Now it's time to create our Dog module. Since it needs Mammal for the inheritance, we'll list it in our dependency list. The implementation remains the same.

(function () {
    'use strict';
 define(["Mammal"],
     function(Mammal) {
         function Dog(name) {
     this.name = name;
     Mammal.call(this);
   }

   Dog.prototype.grow=function(){ 
     this._super.grow.call(this);
     this.age =+ 1; 
     console.log('Dog grows');
   }
    
   Dog.prototype = Object.create(Mammal.prototype);
   Dog.prototype.constructor = Dog;
   Dog.prototype._super = Mammal.prototype;
     
   return Dog;
     });
})();

And of course update our main file to see if it works:

(function () {
    'use strict';
 require(["Mammal", "Dog"],
     function(Mammal, Dog) {
         var m = new Mammal(), d = new Dog('Rocky');
   m.grow();
   d.grow();
     }
   );
})();

CommonJS and inheritance

As you recall modules should be defined using the CommonJS syntax if you want to use them in Node.js.

(function () {
    'use strict';
 
 function Mammal() {
   this.age = 0;
   console.info("Mammal was born");
 }
  
 Mammal.prototype.grow = function() {
     this.age += 1;
     console.log("Mammal grows");
 };

 module.exports = Mammal;
}());

As you can see we removed define method call and replaced return with module.exports.

(function () {
    'use strict';
 
 var Mammal = require('Mammal');

    function Dog(name) {
   this.name = name;
   Mammal.call(this);
 }

 Dog.prototype.grow=function(){ 
   this._super.grow.call(this);
   this.age =+ 1; 
   console.log('Dog grows');
 }
  
 Dog.prototype = Object.create(Mammal.prototype);
 Dog.prototype.constructor = Dog;
 Dog.prototype._super = Mammal.prototype;

 module.exports = Dog;
})();

Here instead of listing the dependencies, we just require the Mammal class in our Dog definition.

Object Oriented JavaScript - Inheritance

Up until now, we've talked about Object Oriented JavaScript programming. Creating classes though doesn't make you code truly object oriented. What you lack is polymorphism, which is achieved through inheritance.

JavaScript is a bit confusing for developers coming from Java or C++, as it's all dynamic, all runtime, and it has no classes at all. It's all just instances (objects). Even the "classes" we simulate are just a function object.

Prototype Chain

When it comes to inheritance, JavaScript only has one construct: objects. Each object has an internal link to another object called its prototype. That prototype object has a prototype of its own, and so on until an object is reached with null as its prototype. null, by definition, has no prototype, and acts as the final link in this prototype chain.

Object.create

After being long advocated for, EcmaScript 5 has standardized a new method called Object.create. To keep up with progress, I'll be presenting inheritance using only this method. For those who want to use it with incompatible browsers, you must add its polyfill.

As the name states, the method creates a new object with the specified prototype object and properties. To understand the meaning of this, let's take a look at example:

function Mammal() {
  this.age = 0;
  console.info("Mammal was born");
}

Mammal.prototype.grow = function() {
    this.age += 1;
    console.log("Mammal grows");
};

function Dog(name) {
  this.name = name;
  Mammal.call(this);
}

Dog.prototype = Object.create(Mammal.prototype);
Dog.prototype.constructor = Dog;
var m = new Mammal(), d = new Dog('Rocky');
m.grow();
d.grow();

At first we created our superclass, Mammal, with attribute age and method grow. After that we declared class Dog, with its constructor and additional attribute, name. The inheritance happens in line 16, where our creation method takes Mammal's prototype and creates a new object inherited from it. Assigning it to Dog's prototype attribute, closes the loop. Take a look at line 11, where Dog's constructor is declared. Inside we call our Mammal constructor, by using call method. Together with constructor substitution in line 17, we achieve a proper relationship of our constructors. Otherwise instances of Dog would have a constructor of Mammal and attribute name wouldn't be initiated. The output of the code, can be seen below:

Mammal was born
Mammal was born
Mammal grows
Mammal grows 

You can see that Mammal's constructor as well as it's method is called when using both Mammal and Dog instances. Now what if we wanted to override the grow method with our own? The following code does exactly this:

Dog.prototype.grow=function(){ 
 Mammal.prototype.grow.call(this);
 this.age =+ 1; 
 console.log('Dog grows');
}

Calling the previous sequence again will produce the wanted results. Now we can see that our new implementation of Dog.grow is called in addition or Mammal's one.

Mammal was born
Mammal was born
Mammal grows
Mammal grows
Dog grows 

Rather than having to know that Dog inherits from Mammal, and having to type in Mammal.prototype each time you wanted to call an ancestor method, wouldn't it be nice to have your own property of the Dog pointing to its ancestor class? Those familiar with other Object Oriented languages may be tempted to call this property super, however JavaScript reserves this word for future use. Instead, we'll call it _super. The code of course produces the same results, however in my opinion it's somehow cleaner.

Dog.prototype._super = Mammal.prototype;

Dog.prototype.grow=function(){ 
 this._super.grow.call(this);
 this.age =+ 1; 
 console.log('Dog grows');
}

Object.create can take additional parameter, properties, which aid us to define new properties following Object.defineProperty syntax to the newly created class. In our example we could add new properties to the Dog this way:

Dog.prototype = Object.create(Mammal.prototype {
 color: { writable: true,  configurable:true, value: 'brown' }
});

I find it distasteful as it breaks your class definition from your methods. It surely makes it more tedious to define your attributes. However if you like it and find it useful, you may use it as well.

Object.create vs new

Object.create is not a new operator and they are not fully interchangeable as some suggest and shouldn't be considered as such. First of all with Object.create you can create an object that doesn't inherit from anything, by passing null as a prototype parameter - Object.create(null). Setting prototype attribute with null, and instantiate a class using new operator, will create a class inherited from Object.prototype. Secondly the performance of Object.create is dreadful and should be only used for class definitions, leaving the creation process to the operator. The measurements results can be seen here.

What about multiple inheritance?

To answer in one sentence - you should avoid it. Take a look at any wide spread modern object oriented language like Java, Ruby, C# and PHP (5 of course :) - non of them allows multiple inheritance. It brings more problems than benefits and most of the times your need of multiple inheritance is a signal your object structure is somewhat incorrect. Follow the SOLID principles and you will be able to solve everything without needing to resort to such measures.

This is not only my unprofessional opinion looking for a way to shine, but also a point of view of one of the most notable man in the sphere - Bjarne Stroustrup.  Take a look at excerpt from an interview over C++ modern style:

People quite correctly say that you don't need multiple inheritance, because anything you can do with multiple inheritance you can also do with single inheritance. You just use the delegation trick I mentioned. Furthermore, you don't need any inheritance at all, because anything you do with single inheritance you can also do without inheritance by forwarding through a class. Actually, you don't need any classes either, because you can do it all with pointers and data structures. But why would you want to do that? When is it convenient to use the language facilities? When would you prefer a workaround? I've seen cases where multiple inheritance is useful, and I've even seen cases where quite complicated multiple inheritance is useful. Generally, I prefer to use the facilities offered by the language to doing workarounds.

But if you insist, it can be accomplished through inheritance by copying properties, also known as mixins. jQuery.extend is the most commonly used implementation.

JavaScript Developer Toolkit - Emmet

This is a second article about JavaScript developer's toolkit and today we're going to talk about Emmet. If you've missed the first article about the useful tools for JavaScript developers, have a look at it here.

What is Emmet?

Essentially it gives you shortcuts you can type that expand into full HTML or CSS. Like nav>a*5 will expand into a <nav> tag with eight links inside it with empty hrefs.

<nav>
 <a href=""></a>
 <a href=""></a>
 <a href=""></a>
 <a href=""></a>
 <a href=""></a>
</nav>

Or, try div.module*2>p*2>lorem and press tab. Firstly it will convert div.module*2 into two <div> elements and associate them with a module css class. After that it will look at >p*2 and create two <p> elements. In the end >lorem will fill the paragraphs with famous lorem ipsum text. Take a look at the produced code below:

<div class="module">
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit.
     Accusantium aliquid, autem eligendi explicabo possimus
        similique vitae! Asperiores ducimus ea illum perspiciatis
        placeat similique soluta, totam! Alias aut maiores
        omnis quo.
    </p>
    <p>Ab alias aspernatur eius, ex natus non obcaecati quo
     veritatis voluptatem voluptatum? Ab assumenda consectetur
        deserunt, doloremque ea et odio. Animi beatae eaque facere
        itaque nemo nobis obcaecati quis sequi.
    </p>
</div>
<div class="module">
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit.
     Ad aperiam eos esse explicabo nostrum, numquam rem
        veniam. Blanditiis commodi cum error eum incidunt ipsam
        laboriosam natus quod veritatis voluptate, voluptatibus?
 </p>
    <p>Ab architecto atque deleniti dicta dolor dolores, enim
     explicabo ipsum, libero natus nulla officiis, rerum
        tempora temporibus unde! Aliquid aspernatur eaque fuga
        molestiae nisi omnis quis repellendus reprehenderit sunt
        voluptatum.
    </p>
</div> 

There are also a bunch of editor navigation shortcuts like move to the next edit point, reflect css value, split/join tag and more. All of them are beautifully demonstrated on Emmet documentation section and even can be played with.

Emmet works with various code editors and is already bundled-in with Webstorm. It can as well be easily installed on Sublime Text, of which we talked in our previous article.

Check out for the next article in the series of developer toolkit. In fact I think I'm going to keep the tradition and post an article about the useful tools every first weekend of the month.