Several months ago (sometime in the fall), I was logging some notes and thoughts on the JS Design Patterns book, as we work our way through selected portions in a small group at work. It’s been a while, but for this week, we took on some material that I thought might be interesting to share.
The chapter reminds us of the power of namespacing. Unlike a spreadsheet, where each column is of equal weight to another column, when we create objects, we can separate out data at different levels. Certain types of information belong together, and can be sorted as such. Sort of like how you can spend a lot of times organizing file folders, on your computer or you know, actual folders. But as the book explains, create too much structure and the names start to get long. In other words, you won’t know where to find what you’re looking for. But some organization makes it clearer why certain bits of data are different from one another.
When explaining this concept, I liked the introduction of the word “nondestructive”. It’s when you create something ONLY if it doesn’t already exist. You might want to do this if you want o put a bit of data in an object. You would want to create that object if it doesn’t already exist. But if it does exist, and already has something in it, you wouldn’t want to overwrite it with an empty folder. This is a convention I have seen around, and used countless times, but didn’t yet have a word to put to it. (So much of the utility of these books is putting words to things I’ve been trying, or seeing techniques that would have made life so much easier.)
I had thought all methods or properties attached to an object were public. And the book says they are, but you can force them to be private with a closure — that is, by referencing them as private variables within a function, but not attaching them directly to the overall object scope.
The chapter goes on to talk a lot about modules vs. constructors, the role of the prototype, etc. Rather than trying to re-explain it all, I thought I’d give an example of an interesting case in which I used these concepts. In writing some code, I thought I would need to load some data once, so I wrote a separate file that loaded the data, treating it just as a module — basically a collection of functions that could be called. Later, it became apparent that I would need two instances of that module, maintaining separate options or information, which was not compatible with the module. By turning that module into a constructor, so that separate instances could be created, and attaching all relevant functions to the prototype (a part of the constructor that is attached to each instance), I could use the same methods over and over, but have separate options stored on each instance of the constructor. And while a constructor is a giant function, we learned in past chapters that a function is actually just a giant object.
(I think I recently figured out that part of “object-oriented” means the structures related to a language are all types of an object. Put that in the category of “amazing discoveries from an intermediate programmer that actually aren’t amazing”.)
(This may make sense to very few people besides me. I’m still learning how to articulate these complex concepts, but I think it does help to try to write it out. And maybe it’s helpful to one other person on the Internet. Then, totally worth it.)