Even in a hypothetical world where objects are packaged into black boxes it would seem that convention and configuration butt heads repeatedly until developers are quite frustrated with their code. In the real world it's even more difficult to package up black boxes because the language architecture design is fundamentally flawed. (I'm looking at you Javascript global namespaces!)
So, I've personally set out to develop quick easy ways to make boxes that appear to be black boxes, but are highly configurable.
Here were some of the goals I had in mind for designing my personal plugin Architecture.
- Had to be easy!
- Had to be quick!
- Plugin Convention over configuration
- Boilerplate-able
- Should give access to constructor options to determine where the construction of the object goes
- Should provide a local scope for hidden variables relative to each object.
Here's a boilerplate you can use to create something like I'm describing.
If some of that code looks confusing to you, I suggest looking at the concept of functional expressions. They give you a "pseudo-blackbox" that can see the global namespace.
If you are good on closures, then we move on to the next step. Actually defining the code to make plugins work. Here's what I personally use:
This code is rather simplistic, but lets take a look a bit deeper to see the real beauty of it.
This little function right here is where ALL the magic happens. Let me show you an example of why this is "magic." Writing a plugin is very easy to do here.
Boom! Now you can call this:
As if that wasn't enough... let's go back and look at another example. A full on event emitter API.
Take some serious time to learn what just happened here. Each one of the functions created in that script are local to the object itself, because the plugin constructor code is called only once. This allows you to enclose private variables into a black box namespace. It's completely abstracted away to the developer behind the curtain.
In functional health,
-Josh
No comments:
Post a Comment