0

It has been awhile I write spagetti code using javascript. I tried to organize my code but I'm confused which one to use and when to use certain pattern.

constructor pattern

function foods(food){
  this.food = food;
  this.eat = function(){
    return 'I"m eating ' + this.food;
  }
}

var eatApple = new foods("apple");
console.log(eatApple.eat()); 

var eatBanana = new foods("banana");
console.log(eatBanana.eat()); 

object literal

var foods = {
  food : null,
  eat : function(){
    return 'I"m eating ' + this.food;
  }
};

foods.food = 'apple';
console.log(foods.eat());

foods.food = 'banana';
console.log(foods.eat());

revealing module

var foods = function(){
  var defaultFood = "default food";
  function eat(food){
    //this is ugly
    if(food){
      food = food;
    }else{
      food = defaultFood;
    }
    return 'I\"m eating ' + food;
  }

  return {
    eat: eat
  };
}();

var justEating = foods.eat();
var eatingApple = foods.eat('apple');
var eatingBanana = foods.eat('banana');

console.log(justEating);
console.log(eatingApple);
console.log(eatingBanana);

I think object literal is the most common use, why isn't everybody just use that? And is revealing module still relevant in 2016? most people will just do module.exports.

Devalor
  • 55
  • 7

1 Answers1

0

I won't recommend object literal pattern because it is hard to use it as a template. I don't know about revealing module but coding style looks ugly and cumbersome.

Consider this example,

Object literal:

var Fruit = {
  type: "Banana",
  getType: function(){
    alert("My type is " + this.type);
  }
}

Fruit.type = banana;
Fruit.type = mango;
Fruit.getType(); // displays  My type is Mango

Now if you wish to add a fruit type like "Mango", you will again have to write the whole object or change the above one. In other words, its not behaving like an instance of a class, so it becomes difficult to use it.

If it was a constructor pattern, then it would have been very easy.

Constructor pattern:

var Fruit = function(type){
  this.type = type
}

Fruit.prototype.getType = function(){
  alert("My type is " + this.type);
}

var banana = new Fruit("Banana");
var mango = new Fruit("Mango");
banana.getType(); // displays  My type is Banana
mango.getType(); // displays  My type is Mango

The whole thing acts like a class (template) and it becomes easy to create different instances of the same. Also it becomes very easy to inherit.

Checkout ES6, the syntax is sweet

Update:

Revealing module pattern:

This one uses closure and it is prone to errors if not used carefully. For example,

var Fruit = function(){
  var type = null;
  var getType = function(){
    return "My type is " + type;
  };

  return {
    type: type,
    getType: getType
  }
}

var newFruit = Fruit();
newFruit.getType(); // My type is null

newFruit.type = "Banana"; 
newFruit.getType(); // My type is null

In this particular case, even if you change the type, the function getType() wont execute as expected as it still remembers the variables from outer function Fruit(). This behaviour is a result of closures.

Flying Gambit
  • 1,238
  • 1
  • 15
  • 32
  • this pattern is `dangerous` in my exp. If the project grow bigger u will have hard time tracing the inheritance. I prefer singleton because it promotes composition. – Devalor Dec 20 '16 at 08:23
  • Object literal or revealing module ? – Flying Gambit Dec 20 '16 at 08:30
  • While creating apps, take the main app as an object, then each sub module of the app becomes another object. Thus making all the objects independent of each other. This way it becomes easier to debug and maintain. – Flying Gambit Dec 20 '16 at 08:40