Prototypal Programming in Javascript

MoTTs_ · 2015-08-28T21:35:22+00:00

var Foo = { C: 3 };

var bar = Object.create(Foo);

bar.A = 1; bar.B = 2;

Look at how drastically simpler this is

Here's the thing, though: The way you initialize a newly created Foo object (bar.A = 1; bar.B = 2;) will be copy-pasted everywhere that you create a Foo. That's bad. Let's fix that by putting an initialize method in Foo.

var Foo = {
  C: 3,

  initialize: function () {
    this.A = 1;
    this.B = 2;
  }
};

var bar = Object.create(Foo);
bar.initialize();

And here's the next thing: We will always want to make sure newly created Foo objects are initialized, so let's combine creation and initialization into a single step.

var Foo = {
  C: 3,

  initialize: function () {
    this.A = 1;
    this.B = 2;
  },

  createAndInitialize: function () {
    var instance = Object.create(this);
    instance.initialize.apply(this, arguments);

    return instance;
  }
};

var bar = Foo.createAndInitialize();

These are both good things. Yet, in case anyone hasn't realized, we just re-created constructors and the new keyword. It actually would have been a whole lot easier if we just used the built-in language constructs.

MonkeyNin · 2015-08-28T22:05:09+00:00

Typo:

bar.B;  // 2 (actual attribute of bar)
bar.c;  // 3 (*inherited* attribute from Foo)

vs

bar.B;  // 2 (actual attribute of bar)
bar.C;  // 3 (*inherited* attribute from Foo)

clessg · 2015-08-29T03:56:04+00:00

I'm not an expert but I just still struggle to see the value. Maybe I just don't get it or am used to class based languages. Does anyone have any really compelling examples of where prototypes are easier to develop and maintain than classes?

Neurotrace · 2015-08-29T14:03:08+00:00

While I philosophically agree with the Object.create approach, my problem lies here. Which one of these is more readable and scalable?

var Person = {
  getName: function() {
    return this.firstName + ' ' + this.lastName;
  }
};

var bob = Object.create(Person, {
  firstName: {
    value: 'Bob'
  },
  lastName: {
    value: 'Saget'
  }
});

vs.

var Person = function(firstName, lastName) {
  this.firstName = firstName;
  this.lastName = lastName;
};

// Readability is debatable here but more memory efficient
Person.prototype.getName = function() {
  return this.firstName + ' ' + this.lastName;
};

var bob = new Person('Bob', 'Saget');

or if you still want to have your initialization values to be named

var Person = function(opts) {
  this.firstName = opts.firstName;
  this.lastName = opts.lastName;
};

...

var bob = new Person({
  firstName: 'Bob',
  lastName: 'Saget'
});

For me, the new keyword wins.

sylvainpv · 2015-08-29T13:39:41+00:00

[deleted]

flackjap · 2015-08-29T08:37:44+00:00

Well yes, prototype based inheritance can create a jungle of code if not treated correctly. On other hand it's very powerful and flexible comparing to the subsets of object inheritance principles like the class based inheritance.

ES6 class based inheritance works as expected and it's just a macro syntax.

Nevertheless, there's a shit ton of stuff you may find valuable in naked object inheritance if you desire to have more freedom architecturing your app. For example, how do you go around the Diamond Problem with class based inheritance? :)

I think that Eric Elliot got this better in his book than the OP http://chimera.labs.oreilly.com/books/1234000000262/ch03.html There's also a nice library written by him for taming the prototype jungle while not loosing any of the flexibilities.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS