javascript

Respect Object Ownership
Chapter 20: Best Practices
The dynamic nature of JavaScript means that almost anything can be modified at any point in time. It ’ s
been said that nothing in JavaScript is sacred, as you ’ re unable to mark something as final or constant. In
other languages, objects and classes are immutable when you don ’ t have the actual source code.
JavaScript allows you to modify any object at any time, making it possible to override default behaviors
in unanticipated ways. Because the language doesn ’ t impose limits, it ’ s important and necessary for
developers to do so.
Perhaps the most important programming practice in an enterprise environment is to respect object
ownership, which means that you don ’ t modify objects that don ’ t belong to you. Put simply: if you ’ re
not responsible for the maintenance of an object, its constructor, or its methods, you shouldn ’ t be making
changes to them. More specifically:
❑
❑
❑
Don ’ t add properties to instances or prototypes.
Don ’ t add methods to instances or prototypes.
Don ’ t redefine existing methods.
The problem is that developers assume that the browser environment works in a certain way. Changes to
objects that are used by multiple people mean that errors will occur. If someone expects a function called
stopEvent() to cancel the default behavior for an event, and you change it so it does that and also
attaches other event handlers, it is certain that problems will follow. Other developers are assuming that
the function just does what it did originally, so their usage will be incorrect and possibly harmful
because they don ’ t know the side effects.
These rules apply not only to custom types and objects, but also to native types and objects such as
Object , String , document , window , and so on. The potential issues here are even more perilous
because browser vendors may change these objects in unannounced and unanticipated ways. An
example of this occurred in the popular Prototype JavaScript library, which implemented the
getElementsByClassName() method on the document object, returning an instance of Array that had
also been augmented to include a method called each() . John Resig outlined the sequence of events that
caused the issue on his blog. In his post, he noted that the problem occurred when browsers began to
natively implement getElementsByClassName() , which does not return an Array but rather a
NodeList that doesn ’ t have an each() method. Developers using the Prototype library had gotten used
to writing code such as this:
document.getElementsByClassName(“selected”).each(Element.hide);
Although this code worked fine in browsers that didn ’ t implement getElementsByClassName()
natively, it caused an error in the ones that did, as a result of the return value differences. You cannot
anticipate how browser vendors will change native objects in the future, so modifying them in any way
can lead to issues down the road when your implementation clashes with theirs.
The best approach, therefore, is to never modify objects you don ’ t own. You can still create new
functionality for objects by doing the following:
❑
❑
Create a new object with the functionality you need, and let it interact with the object of interest.
Create a custom type that inherits from the type you want to modify. You can then modify the
custom type with the additional functionality.
643