HiveBrain v1.2.0
Get Started
← Back to all entries
patternjavascriptMinor

Decoupling with a self-descriptive mediator function

Submitted by: @import:stackexchange-codereview··
0
Viewed 0 times
withfunctiondecouplingmediatordescriptiveself

Problem

I don't have a lot of experience writing libraries and just recently started thinking a lot about structure and patterns.

I wrote a tiny module manager based on the facade and mediator design patterns and very vaguely based on require.js / AMD and libraries using facade+mediator patterns like jQuery.

My goal is not only to decouple but to provide a minimal, self-descriptive mediator function as an entrance point into modules serving as a kind of tutorial.

So if everything works out inspecting a module via console.log(), it only shows the exposed mediator function and hopefully gives the required information needed to use the module without looking up in the documentation most of the time

Here is an example module featuring all structural components:

imports(["module1","module2"],function privateModuleConstructor(moduleOne,moduleTwo){
    var privateVar = "hidden and can only be accessed through the closure";

    return exports(function longDescriptiveMediatorName(){
         var a = arguments,
             l = a.length;
             c = a.callee;
         /* ...exposed part of the facade... */
         if(l===0)                     {return privateMethod()};
         if(typeof a[0] === "string")  {return privateVar+a[0]};
         if(a[0] instanceof Array)     {return privateMethod.apply(c,a[0])}

    },[module1,module2,publicMethod],"shortAlias");

    function privateMethod(){
        return privateVar.replace(/hidden/,"now revealed");
    }
    function publicMethod(){
        return "exposing methods without mediator increases coupling but is possible"
    }
})


How intuitive does this feel to you? Even without seeing the exact source of imports and exports, does this give you the information you would need to write a module yourself?

edit:
After using the pattern for a month it turned out to be rather tedious most of the time. Some modules just can't be reasonably decoupled this way, so it's far from being the magic formula solution that so

Solution

Odd question,

  • arguments.callee is considered obsolete, it's use will trigger an error in strict mode



  • On top you use moduleOne, but you pass module1 in the array in your exports call



  • You did not provide the source for exports



  • You have both missing & unnecessary semicolons ( jshint.com )



-
This

var a = arguments,
    l = a.length;
    c = a.callee;


should be

var a = arguments,
    l = a.length, //<- Comma here
    c = a.callee;


-
Traditionally the private things go on top, with a return/export at the bottom, still I like your way better

-
I'm assuming your exposed part of the facade is just a show case of what you can do and you will not actually decide which function to call based on parameter count and type.

All in all, I find this introduces complexity while not providing very much in return. Personally, I would hold off on modules until I really need them. And then, use require.js.

Code Snippets

var a = arguments,
    l = a.length;
    c = a.callee;
var a = arguments,
    l = a.length, //<- Comma here
    c = a.callee;

Context

StackExchange Code Review Q#54150, answer score: 2

Revisions (0)

No revisions yet.