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

You’ve reached the final element of the base pattern here. We’ve seen files and objects, internals and publics, readability and no training. Now the final step is to make sure these objects can easily communicate with the world, and have a reasonable standard to also listen to the world.

I will not go heavily into the delegate pattern here, you will find much more lucid explanations on the web. A quick explanation would be assigning an object to “listen” to another. That other object has “hooks” or delegateCallbacks defined so you know what to listen for. But this is all so theory driven. Let’s do code. How about starting with our dog from the previous example and adding a delegateCallback section:

Okay, with this I will pull out what we’re interested in and re-describe it here:

This object stands as a protocol definition in our class. I usually leave it at the very top so new developers can see very quickly what the object is capable of notifying the delegate of. You will also see a bit of boilerplate here testing delegate to make sure it handles this callback. This way the object doesn’t have to concern itself with if the delegate is fully formed, it only has to concern itself with itself.

Note: You can, of course, add required delegate callback handling mechanics into these classes at any time. SOOJS leaves the door open for any additional elements you think are needed. It is, after all, all your code.

Coupled with this delegate caller is the callbackHandlers object:

This is the place a SOOJS class handles callbacks and the object you pass as your delegateRef to other objects. To show this I need to construct a different example:

The JS Bin example

The above is an entire example of several objects talking to one another. The JS Bin example also shows how simple the UI implementation becomes when we’re dealing with discrete objects:

Then the delegate callback handlers handle updating the UI in any way needed.

This delegate pattern is amazingly strong. It also asks developers to create tightly managed systems. If there is an issue with something not happening when the final apple falls, you know where to look. Either that is not being announced to the delegate, or the delegate is not handling it. No more hunting around for any and everyone who may be observing the tree changes.

And this brings us to the final discussion of the SOOJS pattern. Even though everything you now know is the pattern, it’s hard to figure the best way to define objects in a customer-facing application. That’s where some basic MVC principles come in.

Series Navigation<< Our first SOOJS ObjectBasic MVC >>