0

I've been always creating JS objects like this a = {} or this a = new MyConstructor() without thinking much about it.

Then I came up with some code that looks like this:

function Constructor(){
    var private = {
          a:1,
          b:2
    };
    return private;
}


var a = new Constructor();

a naturaly now contains a new instance of the private object. And then I realised that the new operator is not required because the private object gets created every time the Constructor function gets called.

So the actual question is: What happens when calling new Constructor()?

Why shouldn't just do a = Constructor() instead?

What happens to any public properties of the Constructor object if any?

Is returning objects from a constructor a bad idea?

Loupax
  • 4,046
  • 4
  • 36
  • 63
  • 2
    [What is the 'new' keyword?](http://stackoverflow.com/questions/1646698/what-is-the-new-keyword-in-javascript) might help. –  Jun 20 '14 at 10:11
  • Also relevant is [Constructor function vs Factory functions](http://stackoverflow.com/questions/8698726/constructor-function-vs-factory-functions) (you're actually talking about a *factory* function, not a constructor). – Qantas 94 Heavy Jun 20 '14 at 10:29

2 Answers2

0

What happens when calling new Constructor()?

Have a look at the docs for the new operator and the What is the 'new' keyword in JavaScript? question.

An instance is created (like Object.create(Constructor.prototype)), which is accessible via this inside the Constructor function. However, the result of the call will only be the returned object (private), that is assigned to a.

Why shouldn't just do a = Constructor() instead?

Actually, you should do this. Constructor is not a constructor, it doesn't create instances - it just returns the private object. Therefore, don't use new. However, you should also rename the function so that it is clear, e.g. to makeXYZ().

What happens to any public properties of the Constructor object if any?

a and b are the "public" properties of the returned objects.
If you mean "static" properties on the Constructor function itself, nothing happens to them.
If you mean "shared" properties on the Constructor.prototype - nothing happens to them, they do not get inherited by the returned objects (which is probably not what was intended).

Is returning objects from a constructor a bad idea?

From constructors, yes.
From functions in general, no. Make it a normal factory function (i.e. a function that returns objects), which is a fine pattern.

Community
  • 1
  • 1
Bergi
  • 513,640
  • 108
  • 821
  • 1,164
  • So, the actual answer to the question is (according to the docs) `when a constructor returns a value, the object construction proccess is overridden`. Is that correct? – Loupax Jun 20 '14 at 10:39
  • Somewhat, yes. The instance object is still created, and accessible as `this` inside the constructor as usual, but `a` will become only the `private` object that was returned. – Bergi Jun 20 '14 at 10:55
  • That was the answer then :) If you add this in your answer I'll accept it – Loupax Jun 20 '14 at 11:03
0

You faced with " NativeObject" javascript pattern. It emulates some OOP paradigms like encapsulation, polymorphism, inheritance, abstraction and so on.

With "new" keyword you create new instance of the object, in JS it can be 

var function_example = function() {
var privateField = 11;
var publicField = 22;

return {
publicField: publicField
}    
}

So, when you what to get object you can call this function:

var object = function_example();

If you want to get function as delegate and assign a reference to it, u can:

var function2_axample = function_example;

If you want to create new instance u should:

var instance = new function_example();
var publicValue = instance.publicField;

So, u can remember, in compare with OOP paradigm, it like this: function - it is class, new function - it is instance.

irotaev
  • 71
  • 7