Please! A real-world application using custom objects in JavaScript.

March 18, 2013 2:18 PM

Coding books give silly examples, like dogs with properties like "breed" and methods like "bark." Can you give me a practical example that includes properties and at least one method—an example that someone would actually use on a real website?
posted by markcmyers to Technology (5 answers total)

Best answer: If you were writing e.g. a two-dimensional game, you might want to have objects representing points/vectors and implement vector addition and scalar multiplication.

function Vector (x, y) {
    this.x = x;
    this.y = y;
}

// Add two vectors together.
Vector.prototype.add = function (other) {
    return new Vector (this.x + other.x, this.y + other.y);
}

// Multiply a vector by a scalar value.
Vector.prototype.scale = function (scalar) {
    return new Vector (this.x * scalar, this.y * scalar);
}

var a = new Vector(1, 1);
var b = new Vector(2, 2);
console.log(a.add(b)); // {x: 3, y: 3, ...}

var c = new Vector(1, 2);
console.log(c.scale(6)); // {x: 6, y: 12, ...}

(jsfiddle)

Another, more abstract example is "iterables" -- things that have a `next` method, that returns a value, and some hidden internal state. So you might have

function Counter () {
    this._number = 0;
};
Counter.prototype.next = function () {
    return this._number++;
};

var c = new Counter();
console.log(c.next()); // "0"
console.log(c.next()); // "1"
console.log(c.next()); // "2"

(jsfiddle)

(In fact, there will be some syntactic sugar to use things like this with the `for` keyword in the next specification for javascript.)
posted by wayland at 2:56 PM on March 18, 2013

Best answer: Anyway, the basic purpose of objects is to store data that would otherwise need to be shuffled around independently. Objects aren't magic and they don't let you do anything you wouldn't otherwise be able to do; they're just a nice way to structure code.

A nice consequence of attaching methods to kinds of objects is that we could have some other iterable that does something completely different from `Counter` when you call `next`, but we could use the same code to interact with it. E.g., we could write this `Alternator` thing that takes two iterables and makes an iterable alternating between the two:

function Alternator(a, b) {
    this._a = a;
    this._b = b;
    this._use_a = true;
}

Alternator.prototype.next = function () {
    if (this._use_a) {
        this._use_a = false;
        return this._a.next();
    } else {
        this._use_a = true;
        return this._b.next();
    };
}

var alt = new Alternator(new Counter(), new Counter());
console.log(alt.next()); // "0"
console.log(alt.next()); // "0"
console.log(alt.next()); // "1"
console.log(alt.next()); // "1"

(jsfiddle)

This doesn't just work with `Counter`, it works with literally anything that has a method `next`.
posted by wayland at 3:18 PM on March 18, 2013

When Javascript tries to be "object-oriented" it gets confusing because

a) it isn't, really
and
b) you run up against the weirdness of the fact that you're almost always dealing with things on the screen in a browser which aren't really "in" the code, if that makes sense.

The above examples are great, I just wanted to add that I've been doing js for years and years and I just recently created my first classes (which is what I think you're asking about here: JS classes are just objects, but not all objects get used as classes. Like I said, it's confusing.)

Anyway, since I don't code games, all I use them for is when I have a "library" that keeps track of, for example, all the pop-up windows currently open. I keep a bunch of instances of "new PopUp" stuffed in an array where I can look at them and adjust their properties. (This kind of thing is often handled by just cramming info into data attributes directly on the html, but for advanced stuff I like to move it over to the "code" side.)
posted by drjimmy11 at 4:01 PM on March 18, 2013

(I should add that each "PopUp" object has to have a corresponding view that is the actual html on the screen, and they're not linked except by sharing an id or whatever. That's why it's weird; you're always trying to "connect" code to layout html which is sitting in the browser, as opposed to a more conventional environment where the view is the same sort of code.)
posted by drjimmy11 at 4:03 PM on March 18, 2013

Best answer: Objects are just a technique for data-encapsulation and code-reuse. OOP tutorials like to imply that objects will correspond to discrete things with obvious boundaries, and one of the ways they imply this is by using examples that correspond to physical things. But the truth is not only that objects are abstractions, but that they usually also represent abstractions.

In simulations, you'll have objects that correspond to real things. In, say, blog software, you'll have some objects that correspond obviously to discrete things -- Users, Entries, Comments. But you'll also be dealing with things like Parser objects and View objects, and other abstractions just because they were sensible (one hopes) ways to organize the data and code for responsible encapsulation and convenient reuse (or not -- a lot of things will never be subclassed.)

The benefits are OOP are more opaque in those examples, so they're not discussed in beginners' tutorials.

I haven't done anything significant in Javascript, so I can't help with a specific example; I just hoped to shed some light on why so many of the tutorials seem to have so little to do with real-world programming.
posted by Zed at 12:59 PM on March 19, 2013