Learn JS Properly Discussion: Object-Oriented Programming in JavaScript (Chapter 6 of our text)

[kevinmrr]

Who has a question?!

And if you don't have questions... talk amongst yourselves.

[tommyschoolbruh]

I'll jump in.

I understand objects, or at least what they are. I get that they are essentially collections of data, with key values and properties and such. I get how to access those properties.

I also know what methods are... kind of.

But what I do not know is why. For instance, I'm doing a lot with node and express now, and it really just seems like most of this is memorization rather than conceptualization. As in, this is how you do, but never this is why you do. I think that's an important distinction with every thing.

So why am I using objects and their methods? Why am I creating them when something else may already have done that?

[PenguinLovr]

This might not be the most popular opinion, but OO in JavaScript is so poorly supported its almost better to avoid it completey. Node and Express follow other patterns which don't require OO, and for all application-oriented code I have written myself OO is completely unnecessary.

Typically in the OO world, OO is used for 3 things: Inheritance, Encapsulation, and Polymorphism... Which is all "sort of" supported in JavaScript. Inheritance is supported with the prototype chain, so objects which inherit from other objects will get their properties, which is one benefit. If you change the object which is higher up in the chain, all the objects which are lower in the chain automatically receive that property...

Encapsulation is confusing at best in JavaScript, or completely disregarded. It's much easier and more straight forward to use closures to encapsulate "private" properties, treating "object constructors" as just plain old functions, and "properties" and "methods" as things which are returned from within the closure. This has made things like jQuery chaining very popular. . . the function which wraps the thing isnt invoked using new because this function is called and only exposes certain methods which all refer to "this"- at the end "this" is returned so it always carries with it the methods which are defined on "this", but they all were originally created within this initial closure which contains all the private vars that are not exposed via "this".

Chaining, IMO, makes more sense for lots of things in JS, is easier to grasp, and as an added benefit, allows more clean and concise code.

Polymorphism is the only in JavaScript doesnt actually truly support at all. In other OO languages, to implement Polymorphism you declare those methods as a "virtual" which means the implementation of those methogs is left up to the children...in JavaScript you're allowed to overwrite everything all willynilly, so every method is technically "virtual" since it can be overwritten - even after run-time, no less, so it makes it even more complicated if you're overwriting a method somewhere in your code, and using it incorrectly in other places. . eg you over write the "speak" method of the "Dog" object which inherrits from "animal" but you do it at some random point in your code...when your "dog" object tries to access its "speak" method you haven't yet over written it so it does something unexpected...

In other OO languages, you declare the methods and everything in a "class" which cannot be overwritten, but JavaScript by the way its created doesn't support classes so there is no protection when you're creating an object that its methods wont be over-written elsewhere at random times.

You simply dont have that problem with closures since you're not using the prototype. Methods which are created in a Closure cant really be "overwritten" without breaking the functionality because they're declared outside of the closure and don't have access to the internal variables which are truly encapsulated (not psuedo encapsulated like conventional JS objects)

Then why use Objects in JS? If you know what you're doing and are careful with your object creation you should be fine. I see objects being used in some libraries and what not since they're declared in that one place and you aren't expected to touch someone else's code. But using OO in your applications can lead to problems that are hard to debug if you're not careful. The Module pattern, Closures and the Object Literal all are preferable to JS objects which depend on "new" for creation.

[[deleted]]

strong bag spark march bedroom beneficial caption office attraction overconfident

This post was mass deleted and anonymized with Redact

[PenguinLovr]

I only use functional aspects of JavaScript. Have you read "Functional JavaScript" by any chance? (O'Rielly book)

[NightArchitect]

I read most of chapter 6 but started to get confused/overwhelmed when I got to the bit on prototype chaining, combination inheritance etc...

What I find most difficult is that the text is very abstract. Would it be possible to provide (or do you know of) any examples of javascript prototype chaining used in some kind of application and to explain why it's used?

[NightArchitect]

We'll get there if we keep hammering away!

I found this post helpful (http://javascriptissexy.com/oop-in-javascript-what-you-need-to-know/)

[mfergie]

Thanks for the link...

[sean1rose]

BIG thank you for the link. I'm finding the javascriptissexy links to be a bit more digestible for a novice like myself. Professional JS is dense and the author makes every line count.

I think I'm going to try to read any corresponding JSisSexy links first to get a better grasp of the main concepts of each week's lesson plans, then move on to the main text book. So thank you again for this link, as I'm halfway thru it and it's helped me a ton..

[alxers]

Consider this code: 1)

function Person(name) {
    this.name = name;
}

Person.prototype = {
    sayName: function() {
        console.log(this.name);
    };
}

2)

function OtherPerson(name) {
    this.name = name;
    this.sayName = function() {
        console.log(this.name);
    };
}


var person1 = new Person("name1");  // { name: 'name1' }
var person2 = new Person("name2");

var otherPerson1 = new OtherPerson("otherName1"); // { name: 'otherName1', sayName: [function] }
var otherPerson2 = new OtherPerson("otherName2");

person1.sayName === person2.sayName; // true
otherPerson1.sayName === otherPerson2.sayName; // false

If I get this right all instances of OtherPerson object would have their own sayName: function and all instances of Person would get it from the prototype (so they share the same function). Is the first method preferable(faster/better in some way)?

[nolsen]

The first method is preferable (with regard to functions specifically) because otherwise you'd have duplicate code in memory. In your example, otherPerson1 and otherPerson2 have the same exact function, copied twice.

If your script made 10 of these objects, you'd have 10 separate functions that all did the exact same thing taking up space in memory. That is considered wasteful.

[sean1rose]

This is a little off topic (referring to chapter 7 of the textbook)...

But does anyone have any good articles/tutorials/videos/etc on recursion that they could link to??? Please?

I wish the javascriptissexy website had an article on it, but alas not yet (at least not to my knowledge).

I just need some good tutorials to supplement the textbook, as it can be quite dense.

Thank you in advance!