How to improve the structure of my JavaScript to make better use of OOP

Question

I'm currently working on a JavaScript project that's a little larger than what I'm used to. In the past I've made the odd carousel and basic visual things.

This time round I'm working on a project that's more or less making a file management solution in the browser.

My first bit of code is to allow users to select single and multiple files using keyboard commands (arrows and shift) and mouse (click and shift click)

I've used a design pattern that I've learnt observing colleagues code on another project but I'm unhappy with the amount of code required to call functions and global (to the object) variables, for instance:

SW.selection.addItemsToSelection($(this))

or

SW.selection.vars.$selectedItems

You can see the full code on JSFiddle here

My questions are:

(a) Is there a better structure I could use to organise this code more efficiently.

and

(b) I only have the vaguest understanding of OOP as I struggle to apply it to real world problems - how would this code best be structured following the OOP methodology given its a fragment of what will be a large JS application.

I hope these aren't too vague! This is something I really struggle to understand but I'd like to improve my JavaScript a lot so taking the rare step of posting here.

Answer 1

You can replace SW.selection with this in most places, if you are in the object scope.

The design pattern looks like a "singleton" (or it’s equivalent in JavaScript: Object), so there is no need for fancy OOP stuff like inheritance etc. One thing you might consider is the possibility to have private vars in your singleton:

SW.selection = (function() {
    var private = 'I’m private';
    return {
        public: function() {
            return private;
        }
    }
}());

SW.selection.public(); // returns 'I’m private', 
                       // but the private variable is not accessible from here

This way, you can store the vars in the private scope so you don’t need to access them via the entire singleton each time using SW.selection.vars.myvar etc.

Answer 2

I don't think there's anything wrong with your example calls, but I'll mention another benefit to the singleton pattern: local name scoping. I'll give a real-world example: if I'm working with google maps, and I get tired of referring to google.maps.LatLng everywhere, I can shorten it within my module scope.

MyApp.MyModule = (function(MM, g) {

  MM.doSomething = function() {
    // here's a function that makes extensive use of google.maps
    // but I can use "g"
    var ll = new g.LatLng(-1, -1);
    var map = new g.Map();
  }

  return MM;
})(MyApp.MyModule || {}, google.maps);

Note that I'm using the same trick to shorten the name of my own module, as well. Other modules would call MyApp.MyModule.doSomething(), if they are accessing my method through the global scope, but I can refer to my own variables and methods as MM.doSomething().