Should I use prototype or not?

Question

I\'m creating a Vector class, which can basically hold three numerical values. However, a lot of operations can be done on such a vector - e.g. getting the magnitude, adding

Answer 1

This is exactly the situation for using prototype. I see two main benefits for doing so:

1. Functions are not created multiple times. If you define the functions inside the constructor, a new anonymous function is being created for each function you define, every time the constructor is called. Prototypes are static objects, and each instance of Vector3D will simply reference the prototype functions.
2. The prototype is a single object that can be easily manipulated. This affords great flexibility; unfortunately I'm only able to provide a few examples of what this can offer:
   1. If you wanted to create a child class, for example Vector3DSpecial, you can simply clone Vector3D.prototype and assign this to Vector3DSpecial.prototype. While you can also do this using constructors by Vector3DSpecial.prototype = new Vector3D();, constructors may contain side-effects which will get executed in that simple prototype assignment, and therefore should be avoided. With prototypes, you may even choose only particular functions in the prototype to be copied over to the new class.
   2. Adding methods to Vector3D is simply a matter of adding properties to the prototype, and allows your code to be more easily split / organised into multiple files, or to allow for adding methods in other parts of the code dynamically. Sure, you can do a combination of adding methods in the constructor and via the prototype, but that is inconsistent and is likely to lead to more complexity further down the track.

When would I not use prototype? For singleton objects, for example a controller that interacts with a page and may delegate work off to other objects. A global "notification" object is one such example. Here, extending is unlikely, and the object is only created once, making the prototype an additional (conceptual) complexity.