Why use public methods in JavaScript objects? [duplicate]

Question

I'm part of a small study group at work that's trying to get a better grasp on what makes JavaScript tick. In our recent discussions about objects, we've learned that an object's public methods are recreated each time an object is instantiated, while methods assigned to the object's prototype are only created once and inherited by all instances. From what I understand, both public methods and those assigned to the prototype are publicly accessible.

The question I have, then, is why bother creating public methods at all if adding to the prototype is apparently more efficient? What benefit does the public method provide that the prototype doesn't?

Dyslogistic

Prototype addition to the object creates the same method for other objects of same class (in this case a function) to be added. for instance if i have var name = new Student() and I added a prototype to name it would be accessible to var name2 = new Student() as well – Heindrick

@AkshayKhandelwal Assuming the OP means doing this.GetName = function() { ... } inside the constructor of Student, you can access that from both too, however it's "recreated each time". – Insistence

Another similar question: Advantages of using prototype, vs defining methods straight in the constructor? – Filomena

@Pablo Nope. I disagree. This is not a duplicate. It definitely makes sense since the difference that he's pointing out is creation of the public methods again. – Heindrick

@AkshayKhandelwal He is pointing that public methods are recreated every time you instance a new object. Last 2 lines of the question are the key here – Filomena

@Pablo, I think the second question you provided is in line with what I want to know. This bums me out because I always search StackOverflow before posting-- I try not to duplicate! Thanks for pointing me to both and I'll read them thoroughly. – Dyslogistic

Answer 1

Answering this specifically:

What benefit does the public method provide that the prototype doesn't?

A method added within the constructor has access to private information, eg:

function Student() {
    var name = 'Bob';
    this.GetName = function() {
        return name;
    }
}

Student.prototype.SomeOtherPublicMethod = function() {
    //no access to name
}

Insistence

This makes sense, @James Thorpe. – Dyslogistic

Unless you wrap the "class" into a self-executing function and move private methods and fields out of the constructor. – Nonparticipation

@Nonparticipation I'd be interested to see how you construct such a thing, where the prototype methods have access to the private variables, but each instance of the object has it's own data. (genuinely, no sarcasm...!) – Insistence

@JamesThorpe Disregard my comment, I did not pay complete attention to the details. But now I'm intrigued and will try to do it! – Nonparticipation

These "public" methods that are added to the object (not the prototype) are sometimes called privileged methods, because they can access the "private" members. Not being able to access "private" member from functions on the prototype is somewhat disappointing when coming from one of the big oop languages like C#, Java etc. – Firdausi

@null, is there a difference between privileged and public methods within a constructor then? I watched an explanatory video that seemed to indicate that it's possible to add public, privileged, and private to an object's constructor. Is a public method simply one that doesn't access private members? And if this the case, I don't understand the need for both public and privileged. – Dyslogistic

@Dyslogistic if you want to call them privileged, then no - there's no difference between that and a public method defined in the constructor. What makes them "privileged" is the fact that they can access the innards, not that they do. – Insistence

@Dyslogistic no, it's just a name that's commonly used to refer to them. You are too much trying to force those keywords onto a language that doesn't have them. The keywords "private" and "public" (and "privileged") were given to you because you are probably familiar with them, but they don't exist in JS. They allow you to get started, but for deeper understanding, think about the core principles of JS such as function scope, closures/iifes, etc. which are the true reasons why the things are the way they are. This is a healthier base for knowledge than keywords of some other language. – Firdausi

So if it was this.name='Bob'; would the prototype be able to access it? So var is like private and this. is like public? Kind of? – Tericaterina

@Phil_1984_ Yes that would make it accessible, and yeah you could say that's the difference between public and private also - just that things need to be public in order for the prototype to be able to see them too – Insistence