This entry is part 3 of 11 in the series SOOJS : OO JavaScript

At its heart, obviously, SOOJS is about bringing some kind of object-orientation to JavaScript. That’s not to say it makes JavaScript itself OO, nor that any of the common OO elements are specifically replicated. There is actually a lot of overhead in doing that sort of thing, and it really bends JavaScript in a way that isn’t helpful and certainly less efficient.

Rather than attempt to recreate, say, Java’s OO paradigms SOOJS simply brings the concept of classes and scope into the discussion. There are implementations of deep OO concepts out there, and if you have a true need for something like multiple inheritance you won’t find it here. However, as we have seen, one of the guiding principles of SOOJS is to allow any other paradigm or pattern to be implemented as well. So, what you learn here will not be lost. That’s the point. You will still know how to fish.

I will use the term class here as I describe parts of this pattern. JavaScript is not a class-based system, rather a function-based one. I am simply trying to use terms that are comfortable to describe discrete “units” of functionality.

Suffice it to say that a class in the SOOJS pattern is simply a collection of methods and properties which can be instantiated. I won’t go too deeply into the OO concepts here, but the point is to create definable “objects” that encapsulate form and function. None of this is new. There are plenty of “Class” structures for JavaScript on the web. Even the venerable John Resig has one — arguably one of the best available. So, why didn’t I just choose one of those?

Indeed, I looked long and hard into those much more complete implementations. They have a few benefits over the SOOJS pattern, but they also have a few weaknesses. And, for my need, those weaknesses are important.

SOOJS is intending to solve the problems of code obfuscation, “compile-time” checking, code-inspection, strong delegate patterning, and really most importantly code-readability. All of this without any need for a standard piece of code, or Library, or anything else.

 

So, then how’s it work

Ah, we’ve finally made it to the guts of it all. So far I’ve extolled the virtues of not giving you anything at all. So what good could possibly come from all of this? Well it is time we step into that discussion. And it’s hard to go much further without code. I know many of you are screaming “finally”. Sorry for the all the exposition here, but the idea behind a pattern is the why, as much as the how.

Let’s start with the most basic of possible Objects in JavaScript.

There. Don’t we feel special, we created a dog. But this leaves a lot to be desired. Let’s put a little specificity in there.

Okay, now we have a more specific object. SallyDog is taking shape. And this is the most common practice in JavaScript to encapsulate data. And it’s really purely the best. We want to keep this kind of thing possible. But what is missing here is it’s not an object that can be instantiated and thus reused. Let’s try this again:

Okay, now we’re getting somewhere. We have used the awesome power of JavaScript to create a “repeatable” dog. Of course we have also created a few properties that can be set. Say we want another dog. It would be nice to be able to set properties from the signature, much like traditional OO programs.

Awesome. This is truly a full-blown repeatable object in JavaScript. Now we have two truly different dogs with their own properties. So, let’s make them do something. Let’s say bark.

(JSFiddle of the above)

Okay, we are not at an entire Object. It looks so good, and this is where most systems stop. It has properties and methods and can be instantiated as many times as we like. So, why aren’t we done yet?

What else could you ask for

Well, the issue here is that these objects, while fully capable of satisfying standard Object requirements, do not have enough room for sophistication. They expose too much and offer no guidance in how things should hook together. This begins a clear divergence in my terminology. What we have seen so far is really an object [small ‘o’ intentional], a simple self-contained item. And, indeed, if you hang in there a bit longer you will see that the above is very near the SOOJS pattern for plain objects. But the world is far more complicated than being populated by unique dogs.

It’s all fine and good to have objects describe the data elements or controlled structures of a system. But I don’t need one pattern for one part of the system and an entirely separate one for another. I need this class pattern to be useable for every part of the system. This way every part of the project has the same structure and bindings as any other. This consistency has an amazing number of down-stream benefits.

So, let’s get back to work.

Series Navigation<< Frameworks, Libraries and Patterns — oh myCore Concepts: Maintainability >>