Question

We have been debating how best to handle objects in our JS app, studying Stoyan Stefanov’s book, reading endless SO posts on ‘new’, ‘this’, ‘prototype’, closures etc. (The fact that there are so many, and they have so many competing theories, suggests there is no completely obvious answer).

So let’s assume the we don’t care about private data. We are content to trust users and developers not to mess around in objects outside the ways we define.

Given this, what (other than it seeming to defy decades of OO style and history) would be wrong with this technique?

// namespace to isolate all PERSON's logic
var PERSON = {};

// return an object which should only ever contain data.
// The Catch: it's 100% public

PERSON.constructor = function (name) {
     return {
         name: name
     } 
}

// methods that operate on a Person
// the thing we're operating on gets passed in

PERSON.sayHello = function (person) {
     alert (person.name); 
}

var p = PERSON.constructor ("Fred");
var q = PERSON.constructor ("Me");

// normally this coded like 'p.sayHello()'
PERSON.sayHello(p);
PERSON.sayHello(q);

Obviously:

1. There would be nothing to stop someone from mutating ‘p’ in unholy
   ways, or simply the logic of PERSON ending up spread all over the place. (That is true with the canonical ‘new’ technique as well).
2. It would be a minor hassle to pass ‘p’ in to every function that you
   wanted to use it.
3. This is a weird approach.

But are those good enough reasons to dismiss it? On the positive side:

1. It is efficient, as (arguably) opposed to closures with repetitive function declaration.
2. It seems very simple and understandable, as opposed to fiddling with
   ‘this’ everywhere.

The key point is the foregoing of privacy. I know I will get slammed for this, but, looking for any feedback. Cheers.

Answer 1

There’s nothing inherently wrong with it. But it does forgo many advantages inherent in using Javascript’s prototype system.

• Your object does not know anything about itself other than that it is an object literal. So instanceof will not help you to identify its origin. You’ll be stuck using only duck typing.
• Your methods are essentially namespaced static functions, where you have to repeat yourself by passing in the object as the first argument. By having a prototyped object, you can take advantage of dynamic dispatch, so that p.sayHello() can do different things for PERSON or ANIMAL depending on the type Javascript knows about. This is a form of polymorphism. Your approach requires you to name (and possibly make a mistake about) the type each time you call a method.
• You don’t actually need a constructor function, since functions are already objects. Your PERSON variable may as well be the constructor function.

What you’ve done here is create a module pattern (like a namespace).

Here is another pattern that keeps what you have but supplies the above advantages:

function Person(name)
{
    var p = Object.create(Person.prototype);
    p.name = name; // or other means of initialization, use of overloaded arguments, etc.
    return p;
}
Person.prototype.sayHello = function () { alert (this.name); }

var p = Person("Fred"); // you can omit "new"
var q = Person("Me");
p.sayHello();
q.sayHello();
console.log(p instanceof Person); // true
var people = ["Bob", "Will", "Mary", "Alandra"].map(Person);
        // people contains array of Person objects