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.
This chapter takes on the intricacies and process of building up an object. Work I’ve been doing is increasingly based around data structures and crafting systems, so creating this type of a structure for code is becoming increasingly helpful. I feel like as a beginning programmer, it’s a victory to understand how an already existing object or library is structured — such as accessing a bit of data in JavaScript the same way you would click on a cell in a spreadsheet. But when you really get into it, you start defining the data structure that makes logical sense, that you would want. And maybe that’s a literal definition of “architecting” code — thinking of what the structure should be, and bringing it to life. I’ve long loved how code can make your dreams into reality. I always meant visualizations when I said that, but I think it also stands for the beauty of the code structure that you want to build.
Enough philosophizing!
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”.)
Anyway, cool stuff. Very powerful to realize the claim we as programmers have to defining the object structure of what we’re building in JavaScript, and the importance of thinking through code architecture in making these decisions.
(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.)