Take the 2-minute tour ×

It seems that when using Javascript's Prototypal Inheritance, we would still typically do this, say, if it is programming a game of Mario Kart:

        |   |---Yoshi
        |   |---Mario
        |   |---ShyGuy

so the GameObject might have a 3D coordinate of where it is in the GameWorld, and a 3D model of points and surfaces to draw on the screen, and so forth.

So we have this generic object first, and then we inherit more generic objects based on it, in this case, the KartDriver and the WeaponObject.

And even Yoshi might be a generic object, that if there are 8 players and 2 of them chose the same character (in an online race), then there will be 2 Yoshi objects, and Yoshi also became a generic object.

Or even the GameWorld object, might seem it is a concrete and unique object, but if the server hosts 30 races at the same time (with each race usually 5 to 8 people), there in fact there will be 30 GameWorld objects.

But on a 3DS console, the GameWorld would be just 1 object, so in this case it is not a generic object, or maybe we can say it is a generic object, but there will be a singleton object based on it.

Is it true that the typical Javascript Prototypal Inheritance pattern will usually be like this? It might be extremely rare that it is purely based on "concrete object" inheritance? If there are such usage, what might be the situation that a Javascript purely uses "concrete objects" and have no "generic objects"?

Update: I ask this question because Prototypal Inheritance typically is said to be "classless" and object-based. But it also seems that we'd create generic objects first, for the concrete objects to be based on, so this "generic object", in a way, also feel like a "class". That is, even if we don't write code to make Javascript's inheritance to become a classical inheritance structure (class-based), and purely just use prototypal inheritance (object-based), we would still more often than not, use "generic objects" which do look like classes.

Update 2: if we see a class as a "blueprint" of how an object is constructed, in classical OOP, then this generic object method also involves blueprints for objects, but just that it is more dynamic and not static like Objective-C. For example, we can dynamically add a property to KartDriver object and now all Yoshis and Marios will inherit from it. So looking at this blueprint design, it in fact is "class" and not "classless". Just that this is dynamic class, while the classical OOP is static class.

share|improve this question

closed as not a real question by Pointy, Barmar, Dan, Andro Selva, Yan Berk Oct 1 '12 at 5:29


This question doesn't make a lot of sense. –  Pointy Oct 1 '12 at 3:40
It does. No offense, but this question doesn't deserve a downvote –  SReject Oct 1 '12 at 3:45
I thought this looks at OOP and Prototypal Inheritance in a real life programming situation –  動靜能量 Oct 1 '12 at 3:46
I can't believe asking an OOP question on Javascript can be closed –  動靜能量 Oct 1 '12 at 10:03
add comment

2 Answers

Javascript doesn't have classing or inherintence, it has prototyping and scope. As a general rule of thumb, prototyping is used if

1: The object is used more than once, and 2: If the code to prototype is shorter than just hardcoding/creating such objects

share|improve this answer
add comment

I wouldn't say that's correct.
Realistically, yes, you're probably creating objects and structures which your game objects either reference or are passed to...

...but if you're making a BananaPeel, which inherits from Weapon, which inherits from WorldObject, which inherits from GenericObject, then you might be JSing wrong.

That would be a LOT of effort put into making pretty useless workarounds to get inheritance to work in a way you think would be ideal...

Moreover, that would create a LOT of objects/methods which are easily modified by end-users.

While nothing is cheat-proof and no system is hack-proof, conversely, having public properties such that you can just open the Chrome dev console and say myBlueShell.radius = 4000; myBueShell.damage = 4000; or something similar... ...that ends very poorly.

We're never going to reach a point where we no longer need helper-methods or convenience objects... In fact, the point is that the engines are being optimized so that we can run more abstract code, rather than less.

...but unlike a Java or C# or C++, JS doesn't require you to extend things with other things, ad nauseum. Nor do coding conventions demand it.

If you want to borrow a property or a method from something else, you just take it.

Functions are first-class, and they can be passed around and reassigned, and aren't stuck being a method of a particular class.

While technically you can subclass until you're blue in the face, if you really want to endure that headache (like figuring out super-classes and multiple-inheritance), you're also entirely free to use functional programming, or to do component-based engines, leaning heavily on dependency injection, to limit the number of inheritance dependencies and to take advantage of more modular, more flexible designs.

share|improve this answer
do you mean for Yoshi and Mario, you won't base them on a single KartDriver object then, but just have 2 totally "unrelated" types of objects, one Yoshi, and one Mario object? –  動靜能量 Oct 1 '12 at 4:19
Not necessarily. Instead, I might make a factory, which creates a drawable module, a physical module, an inventory module, a controllable module and puts them all together. My drivers would be component-based, plus a basic instantiation of things specific to a particular driver (the reference to the mesh/textures/sounds for that particular driver). That's not to say that subclassing is inherently evil -- but I'd say that all things considered, it's a bit unnecessary. –  Norguard Oct 1 '12 at 4:26
but I think programming itself, for the overall design, might not be concerned with users cheating to begin with... we have so many other things to consider, code reuse, encapsulation, DRY, etc. If anything, the user can always use cheat engine or something like that to check when he has a blue shell and when he has not, and change that 1 byte to make him have blue shell all the time... so there might be other ways to prevent cheating, and it may not change our style of writing programs completely –  動靜能量 Oct 1 '12 at 4:29
Okay, DRY as an example -- which is less work: constantly overriding virtual/super methods (or implementing interfaces), or setting a variable/object property to point at a function (or passing a function to a method) or the like? In terms of reuse, writing a module, and then putting that module inside of tons of different classes, is more reusable than trying to figure out how to extend a jet from a tank from a truck from a bike from a wheel... Bit of an exaggeration, but at the same time, not really, in poorly-written class-based code. –  Norguard Oct 1 '12 at 4:33
playerX = new Player(new Controllable(), new Position(), new Drawable()); playerY = new Player(new Controllable(), new Position(), new Drawable()); updatePosition(playerX.position); updatePosition(playerY.position); drawPlayer(playerX.drawable); drawPlayer(playerY.drawable); seems more compact to me. –  Norguard Oct 1 '12 at 4:36
show 2 more comments
