var a = {
  init: function() {
    this.list = [];
  },

  get first() {
    return this.list[0];
  }
};

O

var a = {
  init: function() {
    this.list = [];
  }
};

Object.defineProperty(a, 'first', {
  get: function() {
    return this.list[0];
  }
});

Y que si hacemos _.extend(a) va a fallar porque intentará hacer result.first = a.first ejecutando el getter. Pero como aún no hemos llamado al .init() en a porque solo es un prototipo, la propiedad .list es undefined produciendo un error.

Pues bien, yo creía que esto se solucionaba extrayendo el descriptor de la propiedad y usando ese mismo descriptor para copiar la propiedad al nuevo objeto:

function extend(obj) {
  var result = {};
  var properties = Object.keys(obj);

  properties.forEach(function(prop) {
    var descriptor = Object.getOwnPropertyDescriptor(obj, prop);
    Object.defineProperty(result, prop, descriptor);
  });

  return result;
}

Pero he usado esto en la librería de promises y me he dado cuenta que solo hereda las propiedades directas, tanto Object.keys como Object.getOwnPropertyDescriptor solo funcionan si la propiedad está directamente declarada en el objeto y no en ninguno de sus prototipos. Y no hay ninguna forma de decir Object.getPropertyDescriptorFromHimOrHisPrototypes() así que la única forma es recorrer todos los prototipos.

function extend(obj) {
  var result = {};
  var proto = obj;

  while (proto) {
    Object.keys(proto).forEach(function(prop) {
      var descriptor = Object.getOwnPropertyDescriptor(proto, prop);
      Object.defineProperty(result, prop, descriptor);
    });

    proto = Object.getPrototypeOf(proto);
  }

  return result;
}

Pero eso tampoco funciona del todo bien porque las propiedades de los ancestros se impondrían sobre las propiedades propias del objeto. Así que primero hay que empezar por el último prototipo y acabar por el propio objeto

function extend(obj) {
  var result = {};
  var proto = obj;
  var protos = [];

  while (proto) {
    protos.push(proto);
    proto = Object.getPrototypeOf(proto);
  }

  protos.reverse().forEach(function(ancestor) {
    Object.keys(ancestor).forEach(function(prop) {
      var descriptor = Object.getOwnPropertyDescriptor(ancestor, prop);
      Object.defineProperty(result, prop, descriptor);
    });
  });

  return result;
}

Y esto ya funciona, pero le falta un detallito, mediante el property descriptor se puede poner que una propiedad no sea enumerable por lo que no se interará sobre ella con un for .. in .. ni con Object.keys pero si las podemos obtener si utilizamos Object.getOwnPropertyNames (Fuente: MDN). Así que remplazando Object.keys con Object.getOwnPropertyNames esta vez si (espero, rezo, suplico -.-) tenemos una función que crea una copia de todas las propiedades propias y heredadas de un objeto.

function ecma5extend(obj) {
  var proto = obj;
  var protos = [];
  var result = {};

  while (proto) {
    protos.push(proto);
    proto = Object.getPrototypeOf(proto);
  }

  protos.reverse().forEach(function(ancestor) {
    Object.getOwnPropertyNames(ancestor).forEach(function(prop) {
      var descriptor = Object.getOwnPropertyDescriptor(ancestor, prop);
      Object.defineProperty(result, prop, descriptor);
    });
  });

  return result;
}

Como al final el código ha quedado bastante más complejo de lo que me gustaría lo he apuntado en un Gist que podría venirles bien.

Hasta donde sé los constructores hacen más o menos esto

function fakeNew(Ctor) {
  var instance = Object.create(Ctor.prototype);
  instance.constructor();
  return instance;
}

Todo empezó cuando quise hacer polyfill de Object.create(), así podría crear objectos sin usar new, decidí usar la versión sencilla

Object.create = function(proto) {
  function F() { }
  F.prototype = proto;
  return new F();
}

Y empecé a crear un montón de objetos y a prototiparlos, pero como los objetos muchas veces necesitaban inicializar sus propiedades les hice el método .init()

var base = {
  init: function() {
    EmitterMixin.call(this);
    return this;
  }
};

var obj = Object.create(base).init();

Pero claro, tengo que acordarme de devolver this siempre al acabar .init() y muchas veces lo olvidaba o me olvidaba de invocar .init() que es peor. Así que intentando como simplificar la inicialización de un objeto pensé crear una funcioń global que se encargara de invocar a Object.create, llamar a la función inicializadora y devolver this:

function create(proto) {
  var child = Object.create(proto);
  child.init();
  return child;
}

Y me empezaron a dar ganas de reventarme la cabeza contra la pared al darme cuenta que lo que estaba haciendo es prácticamente lo mismo que hace el operador nativo new pero mucho más lento y, en caso de usar el polyfill the Object.create incluso usando new por debajo.

Entonces me pregunto, que beneficios aporta abandonar new? es notablemente más rápido en la mayoría de navegadores y por la naturaleza de javascript solemos necesitar crear una función inicializadora que en el caso de new es el constructor.

Y lo que es más grave aún, he notado que usaba dos tipos diferentes de objetos, unos “abstractos” y otros “instancias” la mayor diferencia es que en las instancias tenía que invocar .init() siempre mientras que los abstractos no era necesario porque solo serían usados para crear otros objetos que los prototiparan. Y es un patrón que he visto mientras usaba new:

function Foo() { }
Foo.prototype.method = function() { ... };

function Bar() { }
// Objeto "abstracto", no se invoca inicializador
Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.other = function() { ... };

// Objeto "instancia"
// se invoca el constructor como inicializador
var obj = new Bar();

Realmente hay es una ventaja abandonar new? estamos seguros que no se trata de una herramienta de alto nivel que simplifica algo que igualmente tendremos que hacer nosotros a mano? Que pros y contras tienen new y Object.create?

Github Flow

Y finalmente el artículo que ha inspirado éste. Después de probar el Git Flow (el modelo, no la herramienta) en productos profesionales y a modo de prueba en pequeñas librerías propias y aunque para proyectos grandes donde una release se planea durante semanas va bien, en pequeños proyectos, y en proyectos SaaS no acaba de encajar.

Para empezar en pequeños proyectos no hay necesidad de planificar con antelación una release, un proyecto pequeño necesita mucha actividad y poca burocracia para crecer, por otro lado, en proyectos SaaS (Software as a Serivce), es decir, productos que están disponibles online y todos los usuarios tienen la última versión y reciben los cambios inmediatamente las versiones y releases pierden fuerza. **Porqué retrasar el lanzamiento de una nueva funcionalidad cuando todos los usuarios podrían tenerla mañana sin ningún coste? en un producto clásico las funcionalidades se empaquetan para entregar al usuario la actualización un paquete cerrado y pasar el proceso de actualización la menor cantidad de veces posibles, pero **en un SaaS para el usuario no tiene ningún coste (en esfuerzo) una actualización, simplemente la próxima vez que abra el programa tendrá la funcionalidad.

Un ejemplo de SaaS es Gmail (que estuvo más de 5 años en fase Beta por éste motivo), twitter o github. Y es éste último quién, como no podía ser de otra forma, utiliza un flujo de trabajo de GIT que parece encajar bastante bien con la filosofía SaaS de release constantes. Lo que ellos llaman Github Flow.

Como ellos mismos dicen después de mentar las ventajas de git-flow, “One of the bigger issues for me is that it’s more complicated than I think most developers and development teams actually require” (Uno de sus mayores problemas para mi es que [git-flow] es más complicado de lo que creo que muchos equipos de desarrollo realmente necesitan)

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time.”
(Porqué no usamos git-flow en Github? Bueno, el mayor problema es que nosotros hacemos releases todo el tiempo).

Básicamente utilizan un flujo de trabajo que combina la potencia de GIT con las geniales herramientas de Github por lo que es aplicable tal cual a los proyectos alojados en Github.com:

• El contenido en master es una versión lista para ser utilizada, lo mismo que en git-flow.
• Crear ramas descriptivas a partir de master en el repositorio y hacer push constantemente.
• Abrir “Pull Request” en Github en cualquier momento
• Hacer merge a master solo después de una revisión del “Pull Request”
• Enviar el código a producción inmediatamente después del merge (es decir, enviar a los clientes)

Igual que en git-flow, master tiene que ser código estable listo para poner en producción, pero en éste Workflow además debe ser la rama a partir de la cual crear el resto de ramas. En resumen, cualquier desarrollador puede crear una rama partiendo de master mientras tenga un nombre claro y coherente, bien sea para corregir un bug o implementar una nueva funcionalidad. A partir de entonces el desarrollador puede hacer todos los commits que necesite y hacer push a la rama en el repositorio constantemente.

En Github mencionan muchas ventajas de ésta fase, en primer lugar, que al hacer pull cada desarrollador recibe información de las ramas en las que hay actividad, y si su nombre es descriptivo es sencillo de analizar. Además en la página de Github del repositorio podemos consultar las ramas actuales y cuánto se ha avanzado en cada una, como si de una lista de futuras funcionalidades se tratara (ver imagen artículo original). Por otro lado, los push constantes da visibilidad al resto del equipo de la actividad y garantiza la copia de seguridad de nuestros cambios. Y por fin mi parte favorita, mi descubrimiento del día, los Pull Request de Github.

Un Pull Request consiste en que después de hacer commits y push en una rama, dejamos una notificación de intención de hacer merge a master. Al hacer un Pull Request, en la página de Github del repositorio aparece nuestra notificación con la lista de commits que hemos hecho, y todos los cambios que hemos hecho (en rojo líneas borradas y en verde líneas añadidas). Esto es muy utilizado para ofrecer al dueño de un repositorio un parche o una mejora para que sea aplicado en master, lo que me sorprendió es el uso que le da Github.

A partir de aquí cualquier usuario puede añadir comentarios a una línea específica del código modificado en los commits, o un comentario general y abrir debate. Lo que a nivel profesional se conoce como code review (repaso del código) en el que un tercero nos ayuda a repasar nuestros cambios. Esto siempre que se enfoque con una actitud positiva por ambas partes, permite extender el conocimiento de esa sección del código y detectar bugs con antelación, simplemente porque cuatro ojos ven más que dos.

Actually, we use it more as a branch conversation view more than a pull request
(En realidad, [los Pull Request] los usamos más como página de conversación sobre la rama que como petición de pull).

Según el Github Flow cuando hayamos acabado el desarrollo de la rama o simplemente nos hayamos atascado o necesitamos que un diseñador de el visto bueno al resultado (ya que se pueden adjuntar imágenes a los comentarios con Markdown), abrimos un Pull Request y escribiendo @ en el comentario esa persona recibirá una notificación de nuestro Pull Request. En Github recomiendan usar “/cc @” para poner “En copia” a los interesados. A medida que recibimos opiniones y recomendaciones de otros usuarios mediante el Pull Request podemos seguir haciendo commits que automáticamente se añadirán al Pull Request.

Una vez el trabajo está hecho y hemos pasado el code review esperamos (solicitamos) recibir el visto bueno de algún o varios compañeros

This is generally a +1 or emoji or “:shipit:””
(Esto suele ser un +1 o el emoticono “:shipit:”)

Y hayamos pasado los tests, podemos hacer el merge a master nosotros mismos, cuando hagamos push de master con los cambios aplicados el Pull Request se cerrará automáticamente. Finalmente, inmediatamente después de hacer el merge a master debemos enviar el código a producción, que en el caso de Github lo hacen mediante un comando enviado por chat, pero debemos enviar el código inmediatamente a producción para poder detectar posibles bugs con la máxima antelación posible porque si algo nos da mala imagen como desarrolladores es que el trabajo de otra persona falle al ser enviado a producción por algo que nosotros cambiamos y no enviamos. En el artículo original se puede ver una imagen en la que un solo día se actualizó el código de producción nada menos que 24 veces. El mismo código que recibimos nosotros al entrar a Github.com

Ha sido largo de explicar, pero quise hacer mucho énfasis en los Pull Request ya que es un uso innovador (al menos para mi) traído de la mano de sus creadores que lo usan activamente por lo que está más que garantizada su fiabilidad. En mi opinión es el mejor flujo de trabajo para desarrollar productos SaaS, permitiendo lanzar funcionalidades constante e inmediatamente.

Sin embargo, como todas las grandes metodologías, creo que es muy importante la implicación de todo el equipo en el Workflow. El Workflow está basado en que un desarrollador sabe esperar a revisar el código a fondo y recibir feedback antes de hacer el merge a master, y creo que es bastante más complicado de lo que parece superar la tentación de tener el “trabajo hecho” pero sin revisar.

Conclusión A la fecha me encuentro con tres Workflows para trabajar con GIT:

Git-flow – Bastante genérico, en mi opinión si parte del equipo ya conoce ésta metodología es la que utilizaría “por defecto” al empezar un proyecto profesional. Y aunque suene evidente, no está de más decir que para pequeños proyectos puede resultar excesivo.

Pros

• Estándar – muy conocido en la comunidad GIT
• Genérico – en mi opinión es fácil adaptar ésta metodología a medida que avanza el proyecto

Cons

• Complejo – Para una persona comenzando en GIT puede resultar demasiado aprender la secuencia necesaria para cada fase

Git-flow con ramas por release – No muy recomendable por añadir una complejidad excesiva, pero para los proyectos elefante en los que tenemos tres clientes con versiones distinta puede ahorrarnos tiempo y esfuerzo.

Pros

• Utilidad clara – personalmente saber con precisión dónde es útil es una ventaja a la hora de tenerla en considerarlo

Cons

• Rebuscado – hay que tener cierta experiencia para evitar que ésta metodología se descontrole

Github Flow – En mi opinión la solución perfecta para un producto SaaS.

Pros

• Probado – que éste sistema esté en marcha en Github da mucha confianza, máxime siendo ellos los creadores de una de las mejores herramientas para GIT

Cons

• Equipo conscienciado – éste Workflow requiere mucha atención ya que constantemente estaremos aplicando código en producción con los riesgos que conlleva para nuestros clientes

Control de Versiones

Prefiero empezar por lo más básico porque ésto es algo que los programadores damos por hecho pero para alguien empezando puede ser totalmente desconocido. Una de las herramientas más básicas de un programador junto con el editor de texto es un sistema de control de versiones. Se trata básicamente de un programa que registra los cambios que vamos haciendo en los archivos y cuando nosotros se lo ordenamos (hacemos commit) se guarda el estado actual de los archivos, si más adelante seguimos haciendo cambio en los archivos y en lugar de mejorar empeora gracias al sistema de control de versiones podemos revertir los archivos y dejarlos tal y como estaban en el último commit o cualquier commit anterior. Además permite que dos o más personas puedan archivos de un mismo proyecto y cuando ambos envíen sus cambios el sistema hará lo posible por combinarlos (hacer merge), en caso de que el merge no se pueda hacer automático el sistema notifica un conflicto de cambios y nos pide que lo hagamos a mano.

GIT

Después de usar SVN y TFS y SourceSafe en los cuales hacer merge era dramático o bien imposible (en SourceSafe dos personas no pueden modificar el mismo archivo a la vez), descubrir GIT fue fascinante, la eficacia con la que resuelve conflictos y la capacidad de crear, combinar y destruir ramas con un simple comando es una herramienta invaluable. El principal problema con las grandes herramientas es que hay tantas formas de usarlas que si no sabes lo que haces probablemente te encuentres en un caos y esa es la sensación que tuve al dar mis primeros pasos con GIT, estar gastando tiempo y esfuerzo en usar una herramienta compleja sin conseguir exprimirle el jugo.

GIT Flow

Finalmente me crucé con GIT Flow, una guía para aprovechar el potencial de GIT en el ámbito laboral. La idea es bastante sencilla pero las directrices deben ser respetadas para garantizar el orden:

• Mantener en la rama master una versión del código lista para ser utilizada (production-ready)
• Mantener en la rama develop las nuevas funcionalidades completas de nuestra aplicación, esperando a que podamos lanzar otra versión estable (release)
• Las nuevas funcionalidades se desarrollan en ramas creadas a partir de la rama develop y una vez completadas se “mergean” a develop
• Cuando develop esté listo para una nueva release se abre una rama y se hace la fase final de testing y los cambios de versión. Una vez completada ésta fase la rama de release se “mergea” a develop y master y se añade un tag en master para marcar la release.
• Los bugs se arreglan en ramas creadas a partir de master y una vez corregidos igual que una rama de release se se actualiza la versión y se “mergea” a master y develop y se añade un tag en master

Para una explicación más detallada recomiendo leer el artículo original (inglés) ya que lo explica mucho mejor de lo que yo podría. Cada una de éstas operaciones está compuesta de varios comandos git que deben ser ejecutados en un orden dado y es muy común olvidar algún paso, principalmente al empezar con el Workflow, por ello disponemos de git-flow, una herramienta que añade comandos a git. Una vez instalado podremos ejecutar comandos como:

git flow feature start my-feature-name

Que gestionará por nosotros la creación de la rama a partir de develop. Podemos ver una introducción a git-flow en el artículo Why aren’t you using git-flow? (ingĺés). Aunque no sobra decir que en el caso de las interfaces gráficas de GIT hay que seguir los pasos manualmente.

Personalmente creo que éste sistema es bueno si tenemos GIT y no tenemos claro que Workflow seguir. Es un sistema muy extendido entre los usuarios de GIT lo que permite que la gente se adapte rápidamente y lo considero un punto medio entre complejidad y simpleza. Hay una variante para proyectos que necesitan mantener más de una versión (es decir, la mayoría de los productos que se venden como paquete cerrado) en ésta variante en lugar de poner un tag en master por versión creamos una nueva rama, por ejemplo “release-1.4″, de ésta forma disponemos de distintas ramas para cada versión. Ésto nos permite corregir un bug en una versión pasada y sacar un parche específico.

El proceso al detectar un bug en la última release es probar las releases anteriores hasta detectar la release en la que se introdujo el bug. Por ejemplo, estamos en la versión 1.8 pero detectamos un bug que afecta a nuestro producto desde la versión 1.2. En ese caso corregimos el bug en una rama creada a partir de la rama de la primera versión que contiene el bug, y una vez corregido se envía a cada rama de release que contenga el bug. Evidentemente se trata de un Workflow mucho más costoso que no debe ser utilizado a menos que tengamos la necesidad de mantener más de una versión del producto que por mi experiencia considero una mala práctica, pero si nos encontramos en ésta situación nos puede reducir los problemas y ahorrar mucho tiempo. Continúa en la segunda parte…

Para empezar está claro que es necesario tener un closure, para ocultar las variables desde fuera:

// función de ejecución inmediata
(function(global) {
    // Contenido oculto
})(this); 

Dentro de éste closure definiría la clase:

(function(global) {
    function Persona() {
        var secreto;
    }

    Persona.prototype = {
        guardarSecreto: function(susurro) {
            secreto = susurro;
        },
        revelarSecreto: function() {
            return secreto;
        }
    };

    global.Persona = Persona;
})(this);

Evidentemente es imposible acceder a la variable secreto desde los métodos porque secreto está encerrada en el constructor y no se puede acceder ella desde fuera del constructor. Así que si quiero privacidad sin meter los métodos en el constructor por los métodos que ya expliqué la solución pasa por sacar la variable del constructor:

(function(global) {
    var secreto;

    function Persona() { }
    Persona.prototype = {
        guardarSecreto: function(susurro) {
            secreto = susurro;
        },
        revelarSecreto: function() {
            return secreto;
        }
    };

    global.Persona = Persona;
})(this);

var pepe = new Persona();
var maria = new Persona();
pepe.guardarSecreto('estás en matrix');
console.log(maria.revelarSecreto());

Pruébame

Bien, ahora secreto está fuera del constructor, pero tenemos otro problema, todas las instancias de Persona comparten la misma variable! Hay que buscar la forma de contar un secreto a pepe sin que maria se entere, dicho de otra forma, de guardar un valor en una instancia sin modificar la otra. En Javascript es muy sencillo trabajar con mappings así que porqué no guardamos en un mapping la relación instancia-valor? Así cada instancia podrá tener su valor guardado en la variable secreto sin interferir con el valor de otra instancia.

(function(global) {
    var secreto = {};

    function Persona() { }
    Persona.prototype = {
        guardarSecreto: function(susurro) {
            secreto[this] = susurro;
        },
        revelarSecreto: function() {
            return secreto[this];
        }
    };

    global.Persona = Persona;
})(this);

var pepe = new Persona();
var maria = new Persona();
pepe.guardarSecreto('estás en matrix');
console.log(maria.revelarSecreto());

Pruébame

Esto tampoco funciona, porqué? Para entender ésto hay que investigar un poco, los índices de los arrays y los mappings en Javascript son strings, y si intentas poner un índice de otro tipo lo convierte a string con el método .toString()

var array = [];
array[0] = "Hola!";

for (var i in array) {
    if (array.hasOwnProperty(i)) {
        console.log("Array tiene la propiedad --[" + i + "]-- del tipo --[" + (typeof i) + "]-- con el valor --[" + array[i] + "]--");
    }
}

var mapping = {};
var indice = {};
mapping[indice] = "Mundo!";

for (var i in mapping) {
    if (mapping.hasOwnProperty(i)) {
        console.log("Mapping tiene la propiedad --[" + i + "]-- del tipo --[" + (typeof i) + "]-- con el valor --[" + mapping[i] + "]--");
    }
} 

Pruébame

Entonces tanto pepe como maria se convierten a [object Object] cuando los utilizo como índices del mapping. Y hasta aquí había llegado hasta que descubrí los WeakMap de Firefox. Consiste básicamente en una clase con métodos .set(id, valor); y .get(id); por lo que cumple la misma funcionalidad que un mapping, con la diferencia de que si el único punto del programa en el que se usa una referencia es un WeakMap, el recolector de basura la puede borrar. Es una funcionalidad que es necesaria en Javascript por motivos que no voy a enumerar ahora, pero para mi trae un éxtra: “WeakMaps are key/value maps in which keys are objects” (Los WeakMaps son mappings clave/valor donde las claves son objetos). Sorpresa! Los WeakMap a diferencia de los mappings comunes no usan strings como claves, sino objetos. Esto haría viable la implementación anterior:

(function(global) {
    var secreto = new WeakMap();

    function Persona() { }
    Persona.prototype = {
        guardarSecreto: function(susurro) {
            secreto.set(this, susurro);
        },
        revelarSecreto: function() {
            // Si no tenemos ningún secreto
            if (!secreto.has(this))
                return "Nada";
            else
                return secreto.get(this);
        }
    };

    global.Persona = Persona;
})(this);

var pepe = new Persona();
var maria = new Persona();

pepe.guardarSecreto('estás en matrix');
console.log("Secreto de María: " + maria.revelarSecreto());
console.log("Secreto de Pepe: " + pepe.revelarSecreto());

Pruébame

Nota: Aunque los WeakMap solo están en Firefox, ésto funcionará en todos los navegadores porque he creado una clase que se comporta de forma similar, pero que no permite al recolector de basura eliminar los objetos, la implementación puede verse al final del artículo.

Funciona! Hemos conseguido guardar una variable privada por instancia con un closure por clase. Ahora llémoslo un poco más allá, que pasa si en lugar de guardar una variable guardamos un objeto donde podremos tener todas las variables que queramos para ésa instancia?

(function(global) {
    var privadas = new WeakMap();

    function Persona() {
        // Inicializamos el objeto
        privadas.set(this, {});
        privadas.get(this).otraPrivada = "Variable inaccesible desde fuera";
    }

    Persona.prototype = {
        guardarSecreto: function(susurro) {
            privadas.get(this).secreto = susurro;
        },
        revelarSecreto: function() {
            return privadas.get(this).secreto;
        }
    };

    global.Persona = Persona;
})(this);

var pepe = new Persona();
var maria = new Persona();

pepe.guardarSecreto('estás en matrix');
console.log("Secreto de María: " + maria.revelarSecreto());

Pruébame

Perfecto, pero es un poco raro y repetitivo tener que hacer privadas.set(this, {}); en el constructor y privadas.get(this) pra acceder a las privadas, podríamos encapsular ésto en una función:

function privadas() {
    var map = new WeakMap();
    return function(clave) {
        if (!map.has(clave))
            map.set(clave, {});
        return map.get(clave);
    };
}

Y ahora ésta funcion nos devuelve otra función que podremos llamar cuando queramos con la instancia para obtener las privadas. Nuestra clase queda:

(function(global) {
    var p = privadas();

    function Persona() {
        p(this).secreto = "Nada";
        p(this).otraPrivada = "Variable inaccesible desde fuera";
    }

    Persona.prototype = {
        guardarSecreto: function(susurro) {
            p(this).secreto = susurro;
        },
        revelarSecreto: function() {
            return p(this).secreto;
        }
    };

    global.Persona = Persona;
})(this);

var pepe = new Persona();
var maria = new Persona();

pepe.guardarSecreto('estás en matrix');
console.log("Secreto de María: " + maria.revelarSecreto());
console.log("Secreto de Pepe: " + pepe.revelarSecreto());

Pruébame

Y voilá! Tenemos privadas por clases sin crear más de un closure.

Resumen

Está claro que es aberrante pensar en crear una arquitectura basada en éste sistema, incluso dejando de lado lo extraño de la sintaxis (p(this) para acceder a las privadas), sería peligroso porque aunque Firefox nos ofrezca WeakMap en el resto de navegadores tendríamos que crear una funcionalidad similiar y no podríamos evitar tener una referencia a las instancias si queremos que el sistema sea irrompible, lo que haría que el recolector de basura no pudiera borrar las instancias que ya no utilizemos con riesgo de llenar la memoria RAM disponible.

Como ya he dicho muchas veces, la gracia de esto no es forzar Javascript a su límite, sino forzar la mente, si hoy forzamos la imaginación hasta sus límites mañana podremos sobrepasarlos. La idea es ejercitar y mejorar la capacidad de buscar soluciones creativas y funcionales por extrañas o imposibles que parezcan.

Finalmente, como expliqué en la nota, aquí está la implementación que usé para que los ejemplos funcionen en navegadores que no sean Firefox, guarda en los objetos la propiedad $$ID para no tener que buscar en todo el array de claves el índice del objeto:

if (typeof WeakMap === 'undefined') {
    window.WeakMap = function WeakMap() {
        this.keys = [];
        this.values = [];
    }
    WeakMap.prototype = {
        constructor: WeakMap,

        set: function(key, value) {
            var id = key.$$ID = this.keys.length;
            this.keys[id] = key;
            this.values[id] = value;
        },

        get: function(key) {
            var id = key.$$ID;

            // Si el índice del objeto no se corresponde
            // con su posición en la lista de claves
            // Es que ha sido modificado, debemos corregirlo.
            if (this.keys[id] !== key)
                id = this._fixIndex(key);

            return this.values[id];
        },

        has: function(key) {
            return this._fixIndex(key) !== null;
        },

        _fixIndex: function(key) {
            for (var i = this.keys.length; i--; )
                if (this.keys[i] === key)
                    return key.$$ID = i;
            return null;
        }
    };
}

Uno de los temas más frecuentes cuando uno se inicia en Javascript es la privacidad, principalmente viniendo de lenguajes como Java, C# o C++; donde publican o se ocultan propiedades de los objetos mediante modificadores. Javascript no posee dichos modificadores sino que todas las propiedades de los objetos son públicas lo que puede ser muy confuso para una persona poco diestra en ésta técnica, entre los que me incluyo.

Personalmente cuando diseño un componente (objeto/clase/librería), es porque quiero que ese componente cumpla una funcionalidad, por ejemplo, si yo quiero tener una clase que represente a una impresora necesito enviarle datos y que los imprima; mi prioridad es que dicho componente sea sencillo de utilizar, lo que facilita la reutilización del componente. Por lo que primero imagino cómo me gustaría usarlo:

var impresora = new Impresora();
impresora.encender();
impresora.imprimir(datos);
impresora.apagar();

Como se ve, para cumplir la funcionalidad me basta con tres métodos, pero si yo escribo mi clase impresora con solo tres métodos probablemente duplicaría mucho código, por ejemplo, que .imprimir() y .apagar() deban comprobar si hay papel en la impresora.

Soluciones

Hacer toda la interfaz pública

Podríamos crear in método público .hayPapel(), pero personalmente prefiero que la API, la interfaz pública de mi componente sea tan sencilla como sea posible por lo que no quiero hacer ése método público. Cuando tengo que usar una librería ajena no quiero saber cómo está hecha, quiero saber como usarla. Por ello si ésta clase tiene el método .hayPapel() le estoy diciendo al programador que ese método está ahí para usarlo, cuando en realidad no es así, ese método está ahí para ayudarme a mi como desarrollador de la clase a no duplicar código.

Usar la convención de Barra Baja (Underscore, ‘_‘)

Una práctica muy común en Javascript es añadir al principio o al final del nombre de la propiedad el símbolo barra baja con lo que la propiedad es pública, pero por convención las propiedades que empiezan o finalizan con barra baja no deben ser llamadas desde fuera del componente:

function Impresora() { }
Impresora.prototype = {
    encender: function() { ... },
    apagar: function() { ... },
    imprimir: function(datos) { ... },
    _hayPapel: function() { ... }
}; 

Este es el método más extendido que he visto en Javascript, porque es una solución que no afecta al tiempo de ejecución del programa. Javascript simplemente accede a una propiedad pública sin pérdida de rendimiento. Es una buena solución siempre que se respete la convención, de lo contrario estaríamos acoplando componentes. Eso quiere decir que si quiero hacer pública una propiedad tengo que cambiarle el nombre en todos los puntos en que la utilizo? Desgraciadamente si, pero siempre tienes el consuelo de que será dentro de tu propia librería, ya que si cambias una variable de privada a pública no debería haber ningún punto fuera de tu código que accediera a ésa propiedad, y si lo que estás haciendo es cambiarla de pública a privada… bueno, evidentemente hay que refactorizar el código que utilizara tu librería de cualquier forma.

Privacidad por constructor

Los closures son un curioso método de privacidad, cuando creamos una función dentro de otra, la función hija puede acceder a las variables de la función padre, pero no al revés:

var a = 5;

function() {
    var b = 6;

    function() {
        var c = 7;
        // Desde aquí puedo acceder a 'a', 'b' y 'c'
    }

    // Desde aquí puedo acceder a 'a' y 'b'.
    // 'c' no existe
}

// Desde aquí solo puedo acceder a 'a'.
// 'b' y 'c' no existen 

Con ésto podemos buscar la privacidad, si analizamos el constructor de la clase Impresora veremos que es una función, igual que las del ejemplo. De alguna forma podemos crear variables privadas ahí.

function Impresora() {
    var a = "Privada!";
    console.log("Accediendo desde dentro:" + a);
}

var temp = new Impresora();
console.log("Intentando acceder desde fuera usando 'temp.a': " + temp.a);

// Esta línea no se ejecuta porque 'a' no existe aquí y falla.
console.log("Intentando acceder desde fuera usando 'a': " + a);

Pruébame

Funciona! Ahora añadamos los métodos:

function Impresora() {
    var a = "Privada!";
}

Impresora.prototype = {
    probando: function() {
        console.log("Intentando acceder desde un método usando 'this.a': " + this.a);

        // Esta línea no se ejecuta porque 'a' no existe aquí y falla.
        console.log("Intentando acceder desde un método usando 'a': " + a);
    }
};

var temp = new Impresora();
temp.probando(); 

Pruébame

Pero no podemos acceder desde los métodos! Porque no están dentro del closure, de que nos sirve una variable privada si no podemos acceder a ella desde los métodos públicos? Hay una solución: el closure en el que hemos guardado la variable privada es el constructor del objeto, por lo que podríamos aprovechar el dinamismo de Javascript e injectar los métodos en el objeto dentro del constructor, así los métodos podrían acceder a las variables privadas:

function Impresora() {
    var a = "Privada!";

    // This es el objeto que éste constructor está creando
    this.probando = function() {
        console.log("Intentando acceder desde un método usando 'this.a': " + this.a);
        console.log("Intentando acceder desde un método usando 'a': " + a);
    };
}

var temp = new Impresora();
temp.probando(); 

Pruébame

Bien! éste sistema funciona, verdad? No tiene ningún inconveniente? Bueno, tiene uno, pero no es visible a simple vista porque nuestro cerebro y el intérprete de Javascript funcionan de forma distinta. Para nosotros this.probando = function() { ... } es crear una función y añadirla a todos las instancias de Impresora pero el intérprete no lo ve así, para la máquina Javascript estamos creando una función por cada método para cada instancia y tiene sentido, si la primera función probando que creamos accede a la variable privada a de la primera instancia que creamos necesitaremos una función distinta para acceder a la variable privada de la segunda instancia que creemos.

Eso quiere decir que si creamos 10.000 instancias de Impresora tendremos 10.000 funciones que hacen casi lo mismo en la memoria? Si. Con las computadoras actuales es casi despreciable, pero si estamos manejando un proyecto en Javascript que puede estar creando y borrando instancias de la clase durante días (por ejemplo un programa de servidor o una RIA), tendremos un problema a medio plazo.

Privacidad de librería

Ahora tengo que confesar que he hecho trampas, todos los patrones descritos son para hacer privacidad a nivel de clase, pero hay una forma más sencilla de hacer privada una clase entera, los closures. Ahora pensarás “pero me acabas de decir que los closures volvían a crear los métodos por cada instancia!” si, cuando el closure es el constructor. Pero si englobamos toda la clase en un closure podemos tener privacidad a nivel de librería:

// función de ejecución inmediata, se crea, se ejecuta y no se vuelve a utilizar
// es el closure que guardará la privacidad
(function(global) {
    var contador = 0;

    function Impresora() {
        contador++;
    }

    // Creamos un método estático
    Impresora.cantidadDeInstancias = function() {
        return contador;
    };

    global.Impresora = Impresora;
})(this);

var temp = new Impresora();
var temp2 = new Impresora();
console.log(Impresora.cantidadDeInstancias());

Pruébame

La variable contador es privada a nivel de librería, significa que todo lo que esté dentro del closure accede a ella y como podemos ver todo el código dentro del closure accede a la misma variable, lo que significa que todas las instancias de Impresora comparten la misma variable. También podemos usar éste patrón para ocultar clases y funciones, lo único que será publicado de dentro del closure será lo que guardemos en la variable global.

// función de ejecución inmediata, se crea, se ejecuta y no se vuelve a utilizar
// es el closure que guardará la privacidad
(function(global) {
    function Papel() { }
    Papel.prototype = {
        hayPapelEn: function(impresora) {
            // no hay papel
            return false;
        },
        pedirAlUsuario: function() {
            console.log("Oye tu! ponme papel!");
        }
    };

    var papel = new Papel();

    function Impresora() { }
    Impresora.prototype = {
        imprimir: function(datos) {
            if (!papel.hayPapelEn(this))
                papel.pedirAlUsuario();
            // imprimir
        }
    };

    global.Impresora = Impresora;
})(this);

var temp = new Impresora();
temp.imprimir();

Pruébame

Este es un patrón muy recomendable, ya que mediante una función autoejecutable ocultamos todo lo que el usuario de nuestra librería no necesita conocer. Por poner un ejemplo, node.js utiliza un patrón similar para generar librerías, en las que todas las variables que creamos en el archivo .js quedan ocultas y solo se exponen las propiedades que añadimos al objeto global exports. Ejemplo de saludo.js:

var saludo = "Hola!";
function saludar() {
    console.log(saludo);
}
exports.saludar = saludar; 

Si tuviera que decir un defecto de éste patrón, es que todo lo que queramos englobar dentro del closure deberá estar en el mismo archivo, ya que el código debe estar dentro del closure y éste no puede estar repartido entre archivos. Ésto es un problema si queremos que dos clases con mucha lógica se comuniquen y no queremos acabar con un archivo de 1.000 líneas de código.

Resumen

No voy a opinar si la decisión de hacer todo público al crear Javascript es buena o mala porque en mi opinión no es que hacer todo público sea malo, sino que no estamos acostrumbrados a utilizarlo. Por ello, porque la mayoría de los programadores estamos acostumbrado a tener privacidad en los componentes, buscamos entre las opciones que nos da el lenguaje para simularlo.

En cuanto a mi, me parece interesante las posibilidades de un lenguaje tan flexible como Javascript a nivel académico, al fin y al cabo el objetivo de la investigación es tener la mente flexible para que a la hora de la verdad podamos ver caminos alternativos que nos ofrecen una mejor solución para un problema en particular. Un ejemplo de ésto es un patrón de privacidad por instancia que descubrí recientemente, hablaré de él en el próximo post.

Orientación a Objetos

Primero deberemos aclarar que significa Programación Orientada a Objetos (POO u OOP en ingés).

Según la Wikipedia, la descripción es:

es un paradigma de programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, abstracción, polimorfismo y encapsulamiento.

Como vemos un lenguaje orientado a objetos no necesariamente tiene que implementarse mediante clases, cualquier sistema que proporcione herencia, abstracción, polimorfismo y encapsulamiento es una implementación de orientación a objetos válida. Como ya dijimos, el sistema de clases es el más extendido, utilizado por C++, Java, C#, PHP, Python, ActionScript3, Perl, Objective-C, Ruby, etc… Javascript no tiene clases, utiliza el sistema de herencia por prototipos, veamos la diferencia:

En un lenguaje basado en clases tenemos dos tipos de conceptos, los objetos en sí, referencias que pueden ser almacenadas, modificadas y pasadas como argumentos. Y por otro lado las clases, objetos intangibles, no podemos guardarlos en variables ni pasar como argumento, no podemos manipularlos ni comprobar si existen excepto por reflexión, que consiste en herramientas del lenguaje para obtener objetos (tangibles, del tipo anterior) que representan a las clases a las que no podemos acceder. En un lenguaje de éste tipo las clases están una capa por encima de los objetos y definen la herencia, abstracción, encapsulamiento y polimorfismo de los objetos que se obtendrán a partir de ellas, tienen una función de plantillas para crear objetos definidas antes de ejecutarse el código del programa.

En un lenguaje orientado a prototipos no hay clases que definan la herencia, los objetos mismos heredan de otros objetos. No hay clases cuando el programa se inicia, sino que se crean objetos y se le ordena a otros objetos que hereden de ellos. Por ejemplo, si tenemos un objeto eventEmitter y queremos crear instancias creamos nuevos objetos y hacemos que hereden de eventEmitter.

[[Prototype]]

Una vez entendido el concepto podemos pasar a la práctica, sabemos que para crear instancias de clases hacemos new MyClass() pero cómo hacemos que objetos hereden de objetos? Aquí entran los prototipos. Todos los objetos Javascript tienen una propiedad oculta que llamaremos [[Prototype]], con corchetes (aunque en algunos navegadores es posible acceder a ella mediante la propiedad .__proto__, con dos barras bajas a cada lado, pero no es estándar) que es un puntero al objeto del cual hereda. Y que significa que hereda? Podríamos resumir la herencia en que un objeto tiene las mismas propiedades que otro.

Con ésto nos ahorramos tener que poner las mismas propiedades en más de un objeto. Esto trae un nuevo concepto que puede confundir a muchos: en Javascript todo es una instancia, y cuando heredamos de un objeto también se puede decir que estamos creando una instancia de ése objeto, para evitar confunsiones suele decirse que un objeto “extiende” otro. Imaginemos que tenemos un objeto perro que hereda de animal. Que significa ésto? que la propiedad [[Prototype]] de perro es animal, o lo que es lo mismo:

perro.__proto__ == animal; // true

El código de ejemplo es el siguiente:

var animal = {};
animal.estaVivo = function() {
    return true;
};

var perro = {};
perro.__proto__ = animal;
console.log(perro.estaVivo);

Pruébame

Vemos que perro.estaVivo es la función que asignamos a animal cómo puede ser ésto? Por la herencia por prototipos. Javascript ha buscado la propiedad estaVivo en perro pero no la ha encontrado, entonces accede a su propiedad [[Prototype]] (o __proto__) donde nosotros guardamos animal. Entonces busca estaVivo en animal y lo encuentra. Por eso perro.estaVivo nos devuelve el método de animal. Podríamos representarlo así:

Y si animal no hubiese tenido la propiedad estaVivo? En ese caso debemos tener en cuenta que animal también es un objeto y que todos los objetos tienen prototipo, en caso de que no le asignemos ninguno su prototipo es Object.prototype. Es otra forma de decir que en Javascript todos los objetos extienden Object.prototype. Object.prototype es el equivalente a la clase Object de Java o C#.

var animal = {};
console.log(animal.__proto__ === Object.prototype);

Pruébame

Y si tampoco encuentra la propiedad en Object.prototype? lo busca en el [[Prototype]] de Object.prototype pero sorpresa! Object.prototype.__proto__ es null. Eso significa que es el último objeto de la jerarquía de herencia, si llegado a éste punto Javascript no encuentra la propiedad que le pedimos devuelve undefined.

Esta jerarquía de prototipos suele llamarse cadena de prototipos del objeto. Por ejemplo, Object.prototype tiene la propiedad .toString(), entonces si volvemos a crear perro heredando de animal, su propiedad .toString() que será? Javascript recorrerá la jerarquía de prototipos de perro hasta encontrar .toString() que está en Object.prototype.

var animal = {};
animal.estaVivo = function() {
    return true;
};

var perro = {};
perro.__proto__ = animal;
console.log(perro.toString === Object.prototype.toString);

Pruébame

Como modificar una propidad inaccesible?

Bien, la teoría ha ido correctamente, pero como ya dijimos, __proto__ no es estándar, y por lo tanto no podemos contar con que funcione en cualquier motor de Javascript, entonces cómo se supone que vamos a implementar herencia en Javascript? Para ello Javascript provee de una funcionalidad un tanto difícil de entender así que intentaremos ir poco a poco.

Toda función, creada en Javascript tiene una propiedad llamada .prototype que no debe confundirse con [[Prototype]], el [[Prototype]] de las funciones apunta a Function.prototype que es un objeto que tiene funciones como .call(), .apply() y .bind(). No, en éste caso nos referimos a que todas las funciones tienen una propiedad llamada prototype que es un objeto vacío. Y porqué se llama prototype si no tiene nada que ver con el [[Prototype]] de la función? Porque los objetos que creemos llamando a ésa función con new tendrán su [[Prototype]] apuntando a la propiedad prototype de la función:

function myFunct() { }
var obj = new myFunct();
console.log(obj.__proto__ === myFunct.prototype); 

Pruébame

Sorpresa! Hemos modificado la propiedad oculta [[Prototype]] de obj! Quizás te preguntes porqué no se estandariza la propiedad accesible __proto__? Porque con el sistema de las funciones el lenguaje se asegura que sólo podemos modificar la propiedad [[Prototype]] de objetos nuevos, no de existentes. De ésta forma, en las implementaciones estándar donde no podemos acceder a la propiedad __proto__ no podemos modificar el prototipo de una función o de Object.prototype ni podemos evitar que un objeto extienda de Object.prototype, poniendo su propiedad __proto__ a null romperíamos ésta regla del lenguaje.

Pero entonces myFunct es una clase? Podría decirse que si, pero no es una clase como las que estamos acostumbrados a ver, es una función, es un objeto y es tangible, el hecho de crear nuevos objetos con new seguido de una función es solo una sintaxis que se añadió a Javascript para parecerse a Java, lenguaje en plena expansión cuando Javascript fue diseñado. Ahora que entendemos que myFunct.prototype es igual al [[Prototype]] de los objetos que creemos con la función podemos crear objetos que extiendan del mismo objeto:

function myFunct() { }
myFunct.prototype = {
    name: "Alice",
    lastname: "Smith",
    fullname: function() { 
        return this.name + ' ' + this.lastname;
    }
};

var instancia1 = new myFunct();
var instancia2 = new myFunct();

console.log(instancia1.fullname() + '\n' + instancia2.fullname());
console.log(instancia1.__proto__ == instancia2.__proto__); 

Pruébame

E incluso podemos crear un objeto que extienda de una instancia de myFunct!

instancia1.name = "Bob";
function extenderInstancia1() { }
extenderInstancia1.prototype = instancia1;
var subInstancia = new extenderInstancia1();

var texto = "Fullname: " + subInstancia.fullname() + '\n';
texto += "Es instancia de extenderInstancia1? " + (subInstancia instanceof extenderInstancia1) + '\n';
texto += "Es instancia de myFunct? " + (subInstancia instanceof myFunct) + '\n';
texto += "Es instancia de Object? " + (subInstancia instanceof Object);

alert(texto); 

Pruébame

extend()

Pero éste lío de tener funciones que parecen clases pero no son clases exactamente y crean instancias y tener que crear funciones para extender es bastante confuso, por ello, los defensores de no mezclar la herencia por prototipos con éstas falsas clases proponen usar la función extend:

function extend(proto) {
    function intermediario() { }
    intermediario.prototype = proto;
    return new intermediario;
}

Y con ésta función podemos extender objetos sin necesidad de crear funciones intermedias:

var base = {
    name: "Alice",
    lastname: "Smith",
    fullname: function() { 
        return this.name + ' ' + this.lastname;
    }
};

var instancia1 = extend(base);
var instancia2 = extend(base);

instancia1.name = "Bob";
var subInstancia = extend(instancia1);
console.log(subInstancia.fullname()); 

Pruébame

Como vemos, el código queda bastante más claro, es por ésto que en la 5ª edición de ECMAScript (el estándar en el que está basado Javascript), se decidió añadir Object.create() que cumple la misma funcionalidad que la función extend() que hemos creado.

Resumen

Es un camino duro pasar de un lenguaje basado en clases a uno basado en prototipos, requiere mucha práctica, una mente abierta y muchas ganas de aprender. Pero las ganancias son grandes, incluso para desarrolladores que no necesiten tocar Javascript considero que aprender éste patrón aporta ventajas porque entender ambos patrones en mente nos abre a nuevas ideas, nos ayuda a tener siempre presente que las cosas no tienen porque ser como estamos acostumbrados a que sean, y a buscar nuevas soluciones a nuevos problemas y por último pero no menos importante, nos mantiene activos. Espero que sea fácil seguir el post aunque se que ha crecido más allá de lo deseado, pido comprensión ya que escribir no es mi punto fuerte, pero para eso está la práctica, para mejorar

De dónde sale this

He pensado que sería un buen punto empezar por una curiosidad bastante desconocida para los recién llegados a Javascript: La variable this, también llamado el scope o más correctamente contexto de la función. En los lenguajes basados en clases más extendidos (Java, C++, C#…) encontramos que los métodos de la clase siempre disponen de la variable this que nos permite acceder a nuestra propia instancia sobre la que se está ejecutando el método. Es decir, si tenemos la clase

class MyClass {
  String myField;
  void myMethod() {
    this.myField;
  }
}

Veremos que en myMethod siempre tendremos this apuntando a una variable del tipo MyClass que contendrá un campo myField. En Javascript ésto no es así, en Javascript todo son objetos, incluidas las funciones y métodos, ambos son instancias de Function, y como tales no están ligadas a un objeto en particular. Miremos el código:

function myFunction() {
  console.log(this.name);
}

var objectA = {
  name: "Alice",
  myMethod: myFunction
};

var objectB = {
  name: "Bob",
  myMethod: myFunction
};

Aquí tenemos dos objetos totalmente independientes y ambos tienen la propiedad myMethod apuntado a myFunction a pesar de que no tienen una clase en común más que Object. Entonces cuál es el valor de this en myFunction? No es fijo, cambia según como lo llamemos.

objectA.myMethod()
// Imprime "Alice"

objectB.myMethod()
// Imprime "Bob"

Pruébame

Como vemos el valor de this cambia según sobre que objeto lo llamemos. Bien, Javascript sabe que valor tiene que poner a this antes de llamar a una función, pero nosotros necesitamos entenderlo para no encontrarnos con bugs imposibles de corregir. Para ésto hay una regla de oro: el objeto this pasado a una función es el objeto que está antes del punto que precede los paréntesis que invocan a la función. Es decir, la llamada objectA.myMethod() la podríamos dividir en cuatro partes:
* objectA: El objeto que contiene la función
* **. (punto)**: Separa el objeto de su propiedad (la función)
* myMethod: Nombre de la función
* () (paréntesis): Ejecutan la función En éste caso vemos que

antes del punto está objectA por lo que será objectA lo que se le pasará a la variable this del método myMethod.

Casos más complejos

Más de un punto

Ahora vamos a ver casos en los que tenemos más o menos de un punto, es menos difícil de lo que parece. Para empezar, que pasa si usamos namespaces:

amq.test.StringHelper.firstToUpperCase('myname');

Aquí cuál es el valor de this? Si miramos la regla de oro veremos que solo el punto que precede a los paréntesis debe importarnos, por lo que tenemos:

• amq.test.StringHelper: El objeto que contiene la función
• **. (punto)**: Separa el objeto de su propiedad (la función)
• firstToUpperCase: Nombre de la función
• () (paréntesis): Ejecutan la función El valor de

this siempre es el objeto que está antes del último punto, es decir, el objeto que contiene la función.

Sin puntos

Pero que pasa si no hay ningún punto? si la función no está en ningún objeto?

function testScope() {
  console.log(this);
}
testScope();

Aquí podríamos pensar que this es null y tendría sentido pero no, Javascript define que una función invocada sin contexto, el contexto debe ser el Objeto Global, que en el caso de un navegador sería window. Por lo que en una función que no esté contenida en ningún objeto recibirá el objeto global como this.

Callbacks

Ya con toda ésta base podemos abordar el problema de los callbacks, supongamos que tenemos una función que hace un proceso asíncrono y necesitamos pasarle un callback para que se ejecute cuando el proceso asíncrono termine. Para el ejemplo pondremos que la tarea asíncrona sea esperar un segundo

function esperarUnSegundo(callback) {
  setTimeout(function() {
    callback();
  }, 1000);
}

Perfecto, ya tenemos una función que espera que pase un segundo y llama al callback, pero que pasa si la usamos de ésta forma?

var alice = {
  nombre: "Alice",
  cansarse: function() {
    alert(this.nombre + " se ha cansado de esperar");
  }
};
esperarUnSegundo(alice.cansarse);

Pruébame

Aquí tenemos un problema, al parecer this.nombre no es “Alice”. Porqué? Repasemos la regla de oro, this será el objeto que está antes del punto que precede a los paréntesis que ejecutan la función. Busquemos los paréntesis que ejecutan la función:

callback();

Y vemos que no hay ningún punto delante. La función la hemos extraído del objeto alice, pero al extraerla la hemos desvinculado de él y al llamarlo ya no se le pasa alice porque ya no se la llama con alice.<nombre del método> Entonces cómo hacemos para que callback no pierda su contexto? para que mantenga el valor de this a alice?

Los métodos de Function

Para ésto vienen en nuestra ayuda los métodos de Function, como ya dijimos, las funciones son instancias de la clase Function y como tal tienen también métodos propios. Los más utilizados son .call() y .apply()

.call() Imaginemos que tenemos otra vez el objeto alice y que guardamos su método en una variable.

var alice = {
  nombre: "Alice",
  cansarse: function() {
    console.log(this.nombre);
  }
};

var myFunction = alice.cansarse;

Si llamamos a myFunction directamente lo estaríamos llamando sin contexto por lo el la variable this tendría el objeto global dentro de myFunction, como podemos hacer que ejecute myFunction pero pasándole alice como this? Para ésto tenemos las funciones .call() y .apply(), empecemos por la función .call().

La función .call() recibe los mismos argumentos que la función mas uno, el valor que tendrá this que se pasa antes que los demás argumentos. Es decir, nuestra función myFunction no recibe ningún argumento así que si llamamos a su método .call() y le pasamos lo que queremos que sea this es decir, alice conseguiremos que el método funcione igual que si lo hubiésemos llamado con alice.cansarse

myFunction.call(alice);

Pruébame

Ahora vamos a probar lo mismo con una función que reciba argumentos:

var alice = {
  nombre: "Alice",
  saludar: function(amigo1, amigo2) {
    alert("Hola " + amigo1 + " y " + amigo2 + ", yo soy " + this.nombre);
  }
};

var myFunction = alice.saludar;
myFunction.call(alice, "Bob", "Rob");

Pruébame

Como se ve, hemos conseguido modificar el valor que tiene this cuando se ejecuta la función, es decir el contexto.

.apply()

El método .apply() actúa de forma bastante similar a .call(), pero con una variación, solo recibe dos argumentos, el primero es el contexto de la función, el valor de this y el segundo será un array que contendrá los argumentos que se le pasarán a la función, veamos su uso en el ejemplo anterior:

myFunction.apply(alice, [ "Bob", "Rob" ]);

Pruébame

Esto aunque en un principio parezca bastante inútil nos servirá cuando, queriendo o no cambiar el contexto de una función, querramos llamarla y no sepamos ni nos interese saber cuántos argumentos tiene, supongamos que tenemos la función callWithAlice() que llama a la función .saludar() de alice y le pasa todos los argumentos que recibe.

Nota 1: Para ésto hace falta aclarar que el objeto arguments es una especie de array con los argumentos pasados a la función, más adelante profundizaremos en ello.

Nota 2: En éste caso no queremos cambiar el contexto, pero como estamos llamando a .apply() tenemos que darle uno, por lo que le damos alice que es el contexto que ya tenía.

function callWithAlice() {
  alice.saludar.apply(alice, arguments);
}
callWithAlice("Rob", "Bob");

Pruébame

Bonus: .bind()

Ahora que ya entendemos el contexto, .call() y .apply() sabremos que cuando pasemos una función como callback si no queremos perder el contexto de la función deberemos hacer:

function esperarUnSegundo(callback) {
  setTimeout(function() {
    callback();
  }, 1000);
});

esperarUnSegundo(function() {
  alice.myMethod();
});

O bien:

function esperarUnSegundo(callback, context) {
  setTimeout(function() {
    callback.call(context);
  }, 1000);
});

esperarUnSegundo(alice.myMethod, alice);

Pero ésto puede ser un poco tedioso cuando manejas muchos callbacks de éste tipo, para ello se ha creado el método .bind(). Es un método de Function que devuelve otra función. Confuso, verdad?

.bind() recibe un argumento, el contexto que se le podrá a la función sobre la que se aplica el .bind() y devolverá una función que cuando sea llamada ejecutará la función original con el contexto que se le pasó a .bind(). Lo veremos mejor con un ejemplo:

var alice = {
  nombre: "Alice",
  saludar: function() {
    console.log("Hola! Soy " + this.nombre);
  }
};

var myFunction = alice.saludar.bind(alice);
myFunction();

Pruébame

Lo que hemos hecho en la línea 8 es crear una función que cuando sea invocada llamará a saludar y le pasará alice como contexto.

Y ya está!

Con éste repaso ya deberíamos ser capaces de entender la parte más complicada para un recién llegado a Javascript, la modificación del contexto. Es una técnica que requiere mucha práctica, pero detrás de la cual se esconde la mitad del potencial de Javascript y como tal, también nos abre los ojos a muchos bugs que de otra forma serían imposibles de entender.

De hecho, para los que les gusta romperse la cabeza como yo, les dejo un caramelo: Todas las funciones tienen los métodos .call(), .apply() y .bind(), es cierto. Pero éstos métodos también son funciones, eso significa que podemos hacer ésto? Que resultado tendría? Se los dejo a ustedes

alice.saludar.call.call.call.call.apply.bind()

Y que pasa si llamo a uno de éstos métodos y no le paso scope?

alice.saludar.call(null);

Espero que haya sido claro y conciso, pero me temo que ha sido más de lo primero que de lo segundo. Pronto tendré otro artículo sobre Conceptos Básicos de Javascript. Saludos.

NOTA: Me gustaría implementarla en Test Driven Development, pero ya es bastante para quien lee y para el que escribe seguir la implementación como para encima añadir TDD, pero no quisiera dejar de recomendarlo.

Primero: Funcionalidad básica

Lo que necesitamos de un objeto Promise es:

• Crear instancias totalmente independientes
• Añadirle callbacks que serán llamados cuando se cumpla la promesa
• Notificarle cuando se ha cumplido la promesa

Con los objetivos en la mano es más sencillo ver que hacer, lo primero necesitamos una clase, a la hora de crear clases en Javascript yo me decanto por el patrón de constructor con prototipos que espero explicar algún día.

function Promise() { }

Segundo punto: poder añadirle callbacks, ésto consiste en el método .then() al que deberemos poder llamar pasándole las funciones que queremos que se ejecuten cuando la promesa se cumpla. Puesto de debe poderse añadir más de un callback para cada promise lo más lógico sería crear un Array donde almacenarlos

function Promise() {
  this._callbacks = [];
}

Y el método .then() que vaya añadiendo al Array los callbacks que se le pasen, puesto que es mejor que los errores se detecten cuanto antes también podemos asegurarnos que el callback es una función:

Promise.prototype.then = function(callback)  {
  if (typeof callback !== 'function') {
    throw new Error("[Promise.then] El argumento 'callback' no es una función " + typeof callback);
  }

  this._callbacks.push(callback);
};

Y ahora que ya tenemos todos los callbacks en un Array necesitamos algún sistema para avisarle al Promise que ya tiene los datos que necesita y que se los pase a los callbacks. Sobre ésto no he visto ninguna implementación, pero a mi me parece bastante razonable crear un método Promise.done() que notifica al Promise que ya está cumplido y ejecuta los callbacks.

Promise.prototype.done = function() {
  var callback;
  for (var i = 0; i < this._callbacks.length; i++) {
    callback = this._callbacks[i];
    callback();
  }
};

Y ya lo tenemos hecho, hemos creado un Promise básico, vamos a probarlo. Imaginemos cualquier función asíncrona, por ejemplo vamos a crear una función que nos avise cuando pase un segundo:

function esperarUnSegundo() {
  var promise = new Promise();
  // Hacemos un timeout a mil milisegundos
  setTimeout(function() {
    promise.done();
  }, 1000);
  return promise;
}

esperarUnSegundo().then(function() {
  alert("Ha pasado un segundo =D");
});

Pruébame

Si probamos todo el código veremos que al cabo de un segundo ejecuta el alert.

Todo funciona perfectamente, vamos un punto más allá, ésta vez descarguemos una página, como no nos importa ahora mismo el código que descarga la página fingiremos llamar a una función peticiónHttp(url, callback) que lo hará por nosotros.

function descargar(url) {
  var promise = new Promise();
  peticiónHttp(url, function(codigoHtml) {
    promise.done();
  });
  return promise;
}
descargar('www.google.com').then(function() {
  // Y ahora?
});

Sorpresa! La función ha descargado la página y obtenido el html, pero nuestro Promise no ha sido capaz de pasarlo al callback. La función del Promise en un principio era avisar cuando una tarea asíncrona termina, pero la mayoría de las tareas asíncronas devuelven un resultado y cuando avisemos al Promise que se ha cumplido también querremos que pase el resultado a todos los callbacks. Para ello modificaremos el método done y para que pase a los callbacks todos los argumentos que se le pasen a él (si no sabes lo que hace el método apply puedes mirarlo aquí):

Promise.prototype.done = function() {
  // Guardamos los argumentos que se le ha pasado a .done()
  var args = arguments;
  var callback;
  for (var i = 0; i < this._callbacks.length; i++) {
    callback = this._callbacks[i];
    // Y se los pasamos al callback
    callback.apply(null, args);
  }
};

Y ya está, ahora podemos pasarle argumentos a .done():

function descargar(url) {
  var promise = new Promise();
  peticiónHttp(url, function(codigoHtml) {
    promise.done(codigoHtml);
  });
  return promise;
}

descargar('www.google.com').then(function(codigoHtml) {
  alert(codigoHtml);
});

Ya tenemos nuestra versión 0.1 de la clase Promise

Segundo: Gestión de errores

Hasta aquí ya tenemos un Promise con el que avisar cuando acaba una tarea asíncrona, pero nos olvidamos de algo muy importante, a la hora de programar no todo sale como quisiéramos y muchas veces nos encontramos con errores, que pasaría si peticiónHttp() fallara? Que jamás se ejecutaría el .done() del Promise que hemos devuelto y el callback esperará sentado a que lo llamen el resto de su vida. Hay que preparar el Promise para que avise cuando algo va mal. Necesitamos añadirle al Promise:

• Poder añadir callbacks especiales para cuando se produzca un error
• Avisarle cuando se produzca un error
• Que le pase al callback de error el objeto Error que se ha lanzado

Lo primero es que el Promise no solo reciba un callback normal sino que también reciba otro callback que será ejecutado solo si se produce un error. Una idea que me gusta es dárselo al método .then() como segundo argumento, ya que el primero es el callback normal. Y éste debería guardarlo, para ello debemos crear otro Array donde guardar los callbacks de errores:

function Promise() {
  this._callbacks = [];
  this._onError = [];
}
Promise.prototype.then = function(callback, onError) {
  // Validamos el callback normal
  if (typeof callback !== 'function') {
    throw new Error("[Promise.then] El argumento 'callback' no es una función " + typeof callback);
  }
  // Validamos el callback de error. Como es opcional puede ser 'undefined' o una función
  if (onError && typeof onError !== 'function') {
    throw new Error("[Promise.then] El argumento 'onError' no es una función " + typeof onError);
  }

  this._callbacks.push(callback);
  // Si no era undefined debe ser una función, porque ya lo validamos
  if (onError) {
    this.\_onError.push(onError);
  }
};

Como se ve es prácticamente lo mismo que para los callbacks, ya que se trata de lo mismo, un callback por si hay errores. Ahora vamos a matar los últimos dos puntos de un tiro. Añadiremos un método para avisar al Promise cuando se produzca un error y le pasaremos el objeto Error para que lo pase a todos los callbacks de error.

Promise.prototype.fail = function(error) {
  var callback;
  for (var i = 0; i < this._onError.length; i++) {
    callback = this._onError[i];
    callback(error);
  }
};

Y ya está, ahora cuando llamemos al método .fail() llamará a todos los callbacks de error y les pasará el objeto Error. Ahora podemos adaptar la función descargar() para que también notifique cuando se produzca un error:

function descargar(url) {
  var promise = new Promise();
  try {
    peticiónHttp(url, function(codigoHtml) {
      promise.done(codigoHtml);
    })
  } catch (error) {
    promise.fail(error);
  }
  return promise;
}
descargar('www.google.com').then(function(codigoHtml) {
  alert(codigoHtml);
});

Ahora ya podemos decir que tenemos la versión 0.2 del Promise tengo que dejar para otro post métodos más complicados como .then() concatenados y el .and() porque ya es muy tarde. Aquí dejo el código completo al que le he añadido la propiedad _estado para evitar que se pueda cumplir o fallar un Promise cuando ya está cumplido o fallado.

function Promise() {
  this._callbacks = [];
  this._onError = [];
  this._estado = "esperando";
}

Promise.prototype.then = function(callback, onError) {
  // Validamos el callback normal
  if (typeof callback !== 'function')
    throw new Error("[Promise.then] El argumento 'callback' no es una función " + typeof callback);

  // Validamos el callback de error. Como es opcional puede ser 'undefined' o una función
  if (onError && typeof onError !== 'function')
    throw new Error("[Promise.then] El argumento 'onError' no es una función " + typeof onError);

  this._callbacks.push(callback);
  // Si no era undefined debe ser una función, porque ya lo validamos
  if (onError) 
    this._onError.push(onError);
};

Promise.prototype.done = function(error) {
  if (this._estado !== 'esperando')
    throw new Error('Intentando cumplir un promise que ya ha finalizado');

  this._estado = "cumplido";
  // Guardamos los argumentos que se le ha pasado a .done()
  var args = arguments;
  var callback;

  for (var i = 0; i < this._callbacks.length; i++) {
    callback = this._callbacks[i];
    // Y se los pasamos al callback
    callback.apply(null, args);
  }
};

Promise.prototype.fail = function(error) {
  if (this._estado !== 'esperando') throw new Error('Intentando hacer fallar un promise que ya ha finalizado');

  this._estado = "fallado";
  var callback;

  for (var i = 0; i < this._onError.length; i++) {
    callback = this._onError[i];
    callback(error);
  }
};

Recientemente he tenido que implementar un sistema MVC en Javascript para simplificar el desarrollo sobre una plataforma y me he encontrado con el problema de que las llamadas asíncronas a servidor rompían la simpleza del código, tras un análisis identifiqué cuatro problemas:

1 – Ensuciar la API

Todas las llamadas reciben un último argumento que es el callback:

var dir = new Directory('file:///home/user/Desktop');
dir.browse(function(dir, items) {
  // ...
});

Con ésto la API resulta confusa desde el punto de vista de la simpleza y de la semántica. Semánticamente una función recibe la información mínima indispensable para devolver un dato relacionado a lo que se le ha solicitado, como vemos no es el caso en métodos asíncronos:

void Directory.browse(Function callback);
void File.getContent(String encoding, Function callback);
void File.getPermission(Function callback);

2 – Llamadas anidadas

En muchas ocaciones deberemos ejecutar una llamada al acabar otra, ésto nos obliga a anidar callbacks:

var file = new File();
file.isReadable(function(permission) {
  if (permission) {
    file.getContent(function(content) {
      // do something with the content
    });
  }
});

A medida que vamos añadiendo niveles de profundidad ésto se vuelve muy confuso.

3 – Llamadas concurrentes

También necesitaremos realizar llamadas asíncronas paralelas y ejecutar una acción al acabar todas:

var isFile1Done = false;
var isFile2Done = false;

function testIsOver() {
  if (isFile1Done && isFile2Done) {
    // Both files loaded.
  }
}

File.get('http://www.somedomain.com/file1', function() {
  isFile1Done = true;
  testIsOVer();
});
File.get('http://www.somedomain.com/file2', function() {
  isFile2Done = true;
  testIsOVer();
});

Como podemos ver algo tan sencillo como dos peticiones paralelas necesitan mucho código para manejarlas.

4 – Gestión de errores

Es traumática la forma de gestionar errores mediante callbacks, el método más extendido que he visto ha sido el de nodejs, el primer argumento de cada callback es el objeto Error si es que hubo alguna excepción, lo que me parece horrible ya que cada función debe confirmar que su primer argumento es undefined para asegurar que no han habido errores:

File.get('http://www.somedomain.com/file2', function(error, file) {
  if (error) {
    // Show blue screen of death
  }
  // do something with file.
});

SOLUCION

Queda claro que las peticiones asíncronas son necesarias en cliente y servidor ya que permiten al programa continuar trabajando mientras espera la respuesta a la petición, pero éstos problemas podrían dificultar la manutención del código. Y aquí es donde viene a ayudarnos el Patrón Promise. El patrón Promise asiste a una función que no puede devolver inmediatamente su resultado (es decir, una función asíncrona) y devuelve la promesa de que tendrá el resultado en un futuro (a lo que llamo cumplir la promesa ). A nivel de implementación, una función devuelve un objeto Promise que gestionará por ella el callback. Veamos cómo soluciona nuestros problemas:

1 – Claridad en los métodos

La función solo debe recibir la información necesaria para hacer la petición y devuelve la promesa de que esos datos llegarán.

var dir = new Directory('file:///home/user/Desktop');
var promise = dir.browse();
promise.then(function(dir, items) {
  // ...
});

Y ésto aún lo podríamos mejorar llamando directamente a la función then sin guardar el promise en una variable:

var dir = new Directory('file:///home/user/Desktop');
dir.browse().then(function(dir, items) {
  // ...
});

Y muchos dirán ¿qué diferencia hay entre ésto y el código que teníamos antes? Es sencillo, la diferencia está en quién maneja el callback. Con el código anterior cada función debía encargarse de comprobar si se le había pasado un callback válido y llamarlo al acabar su tarea con los argumentos necesarios. Ahora todo ése código está en la clase Promise y la función puede encargarse de aquello que le corresponde siempre que devuelva un promise y le notifique cuando termine. Finalmente la API queda bastante más clara:

Promise<Array<File>> Directory.browse();
Promise<String> File.getContent(String encoding);
Promise<Boolean> File.getPermission();

2 – Llamadas secuenciales

El promise trae una sorpresa que no me esperaba, el método then de la clase Promise devuelve un nuevo promise. Para qué? para poder ejecutar código secuencialmente, veamoslo:

var file = new File();
file.isReadable()
  .then(function(permission) {
    if (permission) {
      return file.getContent();
    }
})
.then(function(content) {
  // do something with the content
});

Qué es ésta locura? La idea es muy sencilla, pero es confusa porque la explicación utiliza demasiadas veces la palabra Promise, primero expandiremos el código para verlo más claro:

var file = new File();
var promise1 = file.isReadable();

var promise2 = promise1.then(function(permission) {
  if (permission) {
    var promise3 = file.getContent();
    return promise3;
  }
});

promise2.then(function(content) {
  // do something with the content
});

Debemos intentar seguirlo poco a poco, la llamada a llamada file.isReadable() nos devuelve promise1, y cuando llamamos al método then de promise1 nos devuelve promise2. Cuando promise1 termina se ejecuta el callback pasado y se descubre que el callback devuelve un nuevo Promise, promise3. Cuando promise3 se cumpla (es decir pase a estado “done”) también se cumplirá el promise2 ejecutando el callback que le han pasado. En resumen, podemos seguir añadiendo callbacks que se ejecutarán al acabar el anterior encadenando llamadas a then.

3 – Llamadas paralelas

Además me planteé añadir la posibilidad de manejar llamadas paralelas desde Promise, puesto que ya hemos visto lo complejo que puede ser. Para ésto añadí el método and al Promise:

File.get('http://www.somedomain.com/file1')
  .and(File.get('http://www.somedomain.com/file2'))
  .then(function() {
    // Both files loaded.
  });

Una vez más expandamos el código para ver más claramente que está sucediendo:

var promise1 = File.get('http://www.somedomain.com/file1');
var promise2 = File.get('http://www.somedomain.com/file2');
var promise3 = promise1.and(promise2);
promise3.then(function() {
  // Both files loaded.
});

Al expandirlo es más fácil ver lo que sucede, todo Promise tiene un método and al que se le pasa otro Promise, y ésto devuelve un nuevo Promise que se cumplirá cuando los dos primeros estén cumplidos.

4 – Callbacks específicos

Finalmente el patrón Promise también trae una mejora al problema de la gestión de errores, aún no lo he mencionado pero el método then recibe dos argumentos: el primero el callback que será llamado cuando el Promise se cumpla, el segundo otro callback que será llamado si la ejecución asíncrona falla:

File.get('http://www.somedomain.com/file2').then(function(file) {
  // do something with file.
}, function(error) {
  // Show blue screen of death
});

Esto nos permite separar claramente la responsabilidad de cada función y nos libera de la carga de comprobar errores.

CONCLUSION

Como vemos las llamadas secuenciales traen muchos inconvenientes, pero son principalmente consecuencias de no estar acostumbrados a la programación asíncrona, si lo estuviéramos tendríamos más en mente patrones como Promise que como vemos nos ayuda a afrontar una programación que ya de por sí es complicada. En próximos posts espero mostrar paso la implementación de una clase Promise, nos vemos en la próxima.