1

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.

  1. make it a global
  2. make it an object property, or
  3. 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?

Community
  • 1

2 Answers2

3

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.

Corbin March
  • 8,124
  • Just like many other languages that have explicit access modifiers, the protection isn't from use, but more to deter inadvertent misuse.
    • – JustinC Jun 23 '13 at 17:55
  • 1
    If the goal is to only deter inadvertent misuse then for non-singletons this pattern has many downsides. If the answer above wasn't exporting a singleton but a constructor instead, creating an instance of that would also create instances for every function defined as a method too - with a single method usually taking more memory than the object and its data itself. Then you will also not be able to benefit from inlining optimizations, generic methods and inheritance. It's all around horrible pattern for deterring inadvertent misuse which can be accomplished with underscore prefixing. – Esailija Jun 24 '13 at 15:15