My OOP JavaScript question is at the very bottom if you want to skip my introduction.
In an answer to the question Accessing variables from other functions without using global variables, there’s a comment about OOP that says:
If there’s a chance that you will reuse this code, then I would
probably make the effort to go with an object-oriented perspective.
Using the global namespace can be dangerous — you run the risk of
hard to find bugs due to variable names that get reused. Typically I
start by using an object-oriented approach for anything more than a
simple callback so that I don’t have to do the re-write thing. Any
time that you have a group of related functions in javascript, I
think, it’s a candidate for an object-oriented approach.
That rings true to me from what I’ve seen some of my old OOP colleague. There are lots of different approaches and different voices leading in different directions. Since I am a front end developer and UI designer, I am a little confused.
Building up to the question
I’ve heard from a variety of places that global variables are inherently nasty and evil, when doing some non-object oriented Javascript, and that there are three choices available to make a variable from one function, visible and usable by another function, e.g., function A to be visible to function B; or, a variable of Function A to be passed and usable within function B.
- make it a global
- make it an object property, or
- pass it as a parameter when calling B from A.
I’ve read about namespaces, currying, and other approaches…
Question:
With that all said, I was wondering what’s the best OOP structure or best code practice in JavaScript that keeps things encapsulated and adds greatest security from having your variables exposed to manipulation?
0
Take a look at Douglas Crockford’s article on private members in JavaScript. To hide variables, your only real option is to create a closure in which they’re scoped. For example, in a browser:
;(function() {
// secret is only visible to definitions inside this function
var secret = "secret";
// secretWrapper's functions "close over" secret so they retain
// access even after this enclosing function executes.
window.secretWrapper = {
getSecret: function() {
return secret;
},
setSecret: function(val) {
secret = val;
}
};
})();
Avoiding global namespace pollution is a noble goal, but ultimately your code needs to be attached to something, either the global object (window in the browser) or a DOM object (which is attached to the global object).
Remember that this doesn’t make your code more secure or free from manipulation. In the browser, anyone can overwrite your implementations whenever they feel like it. It can make your code more maintainable, however. It allows you to break a problem into pieces that only need be aware of their smaller responsibility.
2
You can only do so much with JavaScript
No matter what framework you use, JavaScript simply does not have a method to mark properties of a user-defined object as protected or hidden. If a function can get a reference to your object, that function can change any part of that object.
So do the best with what you have.
If you want to protect against cross-function manipulation, either pass lightweight objects as parameters or spool one up before you release your exclusive lock.
If you want to have anything in JS be secure, put it on the other side of the HTTP call. (And if you’re making a client-side-only app, put your secure code outside of your javascript object.)
If you want to protect against accidental over-use (which is why globals are evil), pick a framework or write your own, and follow it religiously.
Some advice on doing that
- Write anything not trivial as an object. That is, if it’s more than two lines of code, it should be an method of some custom object on the global namespace (or a child thereof.)
- Non-trivial event handlers should call methods of objects instead of doing the work themselves. (More than two statements is likely “non-trivial.”)
- Methods should ONLY affect their own object’s properties and their parameters.
- When possible, avoid having the methods of an Objects do more than call that object’s other methods, that object’s parent’s methods, or that object’s children’s methods.
- Seriously, pick a framework.
jQueryis just one answer, and for OOP isn’t as snazzy as eitherprototypeorenyo - OOP’s real benefit to JS isn’t encapsulation. It’s testability. When picking a framework, lean towards one that includes a good test harness for your new code. (Or, heck, write one yourself. They’re not THAT hard.)