JavaScript notes: classes and object literal notation

A couple of days ago I started building a lightbox feature using a similar object oriented method that I used for the number input enhancement. I began by building a custom object class because this was the only way I knew how. Then Jeremy spotted that there was a JavaScript style that would be more suited to a lightbox pattern: Object literal notation. So, thanks to some teaching from Jeremy, I am armed with an ability to work with two different styles of JavaScript: classes and object literal notation. I was pretty sure I understood the difference between the two and when I would choose one over the other, until I tried to write about it. I don't know if I can explain it all yet, so today, I am going to document what I have learnt about the differences between creating objects via classes and object literal notation in note form.

Classes

Custom objects can be created using classes like this:

function Lightbox(argument) {
    var closeButtonSelector = '.js-lightbox-close'; /*Property*/
    this.init = function() {
        //Public method    
    };
};

Or it can start like this:

var Lightbox = function(argument) {

};

Before they will work, objects of the class need to be instantiated like this:

var myLightbox = new Lightbox(argument);

Object Literal notation

Objects, methods and properties can be defined like this:

/*Object*/
var Lightbox = {
    linkClass: 'js-lightbox', /*Property*/
    closeButtonSelector: '.js-lightbox-close', /*Property*/
    createLightbox: function () {
        //A method
    },
    keyListener: function(ev) {
        //Another method
    }
};

Differences

  • When writing classes properties and methods are defined after an equal sign, whereas in the object literal style, they can be written differently using a colon and a comma instead of the equal sign (as seen above).
  • Classes provide the blueprint for which an object will inherit its properties and methods. This means that objects need to be instantiated before they can be used. Object Literal notation can be used to create an object, but not classes.
  • Whilst objects derived from classes inherit properties and methods from their class, they can also be extended. This means that new properties and methods can be added to individual instances. This is not possible for objects created in literal form because only one object is created—no classes.

To instantiate or not to instantiate

The most significant difference I can see between creating classes and literally notated objects is that the latter are entire objects, whereas classes are not objects, but blueprints from which objects are created. Being able to create and extend new objects looks like a pretty powerful feature.

So, which one do I use? From what I see right now, if only one object of its kind is needed then the object literal notation makes sense. If multiple objects are required or they need to be modified, then classes are needed. I can think of a few use cases for creating custom objects with classes such as carousels,

Some terminology to be aware of (I am not attempting to define them)

Namespace

Namespaces allow us to group code and avoid naming conflicts. Objects create namespaces, so we can avoid creating global variables. It is better to avoid using global variables because the more you have, the greater chance you have of accidentally overwriting a value. Too many global variables is referred to as 'polluting the global namespace'.

Encapsulation

Encapsulation is also the grouping of properties and methods and helps protect the global namespace.

Class

A class is the blueprint which defines what properties and methods object should inherit.

Objects

Objects are self-contained components, which contain properties and methods. They represent attributes and behaviour of a 'thing' being modelled.

Properties

These are the variables that belong to an object. Variables are declared and they get values assigned to them.

Methods

These are functions that do something within the object.

Scope

I can't explain this fully yet. At the moment, when I think of scope I think of an object or location having particular variables available to it. When a variable is declared inside a function, it is only available to code inside of that function—not to code outside the function. This refers to local scope.

Note: Variables that are declared inside a function without a var declaration are not local to the function. JavaScript traverses up until it finds the variable declaration. If the variable wasn’t previously declared, it is added to the global scope (where variables can be accessed by any function). To me, this sounds a little risky as it I think it could be hard to track global variables like this and possibly lead to unexpected results.