Several years later, I decided to read Pro JavaScript Design Patterns by Harmes and Diaz again. This book has almost become controversial for its introductory section which presents a suggestion to implement interfaces in JavaScript.

Pro JS Design Patterns implements an Interface object, simply by attaching the several method attributes to an object during creation. The interface class is more likely to be a Factory class since it creates a new class definition based on the input parameters.

// Constructor.
var Interface = function(name, methods) {
    this.name = name;
    this.methods = [];
    for(var i = 0, len = methods.length; i < len; i++) {
        this.methods.push(methods[i]);
    }
};
// create Widget class which implements an interface with two methods: addSubView and removeFromSuper.
var Widget = new Interface('Widget', ['addSubView', 'removeFromSuper']);

Once you initialize Widget, you ensure that Widget is implementing addSubView and removeFromSuper methods. This is a methodology/concept book is presenting. In this blog post, I’ll try to explain you why conceptually it makes no sense to implement an Interface object in JS.

There is no “before run-time”

Dynamic languages are forming the classes at the run-time. Interfaces are invented to find failures during compiling time — long before code is being run. If you develop control methodologies or test against a structure, it might be very pointless due to the fact they are going to be executed in run-time. If your situation is not critical, let it fail on actual code during the test. Nevertheless, you can always check if required methods are implemented by the instance and raise flags if something has gone bad for critical operations or not-trusted objects comes from an AJAX request for example.
If you truly want to make “before run-time” checks, your problem turns out to be a unit-testing one. You can simply write external test code to consume your JS library and check if your object is implementing your set of methods. This is absolutely is not a solution since you are able to modify object structure during the execution (see next section). You, again, can’t be sure your code is going to break it all or not.

Hierarchy or functionality changes at run-time

Almost any object is changeable during run-time — although there are some exceptions with [global] object in browser implementations since window is the [global] object and modification is a security problem . Hierarchy may change, properties may change. So, there is again no guarantee that a Factory created object will agree a certain protocol during the run-time.

The cost

Nothing comes for free. Factory like initialization is an overhead, huge or small, it’s still overhead. It requires extra iterations over objects during creation. And you’re required to iterate over same properties while implementing the methods.

Consequently, there is almost no practical point to create classes from an Interface factory at all. If your code is getting large, write automated tests and find ways to share schema around the developers more efficiently.