HTML and CSS Reference
In-Depth Information
if (observers[i] == observer) {
return true;
}
}
return false;
}
function notify(event) {
var observers = _observers(this, event);
var args = Array.prototype.slice.call(arguments, 1);
for(vari=0,l=observers.length; i < l; i++) {
try {
observers[i].apply(this, args);
} catch (e) {}
}
}
tddjs.namespace("util").observable = {
observe: observe,
hasObserver: hasObserver,
notify: notify
};
}());
Changing the entire implementation in one go is a bit of a leap, but given the
small size of the interface, we took a chance, and according to the tests, we succeeded.
If you are uncomfortable making such a big change in one go, you can take
smaller steps. The clue to performing structural refactorings like this in small steps
is to build the new functionality side-by-side with the old and remove the old one
first when the new one is complete.
To make the change we just made using smaller steps, you could introduce
the object backend using another name and add observers both to this and the old
array. Then, you could update
notify
to use the new object, passing the last test we
added. From there you could write more tests, e.g., for
hasObserver
, and switch
over from the array to the object piece by piece. When all the methods were using
the object, you could remove the array and possibly rename the object. The internal
helper function we added could be the result of refactoring away duplication.
As an exercise, I encourage you to improve the test case—find edge cases
and weak points, document them in tests and if you find problems, update the
implementation.
