Introduction to Object-Oriented JavaScript

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Introduction_to_Object-Oriented_JavaScript

by Garbage • 11 years ago

96 62 11 years ago

developer.mozilla.org

hoare2• 11 years ago

Wouldnt the only thing that js need to be fully oo be a proper inheritence? Prototyping has its advantages too though

sup• 11 years ago

That's coming in es6

oldmanjay4• 11 years ago

I know people are crying out for this, but I can only shudder inside at the unholy mudball messes that will result. Inheritance is one of those things we shouldn't let anyone use until they're 40 or so.

hoare2• 11 years ago

im rly in love with typescript right now, looking forward to es6!

cygx• 11 years ago

Inheritance is no fundamental property of OO systems, and JavaScript has always supported it anyway (it just did not provide syntactic sugar).

JavaScript always has been an object-oriented language - arguably just not a partcularly well-designed one, and not a pure one (as not all computation happens through message passing).

kremlin• 11 years ago

This is just in time. I just read a chapter in a JavaScript book about OO programming in JS and finished the chapter very confused. It demonstrated about 12 different patterns people have used for creating 'classes' and 'subclassing' them, each with a list of advantages and disadvantages.

Eg there's the 'parasitic instantiation' and then there's the 'Constructor pattern' and then there's the 'Parasitic Constructor', and there's like 3 other patterns that have their own permutations. Coming from Python and then Java, where classes just work...it's kind of annoying.

[edit] I was being a bit hyperbolic, the book discussed 6 ways of inheritance in JS, those being (1) Prototype Chaining (2) Constructor Stealing (3) Combination Inheritance <- most popular one according to the book (4) Prototypal Inheritance (5) Parasitic Inheritance (6) Parasitic Combination Inheritance <- pattern that is generally the best according to the book

woah• 11 years ago

Inheritance is rarely necessary

ExpiredLink• 11 years ago

But why? JavaScript obviously wasn't made with object-orientation in mind.

stesch• 11 years ago

That's why every framework invents its own kind of OO for it. :-(

Matachines• 11 years ago

JS isn't OOP and it doesn't need to be. Please read this instead:

https://medium.com/javascript-scene/the-two-pillars-of-javas...

erikpukinskis• 11 years ago

If you're trying to say that OOP isn't the central organizing principle of JavaScript, then I 100% agree with you. Lambdas and closures are awesome.

However, JavaScript does have the "new" keyword, and I would argue that constructors are quite central to JavaScript and good idiomatic JavaScript uses them. And it exposes YourConstructor.prototype, which I would argue is also useful.

So I guess maybe you're saying something about the term OOP that I don't understand. Maybe OOP means "everything is an object" to you? Or it means multiple inheritance?

I guess I don't understand the distinction you're trying to draw when you say "not OOP".

EugeneOZ2• 11 years ago

Article of the same author, on the related subject: https://medium.com/javascript-scene/how-to-fix-the-es6-class...

zachrose• 11 years ago

There's a whole depth of abstractions that people imply when they talk about OOP in JavaScript. In my mind they go something like this.

    1) Using object literals for values.
    2) Using object literals with functions.
    3) Using object literals with functions and calling them in contexts (`this`, `bind`, `apply`).
    4) Using the `new` keyword.
    5) Designing objects with inheritance hierarchies or prototype chains.
    6) Designing mutable and stateful objects with indefinite life spans.

I don't understand the arguments that classical-ish inheritance in JS is bad while prototypical inheritance is somehow better. I've worked in codebases that liberally extend objects into different types of objects with long prototype chains, and IMHO they suffered from the same problems that people complain about in classical inheritance: tight coupling, premature/wrong abstractions, gradual violations of open/closed, etc.

Personally, I go through 1-4 liberally and 5 and 6 conservatively. IMHO, complaints about inheritance mechanisms seem to have something in common with the people who talk about the special needs of "large-scale applications". Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are?

NB: It's entirely possible that I haven't run into the kind of complex requirements where liberal inheritance is a good fit. I'd be interested in hearing stories about when that worked out well.

hughw13• 11 years ago

I agree. JS is beautiful in the parts where it encourages functional, not object, programming. That link puts it nicely: "You're working in the phony version of JavaScript that only exists to dress the language up like Java." In the Mozilla article, I can hardly believe I'm reading discredited perennials like "OOP promotes greater flexibility and maintainability in programming ... Because OOP strongly emphasizes modularity, object-oriented code is simpler to develop and easier to understand later on." That was the promise, in 1985. The reality is, OOP has created a snarl of programs where mutable state is the defining characteristic, justified by a consulting industry that is more promotion than real, grounded theory. They live on.

oldmanjay4• 11 years ago

You're vastly overstating what you consider the "reality" of object oriented programming. Systems designed to be OO from the beginning are clearly massively successful at producing incredibly complicated software. The paradigm has not been discredited despite your assertion or your personal idea of beauty.

uname-s2• 11 years ago

The promise in 1985 was Smalltalk; the reality was Java. Your argument rests on an industry bait-and-switch.

Kiro2• 11 years ago

How about games? I feel OOP makes the most sense when coding games. You want mutable objects (for example enemies) behaving the same.

uname-s2• 11 years ago

Smalltalk has always had lambdas in the form of block objects. It uses them everywhere and for everything, even implementing control flow constructs like if/then/else and while. It also uses them to implement Lisp-style higher-order iterators like mapcar (collect:), reduce (inject:into:), and remove-if-not (select:), which though possible in JavaScript (see Prototype.js), is generally uncommon because JavaScript's lambda syntax has historically been the most verbose of any dynamic language.

Anyone who claims lambdas are somehow new to or incompatible with OOP clearly doesn't understand OOP, since lambdas have been an integral part of the most influential pure OO language (Smalltalk) for 40 years.

jwdunne• 11 years ago

I've also seen very simple object systems built purely using closures in Lisp. I can't remember where I've seen it, but it usually involves the bank account example. Since no other Lisp features were involved,until you start glossing over with macros, this could be replicated in JS. It'd look strange but it's certainly possible, e.g:

  var savings = account(200);

  savings('deposit')(200);
  console.log(savings('amount')); // should print 400

  savings('withdraw')(200);
  console.log(savings('amount')); // should print 200

If you can build an OO system in terms of lambdas and closures, does it mean the two are incompatible? I don't think so.

lispm• 11 years ago

Though it does not have lexical scope / closures for 40 years.

Kiro2• 11 years ago

This article needs some code examples. Read it through and still not sure how to do this.

cnp2• 11 years ago

When will people start releasing ES6 editions of things? Seems so old school when you can simply write

`class Foo extends Bar {}`

bkurtz13• 11 years ago

Now you're being old school. It's called ES2015 now! ;)

(edit: app I was using chopped my comment...)

cnp2• 11 years ago

True true, though it's more characters to type :) And is ES7 going to be called ES2016? (Considering how JavaScript is starting to run everything there is a certain long-term logic to this naming approach.)

thomasfoster962• 11 years ago

I'm still worried that the idea of a namespace is still being thrown around in JavaScript. If you've used PHP (which presumably quite a few inexperienced programmers might have before they get into JavaScript), JavaScript namespaces act nothing like PHP namespaces. A JavaScript namespace is just a global variable. Nothing fancy.

bbcbasic• 11 years ago

Or we can set this explicitly using Function#call (or Function#apply), as shown at the end of the example.

Or we can define a variable self in the class, set self = this in the constructor, and refer or that hereon.

Introduction to Object-Oriented JavaScript

Related Stories