CODEWITHSUNDEEP
javascriptoopsyntaxprototype
fizzydrinks
fizzydrinks

Reputation: 634

Using "this.prototype" vs outer "Constructor.prototype" in OOP

In JavaScript, defining a classlike (constructor) function method is usually done like this:

function Class1() {
   // ... code ...
}
Class1.prototype.method1 = function(args) {
   // ... code ...
};

And going by the general syntax/semantics rules of ECMAScript, there is no reason I couldn't override/alter/extend the original Object.prototype with

function Class1() {
   // ... code ...
   this.prototype.method1 = function(args) {
      // ... code ...
   };
}

Then why is it not done that way? Code would look a bit more confusing, but a lot quicker and cleaner to write and read (putting all Class1-related methods right underneath Class1 itself). Wouldn't it be a better use?

Upvotes: 2

Views: 633

Answers (4)

LetterEh
LetterEh

Reputation: 26696

Even if you fix the code, to point to the correct this, prototypical properties are added to each instance, when they're created.

But they're added by sharing the same copy of the method/property.

If it wasn't called prototype: if it was called "Bob" and copied by hand, it would make more sense:

var Bob = {
    name : "Bob",
    sayName: function ( ) {
         var person = this;
         console.log( "My name is " + person.name );
    }
};



 var Person = function (name) {
    var person = this;
    person.name = name || Bob.name;
    person.sayName = Bob.sayName;
 };


var doug = new Person("Doug"),
    jim  = new Person("Jim");

There are a couple of things going on behind the scenes, regularly, but there really isn't much difference here, between Bob and what would normally be Person.prototype.

But you can clearly see why you wouldn't want to reset Bob.name, every single time you make a new person.

Upvotes: 1

Mehran Hatami
Mehran Hatami

Reputation: 12961

As the other answers have pointed out, the second use of prototype is not a valid javascript code, but it seems you want to have access to your constructor when it is actually running, which is possible with these 2 options:

1- if you don't use strict mode, you can have it like:

  var MyClass = function ClassConstructor(){
         arguments.callee.prototype. ...
  }

2- in strict mode for instance if you have your classlike function like:

var MyClass = function ClassConstructor(){
        ClassConstructor.prototype. ...
 }

this way you can use ClassConstructor only in the constructor, it is kind of private there.

Upvotes: 1

Pointy
Pointy

Reputation: 413720

Those two pieces of code are most definitely not the same; the second one won't work.

What happens in the constructor (usually) has nothing to do with the prototype object. It's initialization code for each instance. The "prototype" property of interest is the "prototype" property of the constructor function, not of the instances.

Creating prototype functions inside the constructor doesn't make sense, because it'd mean you'd be re-doing that work for each instance you create.

Upvotes: 2

Tyler McGinnis
Tyler McGinnis

Reputation: 35276

The problem is those two code samples are not equivalent. In the first example 'this' refers to Class1, but in the second example 'this' refers to whatever that newly created object was. For example, 

var myObj = new Class1()

in the example above, 'this' is myObj - which breaks your second example.

Also, even if that did work, you would be then recreating that method for every instance you made. It would be much more efficient to not do that.

Upvotes: 2

Related Questions