Introducción
Continuamos viendo patrones de diseño. Hemos analizado por el momento los dos más conocidos: el patrón módulo y el módulo revelado. Toca ahora el turno de un recién llegado, el intraducible This Namespace Proxy.
Creado por el desarrollador inglés James Edwards, este patrón utiliza los comandos apply y call para crear dos capas en las que contexto y argumentos se separan. Resulta, de lejos, el diseño más elegante visto hasta ahora:
El código
var myApp = {}; (function(){ // Private variables / properties var foo = 'Hello'; var bar = 'World'; //Private method var myMessage = function(){ return foo + ' ' + bar; }; // Public Method this.sum = function( param1, param2 ){ return param1 + param2; }; }).apply( myApp ); console.log( myApp.sum( 10, 5 ) ); // 15 console.log( myApp.myMessage() ); // Error, myApp.myMessage is not a function
La diferencia de este patrón con respecto a los anteriores está en la propia función que lo envuelve: en lugar de un autoejecutable a secas, estamos añadiendo los métodos al objeto principal mediante el comando apply.
En este contexto, this referencia siempre al padre (el objeto al que estamos extendiendo) lo que permite una flexibilidad extrema. La distinción entre métodos públicos y privados se realiza ahora mediante dicha referencia.
Una primera ventaja del uso de this, es que, al no tratarse de variables, estamos protegiendo el nombre de los métodos públicos de reasignaciones accidentales que puedan darse más adelante.
Pero además de añadir una capa de seguridad, este patrón permite avanzar en cuanto a escalabilidad de una arquitectura Javascript.
Módulos en paralelo
This Namespaces Proxy es brillante por su simplicidad conseguida gracias a un correcto uso del lenguaje: no hay artificios ni malabarismos como los que hemos visto anteriormente con el método return.
Tomándolo como punto de partida, podemos continuar jugando con el API apply y call para obtener un modelo capaz de ser asignado a dos, o más, contextos diferentes permitiéndo una ejecución en paralelo. Esta funcionalidad resulta extremadamente útil en aplicaciones complejas donde varios procesos participan de los mismos algoritmos sin interferir entre ellos. Un ejemplo básico de esta estructura serÃa:
// Contexts var context1 = {}, context2 = {}; // Method for any context var incrementNumber = function( param1 ){ var startNumber = param1 || 0; this.increment = function(){ return startNumber++; } }; incrementNumber.call( context1 ); incrementNumber.call( context2, 10 ); console.log( context1.increment() ); // 0 console.log( context1.increment() ); // 1 console.log( context1.increment() ); // 2 console.log( context2.increment() ); // 10 console.log( context2.increment() ); // 11 console.log( context2.increment() ); // 12
Analizando el código anterior, vemos que partimos de dos contextos diferentes; en este caso, objetos vacÃos. El método común que queremos aplicar se define más adelante y luego se asocia a los contextos anteriores mediante un call. El resultado son dos objetos independientes participando del mismo método.
Esta flexibilidad permite, por ejemplo, extender un único entorno consevando la herencia del método común que pasa a estar disponible mediante la referencia this:
context1.incrementTwice = function(){ // First this.increment(); // Second and go return this.increment(); }; console.log( context1.incrementTwice() ); // 1
El ejemplo anterior, aunque poco útil, muestra cómo se puede extender un contexto (objeto) de forma individual conservando la funcionalidad de los métodos comunes.
Exprimiendo el contexto
Angus Croll considera ir más allá: propone tomar una librerÃa completa, contenerla dentro de un nuevo objeto y usar apply para asociarla al contexto que escojamos.
//library code var protoQueryMooJo = function() { //everything } //user code var thirdParty = {}; protoQueryMooJo.apply(thirdParty);
Esto permitirÃa por ejemplo, usar jQuery únicamente dentro de un contexto del código y Mootools en otro. Esto abre un amplio abanico de posibilidades en cuanto al ensamblaje de librerÃas propias o de terceros.
Conclusión
El This Namespace Proxy supone un cambio importante en cuanto al planteamiento de los patrones de diseño más tradicionales. El uso de fórmulas básicas del propio lenguaje como son la APIs call y apply permiten asociar métodos a un número ilimitados de contextos – objetos permitiendo una ejecución en paralelo de los mismos.
Llendo más allá, puede utilizarse esta estructura para conseguir que partes de un código (librerÃas enteras u otros métodos) actúen dentro de un determinado ámbito sin interferir con el resto disminuyendo drásticamente los riesgos de colisiones e incompatibilidades.

Muy bueno el artÃculo aunque no me ha quedado clara la diferencia entre usar “call” ó “aply” (a parte de lo evidente).
¿como se consigue hacer una clase que herede de otra con este patron? Es decir, tengo mi clase var myApp = {};
(function(){//lo que haga la clase}).apply( myApp ); y quiero crear una segunda clase usando este mismo patron que extienda de la primera… estoy intentandolo pero no doy con la tecla…
me lie, basta con myApp.mySubApp = {};
(function(){//lo que haga la clase}).apply( myApp.mySubApp );
Hola, hace un tiempo uso una estructura como la siguiente para generar objetos a partir de “clases” (entiendo que uno se deberÃa olvidar de las clases en javascript), sin embargo me ha funcionado bastante bien. Noto que hay algún parecido con el patrón Proxy, sin usar apply. Quisiera saber si cometo errores al usar esta estructura, o si incluyo fallas de seguridad.
Foo=function(param1,param2){ //Create an obj variable to manage this without conflicts with another this uses var obj=this; //Private variables var priVar=0; var parameter1=param1; var parameter2=param2; //Private Methods var privateMethod=function(){ console.debug("I'm a private method, only accesible from the Object"); }; //Public Methods obj.decrement=function(){ console.debug(--priVar); } obj.increment=function(){ console.debug(++priVar); } obj.getParam=function(){ console.debug("The parameter1 passsed in constructor is: "+parameter1+" - parameter 2: "+parameter2); } obj.usePrivateMethod=function(){ privateMethod(); } }; //Uso de la "clase" var foo=new Foo("parameterValue","another"); foo.increment(); foo.decrement(); foo.getParam(); foo.usePrivateMethod();No hay ningún problema con la estructura que planteas; durante años, la programación con objetos en Javascript se ha desarrollado con un patrón similar al que propones: constructores y herencia prototÃpica.
En tu caso, Foo, (que por cierto has olvidado declarar con ‘var’), actúa como un constructor al que se precisa instanciar como una ‘clase’ estándar; tras ello, mediante herencia prototÃpica, se van estableciendo sus métodos públicos dejando el resto de funciones internas como privadas.
Los patrones ‘modernos’, lo que buscan es ‘homogeneizar’ la estructura interna de los objetos para organizarla en Javascript puro, es decir, sin tratar de imitar las caracterÃsticas o funcionalidades a las que podemos estar acostumbrados en otros lenguajes. De ahà que ni siquiera hablemos de clases sino de prototipos y que optemos por esquemas donde todos los métodos internos de un objeto, se declaren de la misma forma para, solo en un determinado punto, hacerlos públicos o no.
Como ves, es solo una cuestión de ‘organización’ interna… Tu código, o forma, es perfectamente válido.
Saludos.