Category: Code

Objects with constructors and prototyped methods

In this installment, I am going to look at building a tally clicker using what seems to be the canonical form for building class-like entities in JavaScript. The idea is simple:

• Use a constructor function to create a scope/context with the object’s properties.
• Use the constructor function’s prototype property to attach methods.

Attaching methods to the constructor’s prototype allows a single method instance to be shared among all objects instantiated from the constructor function.

Here’s how we might do it:

// == Begin Clicker2 definition =====================
// -- Constructor -----------------------------------
var Clicker2 = function() {
  // properties:
  this._numClicks = 0;

  // initialize state:
  this._update();
};

// -- Methods ---------------------------------------
Clicker2.prototype.click = function() {
  this._numClicks++;
  this._update();
};

Clicker2.prototype.reset = function() {
  this._numClicks = 0;
  this._update();
};

Clicker2.prototype._update = function() {
  console.log("Clicker2 obj: " + this._numClicks);
};

Clicker2.prototype.showInfo = function() {
  alert("I am a Clicker2 object who is at " +
    this._numClicks + " clicks.");
};
// == End Clicker 2 definition ======================

The HTML might then have something like:

<button onclick="yourClicker.click();">Click</button>
<button onclick="yourClicker.reset();">Reset</button>
<button onclick="yourClicker.showInfo();">Info</button>
...
<script>
  // Wait for DOM to be ready and then instantiate a
  // Clicker2 object:
  document.addEventListener('DOMContentLoaded',
    function() {
      document.yourClicker = new Clicker2();
    });
</script>

Compared to the approach using object literals, this approach has the following advantages:

• It allows for automatic object initialization.
• The object abstraction has, “Reuse me!” written all over it.

However, it still has a couple issues:

• It violates encapsulation because everything is still public.*
• It still pollutes the global namespace.

In the next installment, we’ll look at a way to fix these remaining problems. Just as a reminder, I am not (yet) taking on the following:

• Inheritance-like stuff
• “Class” (i.e., static) members*
• Polymorphism

*An issue of religious importance.

I’ve always found JavaScript’s approach(es) to OOP a little cumbersome. I’m not talking here about prototypal vs. class-based OOP. Rather, I’m talking about the readability, etc. of the actual code you have to write to build objects. I want to take a few blog entries to try to put the maze into some kind of cohesive perspective.

I like to use a tally clicker to explore objects in languages I am learning. A tally clicker is a real-world object with a minimal set of features that are easy to implement and that map to basic but salient OOP concepts.

Object literals

I’m going to start this exploration with plain-Jane object literals. This is one of the canonical ways and often the first way shown to implement objects in JavaScript. Here’s how I might implement a tally clicker with a JavaScript literal:

// == Create a tally clicker ========
var myClicker = {

    // pseudo-private property
    _numClicks: 0,         

    // pseudo-private method
    _update: function() {
        console.log("myClicker1: " + this._numClicks);
    },

    // public methods
    click: function() {
        this._numClicks++;
        this._update();
    },

    reset: function() {
        this._numClicks = 0;
        this._update();
    },

    showInfo: function() {
        alert('I am "myClicker" and am at ' +
            this._numClicks + ' clicks.');
    }
}; // == End tally clicker ========

I might then stick something like this into the HTML:

<button onclick="myClicker.click();">Click</button>
<button onclick="myClicker.reset();">Reset</button>
<button onclick="myClicker.showInfo();">Info</button>

The object literal approach is a seductively easy and pretty readable way to build an object—but it’s got issues. Namely:

• There’s no automatic initialization apart from property values.
• It violates encapsulation because everything is public.*
• It pollutes the global namespace (sort of). As is, the name of the object is in the global namespace.
• The object abstraction doesn’t scream, “Reuse me!” (This may be a cognitive style issue more than anything else.)

In the next couple installments, I’ll consider some alternative implementations specifically with regard to the above criteria. For the moment, I will not deal with:

• Inheritance-like stuff
• “Class” (i.e., static) members*
• Polymorphism

*An issue of religious importance.