Is trying to imitate a interface/abstract class in javascript bad practice

Question

I am writing some code in Node.js that jumped out at me as being better structured using the strategy pattern. Coming from .Net I would create the interface the rest were based on and move from there, in JavaScript this is not so clear cut.

I understand as a prototypical language JavaScript does not have the notion of interface inheritance, so I am not sure what I have done is a smell or not, as I cant seem to find references, apart from one blog post which tries to infer an interface by using a base abstract class which forces the inheriting classes to implement the function (as it throws).

My base class

QueryStrategy = function () {

};

QueryStrategy.prototype.create = function(){
throw new Error("Not Implemented");
}

module.exports = QueryStrategy;

Implementation 1

var util = require('util');
var QueryStrategy = require('./queryStrategy');

SelectQueryStrategy = function (query) {
    this.parameters = query.parameters || [];
    this.entity = query.entity || '';
};

util.inherits(SelectQueryStrategy, QueryStrategy);

SelectQueryStrategy.prototype.create = function () {
    var self = this,
        params = self.parameters,
        paramList = self.parameters.length >= 1 ? '' : '*';

    for (var i = 0; i < params.length; i++) {
        var suffix = i === (params.length - 1) ? '' : ', ';
        paramList = paramList + params[i].key + suffix;
    }

    return util.format("SELECT %s FROM %s", paramList, self.entity);
};

module.exports = SelectQueryStrategy;

Currently the base does not have any shared functions, or properties. Shared functions will come, properties, because of the prototypical chain search i didn't see the point of adding the "shared" properties as they are overwritten by the instances created (please if this is wrong, let me know).

Is this an acceptable approach or should I disregard inheritance in this instance. There may be some type checking and it would make it easier if your could infer the the type to one (i.e. they must all be of the Type QueryStrategy) but I don't want my .Net prejudice to take over here.

Alternative Approach

Firstly, i am not trying to sell books here, i am just reading a lot around the subject with books that i have, but want to give credit where its due.

Based on the couple of comments, it is correct to say that the type inference won't really make any difference here and possibly should be just left down to Duck Typing to check, and maybe trying to slot something in that is not defined in the language is not the best approach. I have read in Addy Osmani Javascript patterns about interfaces, although my implementation was not the same, and although interface usage is acceptable, it is probably not needed.

It might be simpler to keep the strategy approach but with a different implementation, one that is outlined in Javascript Patterns by Stoyan Stefanov, where you have one implementation and based on some form of configuration you know which strategy to use.

Pseudo Sample

QueryBuilder = function () {
   this.types = [];
}

QueryBuilder.prototype.create = function (type, query) {
    var strategy = types[type];
    strategy.create(query);
};

QueryBuilder.types.Select = {

    create: function (query) {
        params = query.parameters,
        paramList = query.parameters.length >= 1 ? '' : '*';

        for (var i = 0; i < params.length; i++) {
            var suffix = i === (params.length - 1) ? '' : ', ';
            paramList = paramList + params[i].key + suffix;
        }

        return util.format("SELECT %s FROM %s", paramList, query.entity);
    }
};

That might be a cleaner way to go, one thing i am note sure about is if I should add types to the prototype, but I guess in this simple case it wouldn't be needed, but in a more complex scenario you could have a lot of strategies and in one file might need to be abstracted out.

is this a more acceptable approach?

What I ended up with

I looked around and tried to understand more about Duck typing, Pros and Cons etc. and tried to simplify my design based on some of the comments and answer I received. I stuck with the strategy-ish approach in that every strategy defined the same function(s), essentially encapsulating what varied across the implementations and giving them a common contract for want of a better term.

One thing that changed was the base class/interface which, as correctly pointed was not doing anything constructive was removed, each strategy is independent (so not 100% in the classical representation of the pattern) they, as stated just define the same create function.

From the place where the nested ifs and switches once belonged has been replaced with a single switch which decides which query strategy to use based on the type of query type requested. This could be re-factored into a factory later on, but for now it serves its purpose:

Query.prototype.generate = function () {

var self = this,
    strategy = undefined;

switch (this.queryType) {
    case "SELECT":
        strategy = new Select(self);
        break;
    case "INSERT":
        strategy = new Insert(self);
        break;
    case "UPDATE":
        strategy = new Update(self);
        break;
    case "DELETE":
        strategy = new Delete(self);
        break;
}

return strategy.create();
};

Each strategy is independently tested, and i feel this is easier to maintain as if something fails, it will fail in one place and investigation will be easier based on the unit tests. Obviously there is a trade off, more files, and a slightly more complex structure...we will see what happens.

Answer 1

It is an acceptable approach but it isn't really going to benefit you in any way, and may make this piece of code more difficult to maintain. The Strategy patterns are really only beneficial in languages with static typing. You could look into TypeScript, as another commenter mentioned.

In JavaScript you're going to rely more on "Duck Typing"...If it looks like a duck, smells like a duck, it's probably a duck.

http://en.wikipedia.org/wiki/Duck_typing