Aquellos que estén más familiarizados con la programación de plugins para jQuery, conocen de sobra el método $.extend() de esta biblioteca. Gracias a él, podemos definir una serie de valores por defecto para nuestras aplicaciones (objetos) que se sobreescriben solo en caso de que éstos se especifiquen a su inicialización.

Este tipo de comportamiento, que identificable con el concepto de herencia clásica en la POO, podemos obtenerlo también en nuestras aplicaciones sin necesidad de recurrir a bibliotecas de terceros.

Veamos una forma sencilla de crear un objeto con una serie de valores por defecto que pueden ser sobreescritos desde su propia API.

El método Extend

Lo primero que tenemos que hacer es crear una función que nos permita ‘extender’ fácilmente un objeto preexistente.

Para este ejercicio, vamos a considerar el extender la primitiva nativa Object de Javascript.

NOTA: Sobre el hecho de extender primitivas, se ha escrito mucho. Si no nos gusta esta vía, siempre podemos crear una función simple que nos haga el trabajo. Para ver las ventajas o problemas de cada uno de estos métodos, se recomienda la lectura del artículo “Extending Javascript Natives” del bueno de Angus Croll.

El código, muy simple, sería:

Object.prototype.extend = Object.prototype.extend || function(destination, source) {
  for (var property in source)
    destination[property] = source[property];
  return destination;
};

Con esto, hemos extendido a Object con un nuevo método extend. Este método aceptaría dos argumentos: el objeto destino (destination) que presumiblemente ya cuenta con una serie de valores establecidos y el objeto origen (source) que debe sobreescribir el anterior allí donde haya coincidencias.

El método anterior podríamos complicarlo mucho más con comprobaciones de todo tipo, pero para la intención de este artículo, con la funcionalidad indicada es suficiente: se trata de un bucle que recorre las propiedades del objeto source y las va escribiendo en el objeto destination. Finalmente, devuelve este último objeto ya modidificado.

Implementando el nuevo método

Tomemos ahora el siguiente escenario: estamos desarrollando una aplicación, biblioteca o plugin y necesitamos asignarle una serie de valores por defecto. Estos valores permiten mucha flexibilidad a la hora de configurar nuestra funcionalidad.

Por ejemplo:

var my App = function(){
 
  // Default settings
  var settings = {
    fullScreen : true,
    backgroundColor : '#000',
    speed : 20
    /* and so on... */
  };
 
};

Se trataría en este caso de ir añadiendo propiedades que más adelante necesitaremos que estén iniciadas con algún tipo de valor por defecto. En el código anterior, hemos incluido como ejemplo una opción para una supuesta pantalla completa, un color de fondo y algún parámetro de velocidad. Podría ser este el código inicial de un carrusel o un slideshow tradicional.

Tendríamos ahora que permitir mediante un API de esta biblioteca, que el usuario o desarrollador pudiera sobreescribir estos valores para configurar la herramienta a su gusto. Algo que permitiera, por ejemplo:

myApp({
  fullScreen : false,
  backgroundColor : '#FFF'
});

La idea sería modificar en tiempo de ejecución los valores por defecto anteriores para que tanto la propiedad fullScreen como backgroundColor tomasen los nuevos valores. Por omisión, speed conservaría su valor inicial.

Para implementar esta funcionalidad a través de nuestro nuevo método extend, solo tendríamos que hacer una pequeña modificación en el código de nuestra biblioteca-aplicación:

var myApp = function(customSettings){
  // Default settings
  var settings = {
    fullScreen : true,
    backgroundColor : '#000',
    speed : 20
    /* and so on... */
  };
 
  customSettings || ( customSettings = {} );
 
  Object.extend( settings, customSettings );
 
  /* Awesome more methods goes here */
 
  return settings; // Only for testing
 
};

Y ya lo tendríamos!

Nuestro objeto se inicia con una serie de valores por defecto, pero ahora, acepta además un argumento que se corresponde con las opciones introducidas por el desarrollador o usuario.

Estas customSettings extienden a las default settings modificando sus valores en tiempo de ejecución. El return no sería necesario en una aplicación real, pero para este ejercicio permite ver cómo hemos efectivamente modificado los valores iniciales.

Podemos comprobarlo si ahora ejecutamos el ejemplo anterior:

var test = myApp({
  fullScreen : false,
  backgroundColor : '#FFF'
});
 
console.log(test);

El resultado que obtenemos son nuestras opciones de configuración modificadas salvo en aquellos casos en los que, por omisión, se mantienen las establecidas por defecto. Cualquier método a partir de ahí en nuestra aplicación podría disponer de estos valores para realizar las operaciones y funcionalidades oportunas.

Conclusión

Con esta sencilla fórmula, podemos crear aplicaciones muy flexibles que permitan un alto grado de configuración. Se trata del mismo principio aplicado a muchas bibliotecas de terceros como pueden ser, por ejemplo, los plugins de jQuery.

this es un valor complejo en Javascript; un error en el diseño del lenguaje susceptible de causar tanto comportamientos inesperados como potentes estructuras de código reutilizable. Su valor, lejos de ser intuitivo, se determina según la forma en que se invoque a la función que lo encierra, algo que no siempre es correctamente entendido o aprovechado.

Dado que el correcto manejo de this resulta esencial en la programación orientada a objetos, y en definitiva en el desarrollo moderno de aplicaciones, es interesante dedicar unos minutos a revisarlo.

Qué es exactamente this

La palabra clave this tiene en Javascript un comportamiento diferente al de otros lenguajes pero por lo general, su valor hace referencia al propietario de la función que la está invocando o en su defecto, al objeto donde dicha función es un método.

La palabra clave del párrafo anterior es “propietario“.

Cuando no estamos dentro de una estructura definida, esto es un objeto con métodos, el propietario de una función es siempre el contexto global. En el caso de los navegadores web, tenemos que recordar que dicho objeto es window:

console.log( this === window );  // true
 
function test(){
  console.log( this === window);
}
 
test(); // true

Accediendo a los valores de un objeto desde el propio objeto

Este concepto de propietario puede inducir a errores. Pensemos en un objeto con una serie de propiedades:

var myApp = {
  name : 'Megan',
  lastName : 'Fox',
  birthDate : '16/05/1986',
  isPretty : true
};
 
console.log( myApp.name ); // Megan
console.log( myApp.isPretty ); // true

Supongamos ahora que necesitamos otra propiedad más ‘dinámica’ que participe de los valores asignados a cualquier otra. Por ejemplo, queremos un ‘completeName‘ que concatene ‘name‘ y ‘lastName‘. Parece que este un claro ejemplo de uso para this:

var myApp = {
  name : 'Megan',
  lastName : 'Fox',
  completeName : this.name + this.lastName
}

Aunque parece coherente, cuando pasamos a comprobarlo vemos que el resultado no es el esperado:

console.log( myApp.completeName ); // undefined

El problema aquí es que this no está apuntando al objeto como cabría esperar, sino que está buscando la referencia fuera, en el contexto global (window).

Para obtener el resultado esperado tenemos que aplicar un patrón de invocación que modifique al propietario desde el que se invoca el this…

Patrón de invocación por método

En Javascript, existen varias formas de llamar a las funciones desde nuestro código; concretamente, podemos enumerar hasta cinco diferentes. La elección de una u otra responde al flujo de nuestro programa pero básicamente, difieren en el contexto que queramos aplicar a cada una. O lo que es lo mismo, al valor que queramos que la función asigne a la referencia this.

En el desarrollo de aplicaciones modernas, el patrón más recurrente es el de invocación por método: una función es almacenada como propiedad de un objeto convirtiéndose así en lo que denominamos un método.

Cuando llamamos (invocamos) a un método, this hace refencia al propio objeto:

var myApp = {
  name : 'Megan',
  lastName : 'Fox',
  completeName : function(){
    return this.name + ' ' + this.lastName;
  }
}
 
console.log( myApp.completeName() ); // Megan Fox

En esta ocasión, si podemos comprobar como this apunta al propio objeto y busca la propiedades ‘name‘ y ‘lastName‘ dentro en lugar de remontarse hasta el contexto global.

Pero como vimos en el caso anterior, no siempre el uso de this es intuitivo. Consideremos la siguiente estructura:

var myApp = function(){
  var name = "World"
  var sayHello = function(){
    console.log( 'Hello, ' + this.name );
  };
  sayHello(); // Invoke the function
};
 
myApp(); // Hello,

¿A dónde está apuntando this en este caso? Como la función no es ahora la propiedad de un objeto, this apunta de nuevo al global (window). Esto es un error en el diseño del lenguaje ya que, de comportarse como se espera, this debería apuntar a la función contenedora (que no deja de ser su propietaria).

Este comportamiento lo podemos comprobar si creamos una variable global con aquel nombre por el que estamos preguntando:

var name = "Strange World";
var myApp = function(){
  var name = "World"
  var sayHello = function(){
    console.log( 'Hello, ' + this.name );
  };
 
  sayHello();
 
};
 
myApp(); // Hello, Strange World

La consecuencia de este error es que un método no puede utilizar funciones internas que la ayuden a hacer su trabajo porque éstas, no tiene acceso a sus propiedades.

Para resolver este problema, podemos recurrir a una solución muy simple: definir dentro de nuestra función contenedora una nueva variable que cachee el valor de this para que así esté disponible desde cualquier otra función anidada que lo precise. Por convención, el nombre de esta variable es that:

var myApp = function(){
  var that = this; // Work around!
  var name = "World"
  var sayHello = function(){
    console.log( 'Hello, ' + that.name );
  };
 
  sayHello();
};
 
myApp(); // Hello, World

NOTA: Últimamente, la convención que propuso Douglas Crockford está siendo revisada y son muchos los desarrolladores que prefieren el término self para referirse al objeto cacheado.

Sobreescribiendo el valor de this en tiempo de ejecución

Una de las características consideradas avanzadas dentro del lenguaje Javascript es la posibilidad de reescribir el valor de this en tiempo de ejecución consiguiendo así una modularidad y reusabilidad extrema.

Más arriba comentamos que existen varias formas de invocar funciones en Javascript donde la elección entre una u otra depende del valor que queramos asignar a this.

Consideremos el siguiente codigo:

var person1 = {
  name : 'Angelina',
  lastName : 'Jolie',
  birthDay : '04/06/1975',
  lastMovie : 'The Tourist'
};
 
var person2 = {
  name : 'Scarlett',
  lastName : 'Johansson',
  birthDay : '22/11/1984',
  lastMovie : 'We bought a Zoo'
}
 
var printName = function(){
  console.log( this.name + ' ' + this.lastName );
}

Si tratamos de ejecutar sin más la función printName, ya sabemos que el this apunta al objeto global window e irá ahí a buscar las propiedas name y lastName.

En una arquitectura modular, lo ideal es que esa función pueda ser reaprovechada y que nos permita imprimir los datos de cualquier objeto que cumpla con los requisitos. Para ello, podemos cambiar el valor de this en tiempo de ejecución con el fin de que apunte a ese objeto en cuestión. Para ello, contamos con las funciones nativas apply y call:

printName.call( person1 ); // Angelina Jolie
printName.call( person2 ); // Scarlett Johansson
 
printName.apply( person1 ); // Angelina Jolie
printName.apply( person2 ); // Scarlett Johansson

El resultado es el mismo: hemos ejecutado la función printName dentro del contexto de cada uno de los objetos que hemos pasado como argumento.

La diferencia entre cada uno de estas funciones es que la segunda de ellas, apply, acepta un array como argumento, lo que permite una flexibilidad aún mayor a la hora de plantear código reusable.

Pensemos en una función que nos permita actualizar datos dentro de nuestros objetos:

var updatePerson = function(name, lastName, birthDay, lastMovie){
  this.name = name;
  this.lastName = lastName;
  this.birthDay = birthDay;
  this.lastMovie = lastMovie;
}
 
updatePerson( person1, 'Angelina', 'Jolie', '04/06/1975', 'Kung Fu Panda 2');

Las limitaciones de call se hacen rápidamente evidentes cuando queremos escribir código que no conoce (o no debe conocer) el número de argumentos que la función necesita.

Tomemos por ejemplo una función que siga el conocido paradigma del ‘dispatcher‘:

var dispatch = function(person, method, args){
  method.apply( person, args );
}
 
dispatch( person1, printName );
dispatch( person2, update, ['Scarlett', 'Johansson', '22/11/1982', 'The Avengers'] );

En este caso, el poder jugar con el valor de this y además asociar una serie de datos a través de un array, permite una poderosa flexibilidad a la hora de escribir código reutilizable.

Conclusión

El valor de this ha sido siempre difícil de manejar en Javascript. Las pequeñas diferencias que presenta frente a otros lenguajes así como un error en su diseño, lo hacen francamente especial. Sin embargo, esa peculiaridad, es precisamente la que permite crear un tipo de código muy versátil una vez que conocemos sus secretos.

Manejarlo correctamente es una parte esencial dentro del desarrollo de aplicaciones complejas en Javascript.

Preparando una aplicación basada íntegramente en canvas me topé con el blog del Proyecto Cyan, un interesante proyecto en español sobre la elaboración videojuegos en Javascript a través de un framework propio que han bautizado como piNgine.

Entre sus diversos y recomendables artículos, uno de los primeros trata sobre la medición del rendimiento de un objeto canvas según el número de FPS (imágenes por segundo) que es capaz de gestionar. Como es bien sabido en la industria del videojuego, éste es un valor esencial a la hora de buscar cuellos de botella y zonas pesadas que son susceptibles de mejorar.

Cómo va eso de los FPS

Cuando estamos trabajando con entornos gráficos, como puede ser el caso del canvas, las operaciones de redibujado son constantes: la sensación de animaciones o desplazamientos se resuelven mediante un ciclo de limpiado y renderizado de las zonas afectadas.

Este proceso conlleva un coste y es mesurable. Los FPS vienen a indicar la cantidad de veces que una zona, generalmente el viewport (la pantalla completa) se redibuja por segundo.

Suele considerarse que una tasa óptima está alrededor de los 40 fps. Valores por debajo de los 20-15 indican sobrecarga y deberían ser objeto de atención para un posible optimizado (reduciendo el número de objetos visibles, modificando el algoritmo de compresión, etc…).

Midiendo los FPS en un canvas

Para realizar esta medición, solo necesitamos aplicar una rutina que realice un conteo de los refrescos del objeto canvas sobre el que estamos trabajando.

Para facilitar la reutilización, lo ideal es crear un objeto que podamos cargar con un JS externo y que nos permita iniciarlo a voluntad para controlar los valores que arroje.

Me he permitido tomar el código de piNgine al que he realizado algunas modificaciones.

Su API es sumamente sencilla. Para comenzar el conteo, únicamente debemos iniciar el objeto:

fpsCounter.init( [ canvasID ] );

Donde:
- canvasID (opcional) es el ID del objeto que deseamos monitorizar. Si omitimos este valor, el objeto busca un canvas con ID canvas (el más frecuente).

NOTA: He decidido que el objeto no busque los objetos canvas automáticamente en el DOM porque existen técnicas muy extendidas como los buffers que crean falsos canvas de sustitución para actuar como zonas de prerenderizado. Aplicar el conteo de FPS sobre esas zonas no tendría sentido por lo que es el desarrollador el que debe proporcionar el ID del objeto que desea estudiar.

El código es el siguiente:

var fpsCounter = ( function(){
 
  console.log('Modulo de FPS cargado...');
 
  // FPS máximos a los que queremos que se ejecute la aplicación.
  var maxfps = 32;
 
  // Variables necesarias para el recuento de FPS y el cálculo del delay.
  var frameCount = 0,
      currentFps = 0,
      drawInterval = 1 / maxfps * 1000,
      lastFps = new Date().getTime();
 
  // Variables para almacenar las referencias al elemento canvas.
  var canvas = null,
      ctx = null;
 
  // Método que utilizamos como constructor.
  var initCore = function( canvasID ){
    console.log('Inciando el contador de FPS...');
 
    // Cargamos el objeto canvas y su contexto
    canvas = document.getElementById( ( canvasID ) ? canvasID : 'canvas' );
 
    if ( canvas && canvas.getContext ){
      ctx = canvas.getContext('2d');
      // Inicializamos el intervalo a los FPS deseados.
      setInterval( function(){ startApp(); }, drawInterval );
    }else{
      console.warn('Objeto canvas no encontrado o navegador no soportado!');
    }
 
  };
 
  var startApp = function(){
    // Actualizamos y enviamos la petición de pintado.
    update();
    draw();
  };
 
  var update = function(){
    // Calculamos el tiempo desde el último frame.
    var thisFrame = new Date().getTime(),
        diffTime = Math.ceil((thisFrame - lastFps));
 
    if (diffTime >= 1000) {
      currentFps = frameCount;
      frameCount = 0.0;
      lastFps = thisFrame;
    }
 
    frameCount++;
 
  };
 
  var draw = function(){
    // Pintamos los datos en el canvas
    ctx.clearRect( 0, 0, canvas.width, canvas.height );
    ctx.save();
    ctx.fillStyle = '#000';
    ctx.font = 'bold 10px sans-serif';
    ctx.fillText( 'FPS: ' + currentFps + '/' + maxfps, 10, 15 );
    ctx.restore();
  };
 
  return{
    init : initCore
  }
 
} )();

NOTA: Durante el código, se realizan algunas llamadas a la consola (console.log); si nuestro navegador no dispone de esa funcionalidad, solo tenemos que comentar aquellas líneas en las que aparezca esa referencia.

Para aplicar este script, podemos crear una sencilla página de prueba:

<!doctype html>
<html lang="es">
<head>
  <title>Contador FPS</title>
  <script type="text/javascript" src="/js/fpsCounter.js"></script>
</head>
<body>
<canvas id="canvas" width="200px" height="200px" style="border:1px solid #000;">
  <p>¡Explorador no compatible!</p>
</canvas>
<script type="text/javascript">
fpsCounter.init();
</script>
</body>
</html>

Podemos ver el resultado aquí.

Si leemos el código, hemos establecido una tasa máxima de FPS por segundo:

var maxfps = 32;

Este valor es muy útil para garantizar que nuestra aplicación corre a la misma velocidad máxima con independencia de la potencia de la plataforma sobre la que la ejecutemos. Un valor de 32 suele ser suficiente pero, como hemos comentado anteriormente, podemos escoger otros más altos si necesitamos una mayor fluidez.

Por defecto, los FPS se muestran en la parte superior del canvas; si queremos cambiar esta localización, solo tendremos que tocar la función draw().

Conclusión

Sin duda, esta rutina puede resultar muy útil mientras trabajamos con canvas o estamos pensando en portar un proyecto al interesante sistema WebGL. Controlar la tasa de refresco es importante para identificar problemas de rendimiento y ponernos en sobre aviso.

En el post anterior revisamos los nuevos métodos on() y off() de la versión 1.7 de jQuery, sin duda, una de las innovaciones más interesantes.

Siguiendo con el estudio de esta versión, nos toca ahora echarle un vistazo a otra importante novedad: el objeto $.Callbacks().

Básicamente, $.Callbacks ofrece un completo stack (conjunto de elementos) donde definir una serie de funciones que serán ejecutadas en secuencia como resultado de una determinada condición o acción previa.

Como la explicación puede resultar confusa, comencemos con un ejemplo para ir luego avanzando con cada uno de los métodos que ofrece este nuevo elemento:

Ejemplo de $.Callbacks

Tenemos dos funciones como las siguientes:

var fn1 = function( myStr ){
  console.log( 'Fn1 says: ', myStr );
}
 
var fn2 = function( myStr ){
  console.log( 'Fn2 says ', myStr );
}

Bien; nada complejo: dos funciones simples que reciben un argumento para pintarlo en la consola. Ahora, asociemos ambas funciones al nuevo objeto $.Callbacks para crear una pila o cola de ejecución con ellas:

var stack = $.Callbacks();
stack.add( fn1 );
stack.fire( 'Hello World' ); // Fn1 says: Hello World
 
stack.add( fn2 );
stack.fire( 'Goodbye Lenin' ); // Fn1 says: Goodbye Lenin, Fn2 says: Goodbye Lenin

Como podemos comprobar, hemos utilizado dos métodos que prácticamente hablan por si mismos: add() y fire(). El primero, se encarga de añadir una función al stack o pila mientras que el segundo, fire(), se encarga de ejecutar dicha pila a la vez que permite que enviemos argumentos a la misma.

Junto a estos dos métodos, contamos con un tercero también básico: remove(), el cual permite, como su nombre indica, borrar una referencia determinada de nuestra lista. Su uso es igual de simple:

var double = function( myVal ){
  if( $.isNumeric( myVal ) ){
    console.log( myVal * 2 );
  }else{
    console.log( myVal, ' is not Numeric!' );
    return false;
  }
}
var triple = function( myVal ){
  if( $.isNumeric( myVal ) ){
    console.log( myVal * 3 );
  }else{
    console.log( myVal, ' is not Numeric!' );
    return false;
  }
}
 
var stack = $.Callbacks();
stack.add( double );
stack.fire( 5 ); // 10
stack.fire( 'foo' ); // foo is not Numeric!
 
stack.add( triple );
stack.fire( 10 ); // 20, 30
stack.fire( 'bar' ); // bar is not Numeric!
 
stack.remove( double );
stack.fire( 2 ); // 6

Lo primero es comentar el uso de otra de las nuevas funcionalidades de jQuery 1.7: la función isNumeric(). Con ella comprobamos si un determinado valor se corresponde con un valor numérico, independientemente de que se le pase como entero o cadena:

console.log( $.isNumeric(5) ); // true
console.log( $.isNumeric('10') ); // true
console.log( $.isNumeric('one') ); // false
console.log( $.isNumeric(NaN) ); // false

NOTA: la última comprobación puede resultar confusa ya que para Javascript, NaN se corresponde con un valor númerico. jQuery, sin embargo, considera que NaN no se corresponde con un número.

Volviendo al ejemplo anterior, vemos como remove() suprime una determinada función del stack. Pero si en lugar de una concreta, quisiéramos eliminar todas las funciones que hayamos incluído en nuestra pila, contamos con el método empty() para vaciarla de forma inmediata:

stack.empty();
console.log( stack.has( triple ) ); // false

NOTA: El método has() lo revisaremos más adelante en este mismo artículo.

Separando pilas

Dado que, como hemos visto en los ejemplos anteriores, las pilas se asocian a variables, podemos tener varios entornos de forma simultánea.

var calcDouble = $.Callbacks();
var calcTriple = $.Callbacks();
 
calcDouble.add( double );
calcTriple.add( triple );
 
calcDouble.fire( 10 ); // 20
calcTriple.fire( 20 ); // 60

Con esto, podemos tener varias colas o listas de ejecución independientes.

Otros métodos

Además de add, fire y remove, $.Callbacks soporta otros métodos que pueden resultar muy interesantes:

fireWith(): con este método, se puede especificar el contexto y los argumentos que se pasamos a la pila:

var sum = function(){
  var result = 0;
  for( var x=0, i=arguments.length; x < i; x++){
    result += arguments[x];
  }
 
  console.log( result );
}
 
var stack = $.Callbacks();
stack.add( sum );
 
stack.fireWith( window, [2, 5, 10, 3] ); // 20

En el ejemplo anterior, hemos creado una función sum que devuelve la suma de todos aquellos valores que se le pasan como argumentos. Para ejecutarla desde nuestra pila, hemos utilizado el fireWith pasándole como contexto window y como argumentos un array con diversos valores.

Tenemos que tener en cuenta aquí que lo que recibe la función sum no es el array, sino que cada uno de los valores que hemos indicado se correspondería con un argumento en nuestra función:

var sum = function(/* arg1, arg2, arg3, ... */){
  //...
}

has(): este método sirve para determinar si una función concreta forma parte de nuestra pila.

var fn1 = function(){
  console.log( 'Hello World' );
};
var fn2 = function(){
  console.log( 'Goodbye Lenin' );
};
 
var stack = $.Callbacks();
stack.add( fn1 );
 
console.log( stack.has( fn1 ) ); // true
console.log( stack.has( fn2 ) ); // false

fired(): este método determina si una determinada lista ha sido ejecutada al menos una vez:

var foo = function( value ){
  console.log( 'foo:' + value );
}
 
var stack = $.Callbacks();
stack.add( foo );
 
stack.fire( 'hello' ); // foo: hello
stack.fire( 'world '); // foo: world
 
console.log( stack.fired() ); // true

disable(): este método inutiliza la lista e impide la ejecución de la misma en futuras llamadas:

var foo = function( value ){
  console.log( value );
}
 
var stack = $.Callbacks();
stack.add( foo );
 
stack.fire( 'foo' ); // foo
 
stack.disable();
 
stack.fire( 'foobar' ); // foobar isn't output so nothing is printed

lock() y locked(): el primer método bloquea la lista para impedir que pueda ser modificada de forma dinámica desde el interior de la misma. El segundo método comprueba si la lista ha sido bloqueada devolviendo un valor booleano.

Indicadores

El objeto $.Callbacks() soporta además indicadores o flags que determinan el comportamiento de la lista. Estos indicadores se especifican al iniciar el objeto y se corresponden con una serie de palabras reservadas separadas por comas. Los posibles valores son:

• once: especifica que la lista solo se ejecutará una vez (igual que Deferred).
• memory: al igual que en Deferred, los valores previos se memorizan por lo que a cada llamada de la lista, éstos se tienen en cuenta.
• unique: asegura que las funciones que forman una lista, solo se pueden incluir una vez evitando duplicados.
• stopOnFalse: interrumpe la pila de ejecución cuando alguna de las funciones devuelve un valor false.

Algunos ejemplos:

var fn1 = function( str ){
  console.log( 'Fn1 says: ' + str );
};
 
var fn2 = function( str ){
  console.log( 'Fn2 says: ' + str );
};
 
var callbacks = $.Callbacks( "memory" );
 
callbacks.add( fn1 );
callbacks.fire( "foo" );
 
callbacks.add( fn2 );
callbacks.fire( "bar" );
 
// Fn1 says: foo
// Fn2 says: foo
// Fn1 says: bar
// Fn2 says: bar

En el caso anterior, aunque fn2 no estaba incluida en la lista antes de la primera ejecución (fire), al si estarlo más adelante en el código, funciona devolviendo el valor ‘memorizado’ en fn1.

var fn1 = function(){
  console.log( 'Hello World' );
}
 
var stack = $.Callbacks( 'unique' );
stack.add( fn1 );
stack.fire(); // Hello World
 
stack.add( fn1 ); // repeat addition
stack.fire(); // Hello World --> only once

Aunque hemos incluido un par de veces la función fn1, gracias al indicador unique ésta solo se ejecuta una vez.

var fn1 = function(){
  console.log( 'Hello World' );
  return false;
};
 
var fn2 = function(){
  console.log( 'Goodbye Lenin' );
};
 
var stack = $.Callbacks( 'stopOnFalse' );
stack.add( fn1, fn2 );
stack.fire(); // Hello World

En esta ocasión, aunque dentro de nuestra lista estarían definidas las funciones fn1 y fn2, al devolver la primera un false y habiendo especificado el indicador stopOnFalse, la ejecución se interrumpe inmediatamente.

Para definir más de un indicador al mismo tiempo, solo tenemos que separarlos con espacios:

var stack = $.Callbacks( 'unique stopOnFalse' );

Conclusión

Pues esto es todo; un nuevo objeto jQuery con el que contar en nuestro inventario para programar callbacks de forma precisa.

Con la llegada de jQuery 1.7, se han solucionado varios bugs que esta biblioteca arrastraba de versiones anteriores; también se ha mejorado una vez más el rendimiento general de la misma prestándose especial atención a selectores y a la portabilidad a los dispositivos móviles.

Pero además de estos ‘arreglos’, tenemos nuevos métodos y nuevas funcionalidades interesantes. De entre los primeros, sin duda los más interesantes son los que se refieren a la nueva gestión de eventos: el corazón de jQuery.

Los eventos en jQuery

Desde su aparición, jQuery se ha caracterizado por la flexibilidad con la que el desarrollador puede efectuar selecciones de elementos dentro del DOM y por la facilidad para asociar eventos a cada uno de esos conjuntos seleccionados.

Sin embargo, un problema con el que han tenido que lidiar los chicos del jQuery Team es que, con el paso de las versiones, estos manejadores (handlers) se han multiplicado hasta resultar confusos en las últimas releases.

Al principio, solo disponíamos del viejo método bind con el que asignábamos un determinado evento a un objeto jQuery:

$('mySelector').bind('click', function(){
  // The callback goes here...
})

Para aquellos eventos muy frecuentes, como en el caso del click anterior, contábamos incluso con prácticos atajos (shortcuts):

$('mySelector').click( function(){
  // The callback goes here...
});

El problema de bind es que solo funciona con aquellos elementos del DOM que ya están presentes cuando la función se ejecuta. Es decir, aquellos otros elementos que pudieran añadirse de forma dinámica, no heredan este comportamiento.

Para solventar este problema, apareció en escena el método live(). Sin embargo, live presentaba más problemas que ventajas y rápidamente se consideró obsoleto (deprecated). El problema con este método proviene de su bajo rendimiento en estructuras complejas y de algunos comportamientos impredecibles que se dan en determinados escenarios. Para un completo artículo sobre el porqué no debemos usar jQuery live, podemos leer un artículo escrito hace algún tiempo en este blog sobre ese respecto.

Buscando una vía alternativa al uso de live, jQuery ofreció un nuevo método muy similar: delegate(). Hasta el momento, delegate ha tratado de cubrir la funcionalidad de asociar eventos a elementos DOM pero, de nuevo, el resultado no ha sido todo lo satisfactorio que cabría esperar.

Es por todo esto que, frente a la confusión por parte del desarrollador de encontrarse tantos métodos similares (bind, live, delegate, one, …), el jQuery Team ha decidido crear dos nuevos métodos que aúnen el comportamiento de todos ellos buscando el máximo rendimiento y minimizando la confusión: on() y off().

El método on()

El objetivo de on() es reemplazar a los antiguos bind, live y delegate. Su sintaxis es la siguiente:

$(elements).on(events [, selector] [, data], handler);

Donde:

• events son los eventos que se buscan asociar al conjunto de elementos seleccionados. La novedad aquí es que pueden asociarse más de un evento separándolos con espacios. Por ejemplo: ‘click’, ‘click blur’.
• selector especifica los descendientes de los elementos seleccionados que dispararán el evento. Se trata de un parámetro opcional.
• data indica cualquier tipo de datos que se necesite pasar al manejador cuando se dispara el evento. Es también un parámetro opcional y, por lo general, se corresponde con un objeto jQuery.
• handler se corresponde con el callback o acción a realizar después de que el evento se dispare.

Un ejemplo de uso completo puede ser el siguiente:

$('#myContainer .item').on({
  click: function() {
    event.preventDefault();
    console.log('item clicked');
  },
  mouseenter: function() {
    console.log('enter!');
  }
});

El resultado del código anterior es que hemos asociado dos eventos diferentes, con dos callbacks diferentes a aquellos elementos DOM que cumplan con el criterio de la selección (en este caso aquellos con la clase ‘item’ descendientes de un ID ‘myContainer’). Como hemos comentando más arriba, al reemplazar a live() y delegate(), este comportamiento será heredado por cualquier otro elemento que se inserte en el DOM de forma dinámica aún después de haber sido ejecutada la función anterior.

Actualizaciones desde métodos antiguos

Actualizar nuestros viejos códigos a la nueva versión resulta por lo general sencillo:

// Old live() style:
$('#myContainer .item').live('click', function(event) {
  event.preventDefault();
  console.log('item clicked');
});
 
// New on() style:
$('#myContainer').on('click', '.item', function(event) {
  event.preventDefault();
  console.log('item clicked');
});

En el ejemplo anterior hemos visto además, como se asocian selectores dentro del propio cuerpo de la función para especificar aquellos descendientes que dispararán el evento.

// Old delegate() style:
$('#myContainer').delegate('.item', 'click', function(event) {
  event.preventDefault();
  console.log('item clicked');
});
 
// New on() style:
$('#myContainer').on('click', '.item', function(event) {
  event.preventDefault();
  console.log('item clicked');
});

En el caso de la actualización desde delegate, solo necesitamos cambiar el orden de los parámetros.

El método off()

Al igual que con la asocación de eventos, la confusión de métodos también llegaba con la acción contraria: eliminarlos.

Para esta acción, contábamos con varios métodos como unbind(), die() o undelegate(). De nuevo, el objetivo principal de la nueva instrucción es reemplazarlos a todos de un modo consistente.

La sintaxis de off() resulta similar a la de on():

$(elements).off( [ events ] [, selector] [, handler] );

Con off(), todos los parámetros son opcionales. Cuando se utiliza en su forma más simple, $(elements).off(), se eliminan todos los eventos asociados al conjunto seleccionado.

Actualizaciones desde métodos antiguos

Como en el caso anterior, dependiendo de qué método vengamos, la conversión presenta más o menos cambios.

Para el caso de unbind(), solo necesitamos cambiar el nombre del método:

// Old unbid() style:
$('#container a').unbind('click');
 
// New off() style:
$('#container a').off('click');

Para aquellos códigos que hagan uso del live() / die(), el cambio es similar:

// Old die() style:
$('#container a').die('click');
 
// New off() style:
$('#container').off('click', 'a');

De nuevo, solo es necesario organizar ligeramente el orden de los parámetros para aprovechar la nueva potencia del método off().

Para la portabilidad desde undelegate(), solo tenemos que cambiar el orden de los parámetros:

// Old undelegate() style:
$('#container a').undelegate('a', 'click');
 
// New off() style:
$('#container a').off('click', 'a');

Conclusión

Con la nueva versión 1.7 de jQuery, se trata por fin de poner algo de orden en cuanto al manejo de eventos que ofrece esta biblioteca, aunando en unos mismos métodos toda la funcionalidad que hasta la fecha se había ido desplegando en varios.

Con esto, el resultado es un API más robusto y sólido, exactamente lo que los desarrolladores jQuery han solicitado al equipo de desarrollo.

Siguiendo en la línea de los artículos que @ialcazar considera como ‘esos que despiertan conciencias‘, he querido traer ahora un escrito original de Lawrence Wenham donde desarrolló un listado de signos (con sus síntomas y remedios) que identificarían a los malos desarrolladores.

El objetivo de este artículo no es otro sino el de motivarnos a continuar aprendiendo ya que es perfectamente aplicable a cada uno de nosotros en el momento de enfrentarnos a una nueva tecnología. Me gusta aquí recordar como Rober Martin siempre aconseja que, para mejorar como desarrolladores, tenemos que salirnos frecuentemente de nuestra zona de confort, buscando nuevos retos en lenguajes que supongan un paradigma radicalmente opuesto al que manejamos en nuestro día a día.

Si decidimos dar el salto del paradigma imperativo al declarativo, podemos necesitar de algún tipo de rasero que nos indique si ya estaríamos preparados para aplicar los nuevos conocimientos a un entorno real de producción.

Veámos cuáles podrían ser los síntomas de si hemos o no comprendido lo que tenemos entre manos…

1. Incapacidad para razonar sobre un código dado

Incapacidad para razonar un código significa que no podemos seguir mentalmente el hilo de ejecución aún sabiendo su finalidad. Es decir, deberíamos contar con la habilidad de ejecutar un programa en nuestra cabeza sin necesidad de recurrir al compilador o intérprete.

Síntomas

• Presencia de códigoue no tiene ningún efecto sobre el objetivo final de un programa pero que se continúa manteniendo. Por ejemplo, hablamos de variables que se inician pero nunca se utilizan, llamadas a funciones que resultan irrelevantes para el objetivo final, valores de salida que no se utilizan, etc…
• Reiteradas llamadas a un mismo bloque de código (por ejemplo, llamar a una función save() varias veces únicamente para estar seguros).
• Reparar errores escribiendo código que sobreescribe ese resultado erróneo. Por ejemplo, en lenguajes de tipado blando, si detectamos que una variable que debería contener un entero contiene una cadena, reescribimos su valor asignándole cero.
• Código yo-yo que convierte un valor algo diferente para un cubrir un paso concreto de ejecución y luego retoma el valor original. Por ejemplo, convertir un valor decimal en una cadena, operar sobre él, y luego devolverlo a su forma decimal inicial.
• Código bulldozer que da la impresión de refactorizar alguna estructura pero que, en realidad, resulta imposible de reutilizar fuera de su propio contexto.

Remedios

Para superar estas deficiencias, un programador debe practicar usando un buen IDE junto a su debugger favorito; esto le permitirá avanzar por un código paso a paso de modo que pueda seguir fácilmente su hilo de ejecución. Esto significa por ejemplo crear puntos de ruptura y monitorizar el valor de determinadas variables antes y después de cada cambio hasta entender qué es lo que está haciendo el código.

El objetivo es alcanzar ese punto donde podríamos fácilmente leer un código, identificar duplicados o estructuras innecesarias. Además de esto, mejoraremos la habilidad de detectar y corregir errores sin tener que reescribir todo desde cero por el simple hecho de que no sabemos leer lo existente.

2. Comprensión pobre del modelo de programación de un determinado lenguaje

La Programación Orientada a Objetos (POO u OOP) es un ejemplo de modelo de lenguaje, como lo es la programación funcional o declarativa. Éstos poseen a su vez diferencias significativas con otros paradigmas como el imperativo, del mismo modo en el que, por ejemplo, la programación estructural es muy diferente del ensamblador o de una programación basada en GOTO.

Existen lenguajes que se adscriben a un determinado modelo (como por ejemplo la POO) pero que presentan sus propias mejoras (features) sobre los mismos.

Síntomas

• Usar la sintaxis que sea necesaria para romper el modelo de un lenguaje y poder así escribir código que nos resulte más familiar.
• (POO) Tratar de llamar a funciones no estáticas o variables en clases no instanciadas y no ser capaces de comprender el porqué no funcionan como esperamos.
• (POO) Escribir varias clases del tipo ‘xxxManager’ que contengan cada una todos los mismos métodos de manipulación (aún con ligeras variaciones entre ellos).
• (Relacional) Tratar una base de datos relacional como un mero objeto de almacenaje sobre el que luego realizaremos todas las relaciones, uniones, concatenaciones o filtrados en el lado del cliente.
• (Funcional) Crear varias versiones del mismo algoritmo para manejar diferentes tipos u operadores en lugar de pasar funciones de alto nuvel a una implementación genérica.
• (Funcional) Cachear manualmente los resultados de una función determinista en una plataforma que puede hacerlo de forma automática (como por ejemplo SQL y Haskell).
• Recurrir al copiar y pegar desde el código de otro programa para lidiar con I/O y Mónadas.
• (Declarativo) Asignar valores individuales en código imperativo en lugar de usar un data-binding.

Remedios

Si la deficiencia de tus habilidades se debe a un aprendizaje o estudio inefectivo, entonces el remedio es tan sencillo como repasar los conceptos y profundizar en la especificación del lenguaje. No existe una forma más efectiva para aprender el modelo de un determinado lenguaje que iniciar un nuevo proyecto y obligarte a ti mismo a usar cada una de sus características, ya sean de forma inteligente o no. Incluso podemos crearnos un nuevo vocabulario con el que referirnos coloquialmente a cada una de esas nuevas funcionalidades para así asimilarlas de una forma más natural. Por ejemplo:

• Fase 1: POO son solo registros con métodos.
• Fase 2: los métodos POO son solo funciones que ejecutan un mini programa con sus propias variables globales.
• Fase 3: Las variables globales se llaman campos, algunos de los cuales pueden ser privados e invisibles desde fuera del mini programa.
• Fase 4: La idea de tener elementos privados y públicos es esconder la implementación de los detalles y mostrar una interfaz más limpia. Y esto es la encapsulación.
• Fase 5: Encapsulación significa que la lógica de mi negocio no necesita de los detalles de la implementación para funcionar.

Otro ejemplo para programación funcional:

• Fase 1: Programación funcional significa hacerlo todo encadenando funciones deterministas.
• Fase 2: Cuando las funciones son deterministas, el compilador puede predecir cuándo puede cachear un resultado, saltarse una evaluación o cuando es seguro detener una evaluación de forma prematura.
• Fase 3: Para poder soportar Evaluaciones parciales o perezosas, el compilador necesita que las funciones estén definidas en términos de cómo transformar un simple parámetro en otra función. A esto lo llamamos Currying.
• Fase 4: Algunas veces, el compilador puede hacer Currying por mi.
• Fase 5: Al permitir al compilador trabajar en los detalles, yo puedo escribir programas que describan qué es lo que quiero en lugar del cómo.

3. Habilidades deficiente para investigar / Conocimiento pobre de las características de la plataforma

Los lenguajes modernos y los frameworks suelen venir con una increible cantidad de recursos y funcionalidades ya preparados para su uso. Plataformas como Java, .NET o Cocoa poseen listados tan largos que incluso un desarrollador con experiencia puede tardar años en asimilarlos. Sin embargo, un buen programador sabrá buscar una función preconstruida para cubrir una necesidad antes de lanzarse a programar una desde cero.

Síntomas

Éstos son solo indicativos del problema si éste persiste en el tiempo más allá de una fase razonable de aprendizaje.

• Reinventar or crear estructuras básicas que ya están presentes en el lenguaje de forma nativa.
• Reinventar clases y funciones que ya están presenten en un framework de forma nativa.
• Correos continuos del tipo ‘Enviame el código, por favor’ a los foros de ayuda.
• Solucionar una tarea aplicando un mayor número de funciones del que sería necesario si conocemos el lenguaje.
• Usar de forma persistente técnicas antiguas cuando éstas han sido reemplazadas por otras modernas y más efectivas. Por ejemplo, continuar utilizando funciones delegadas en lugar de usar expresiones lambda.
• Permanecer constantemente en nuestra zona de confort y resolver así problemas complejos utilizando primitivas.

Remedios

Un programador no puede adquirir este tipo de conocimiento sin un lento aprendizaje. Sin embargo, se requiere de la habilidad para buscar información con un mínimo esfuerzo, lo cual puede significar que tenga que compartir escritorio con un grueso libro junto al teclado, o tener un segundo monitor dedicado a mostrar constantemente un navegador con resultados útiles sobre aquello en lo que se trabaja.

Para iniciarnos en el hábito de mejorar nuestras habilidades, una buena práctica es coger nuestro código antiguo y tratar de refactorizarlo hasta conseguir una reducción del orden de 10:1 en el número de instrucciones empleadas.

4. Incapacidad para entender punteros

Si no somos capaces de entender los punteros, el tipo de programas que somos capaces de escribir se reduce de forma considerable. El concepto de puntero es la llave que permite la creación de estructuras complejas de datos y APIs eficientes. Tendríamos aquí que tener en cuenta que existen lenguajes que manejan referencias en lugar de punteros los cuales, aunque actúan de una forma similar pero automatizando algunos aspectos, requieren de conocer el concepto en si mismo para elaborar estructuras eficientes.

Síntomas

• Incapacidad para crear una lista enlazada, o escribir un código que inserte / elimine nodos de una lista o un árbol sin peder datos.
• Asignar grandes arrays para colecciones de longitud variable y mantener un contador separado con dicha longitud en lugar de utilizar una estructura dinámica de datos.
• Incapacidad para encontrar o corregir los errores tras realizar operaciones aritméticas en punteros.
• Hacer una copia del puntero, cambiar su valor en la copia y asumir que el puntero original continúa apuntando a su antiguo valor.
• Ordenar una matriz de punteros realizando una comparación sobre sus propios valores.

Remedios

“Mi amigo José estaba alojado en alguna habitación del hotel pero yo no sabía en cuál. Como si que sabía dónde estaba nuestro amigo Alberto, llamé a su puerta y le pregunté si el conocía dónde se alojaba José; me contestó que no, pero si que sabía el número de habitación de otro de nuestros colegas, Miguel. Fui entonces a su habitación y le pregunté. Me dijo que José se alojaba en la 414. Tras agradecérselo, me dirigí a la habitación 414 y, efectivamente, allí estaba mi amigo.”

Los punteros pueden describirse siguiendo varias metáforas igual que puede hacerse con las estructuras de datos. El ejemplo de arriba es solo una forma de ejemplificar la idea que hay detrás. Historias como esa, pueden resultar útiles para convertir especificaciones en estructuras mentales más fáciles de asimilar.

5. Dificultad para ver a través de la recursión

La idea de la recursión es sencilla de entender pero los programadores a menudo tienen problemas para imaginar el resultado de una operación recursiva mentalmente, o cómo un resultado complejo puede ser calculado a través de una función muy simple. Esto hace difícil diseñar una función recursiva efectiva porque tenemos problemas en dibujarlas primero en nuestra cabeza. A todo este conjunto de operaciones las llamamos algoritmia.

Síntomas

• Superposición de algoritmos iterativos para soluciones que pueden alcanzarse de una forma sencilla y elegante con recursividad.
• Funciones recursivas que comprueban el estado de la base tanto antes como después de cada llamada.
• Funciones recursivas que no comprueban en ningún momento el estado/valor de la base.
• Subrutinas recursivas que concatenan / suman una variable global.
• Confusión entre qué pasa a una llamada recursiva como parámetro o llamadas recursivas que pasan un parámetro sin modificar en cada iteración.
• Pensar que el número de iteraciones va a pasar como parámetro.

Remedios

Ármate de paciencia y asume que vas a desbordar la pila varias veces hasta dar con el resultado correcto. Comienza escribiendo código con una única base-condición que pase como parámetro a una función recursiva. Codificamos y ejecutamos el algoritmo. ¿Desbordamos? Pues modificamos la lógica y volvemos a probar. El objetivo es finalmente alcanzar una visión completa del camino que recorren los datos dentro de un algoritmo hasta el punto de que podamos seguir varios hilos de forma simultánea. Es costoso, pero se puede practicar.

6. Desconfianza en el código

Síntomas

• Escribir funciones del tipo isNull, isNotNull, isFalse…
• Comprobar si un valor tipado como booleano se corresponde con algo diferente de true o false.

Remedios

Estás tratando de aplicar tus conocimientos de un lenguaje (por ejemplo de tipado blando) a otro (de tipado duro)? Si no es así, volvemos al primer punto sobre la incapacidad de razonar sobre un código.

Muchos de estos posibles síntomas se relacionan más con una dependencia sobre un código dentro de nuestra zona de confort que con una incapacidad natural para razonar una estructura abstracta. El único remedio aquí puede ser el de concedernos más tiempo para familiarizarnos con el lenguaje y construir así un conocimiento sólido.

Conclusión

Todos los puntos anteriores deben tomarse como un mero recetario con el que medir nuestra mayor o menor habilidad con un lenguaje o nuestra mejor o peor comprensión sobre una determinada plataforma.

El análisis de Lawrence puede resultar muy útil cuando por ejemplo, estamos aprendiendo un nuevo sistema y queremos saber si estamos listos para aplicarlo sobre un entorno real de producción.

Sin embargo, como el autor resuelve más arriba, cuando nos enfrentamos a una tecnología nueva, el mejor aprendizaje es el que obtenemos iniciando un proyecto real y tratando de superar las dificultades reales que surgen.

Finalmente, un acceso fluido a la información, la constancia y el no tener miedo a los errores, constituyen la clave para no quedarnos en el camino.

El resto del artículo, lo tenéis aquí.

Cuando comenzamos a estudiar algoritmos, uno de los temas más recurrentes para ejemplificar la materia es la ordenación de datos. Básicamente se trata de, partiendo de una lista con elementos dispuestos al azar, encontrar la forma de procesarla para devolverla ordenada.

Para esto, existen varios tipos de algoritmos diferentes que resuelven el problema a través de distintos acercamientos; estudiarlos es una buena forma de entender cómo se diseñan y cómo se mide el rendimiento de los mismos según cada uno de los escenarios posibles en los que pueden aplicarse.

En este artículo, repasaremos tres métodos muy conocidos de ordenación diferentes: bubblesort, selectionsort e insertionsort.

Cada uno de estos tres algoritmos se resuelven por iteración y, ya que son muy sencillos de codificar, se los considera como métodos simples. Pasemos sin más a estudiar cada uno de ellos para descubrir cuál(es) es el más interesante a la hora de implementarlo en un proyecto.

Preparando el terreno

Por lo general, todos los algoritmos de ordenación funcionan de una forma similar. Toman una lista de elementos, en nuestro caso un array, comparan sus elementos siguiendo una estrategia definida y, según el resultado de dicha comparación, mueven los datos de un lugar a otro hasta conseguir una lista (array) final ordenado.

Teniendo en cuenta lo anterior, un punto clave de nuestros métodos será mover valores entre los índices del array que queremos ordenar. Es decir, necesitaremos una función para intercambiar los valores de un array entre dos posiciones dadas.

Como no tenemos en Javascript una función similar, crearemos una. Por seguir la convención, llamaremos a nuestra función swap y aceptará tres parámetros: el array sobre el que actuamos y los índices de aquellos dos elememtos que queremos intercambiar. Su codificación es muy simple:

/**
 * @function
 * @name swap
 * @description Swap two elements in an array
 * @param {array} myArr The target array.
 * @param {int} indexOne The index of the first element to swap.
 * @param {int} indexTwo The index of the second element to swap.
 * @returns {array} The array with the two elements swapped.
 */
function swap(myArr, indexOne, indexTwo){
  var tmpVal = myArr[indexOne];
  myArr[indexOne] = myArr[indexTwo];
  myArr[indexTwo] = tmpVal;
  return myArr;
}

He comentado la función siguiendo la convención JSDoc para que resulte más clara. Como podemos ver, no realizo comprobación de tipos ni si existen los índices que se pretenden intercambiar. No es el objetivo de este artículo.

Una rápida demostración de su funcionamiento sería:

var myArr = ['a', 'b', 'c', 'd'];
console.log( swap( myArr, 0, 1) ); // ["b", "a", "c", "d"]

Nuestra función hace el trabajo que se le espera: ha tomado los índices 0 y 1 del array para devolver uno nuevo con esos valores intercambiados. Un poco más adelante, afinaremos esta función para que ofrezca un mejor rendimiento.

Estamos listos para comenzar a implementar nuestros métodos de ordenación de datos!

Bubble Sort (u ordenamiento por burbuja)

Imaginemos que estamos en un parque con nuestra familia y queremos hacer una foto en la que salgan todos. Decidimos que podemos ordenarlos según sus edades de tal modo que tengamos al más joven a la izquierda y al más mayor a la derecha. Sin embargo, como no les hemos dicho nada, se han colocado de forma aleatoria:

Para aplicar un ordenamiento de tipo burbuja a este conjunto de elementos, tenemos que prestar atención a las dos primeras personas de la izquierda. Le preguntamos a cada uno por su edad y, si la que está a la izquierda es mayor que la de su derecha, intercambiamos sus posiciones. En el caso contrario, no hacemos nada ya que se encontrarían ordenados de forma relativa entre ellos.

En nuestro ejemplo, la persona de la izquierda es mayor que la de su derecha por lo que tenemos que realizar el primer intercambio:

Ahora fijamos nuestra atención en la segunda y tercera posición para repetir el proceso anterior: preguntamos por sus edades e intercambiamos posición si fuera necesario. En nuestro ejemplo, no tenemos que realizar ahora ningún intercambio, por lo que avanzaríamos para comparar la tercera y cuarta posición entre ellas. De nuevo, están ya ordenados de forma relativa puesto que la persona de la derecha, es mayor que la de su izquierda.

Avanzamos sin alterar nada hasta comparar la cuarta persona con la quinta. Ahora si nos volvemos a encontrar con que la persona de la izquierda es mayor que la derecha, por lo que es necesario un nuevo intercambio:

Hemos completado una vuelta sobre nuestro conjunto y de momento estamos aún lejos de tenerlo ordenado. Sin embargo, si que hemos conseguido algo importante: el elemento de la derecha está ya ubicado en su posición final; es decir, que como si de una burbuja se tratase, el elemento más grande (en este caso la persona más mayor) ha ido bullendo hasta su posición final.

El siguiente paso, sería volver a repetir el proceso ignorando la persona (el elemento) que está a la derecha del conjunto (puesto que ya está en su posición final).

Comparamos ahora la dos primeras posiciones y observamos que están ya ordenadas, por lo que pasamos directamente a comparar la segunda con la tercera posición. De nuevo tenemos los elementos ordenados de forma relativa entre ellos por lo que pasariamos evaluar la tercera y cuarta posición.

Llegados a ese punto, observamos que la persona de la izquierda es mayor que la de su derecha, por lo que intercambiamos posiciones obteniendo:

Hemos completado la segunda vuelta; comenzamos de nuevo e ignoramos ahora los dos últimos elementos. Finalmente, tras todas las iteraciones posibles, obtenemos:

Una vez que hemos comprendido cómo funciona, es hora de implementarlo en código.

La idea tras este algoritmo es que, a cada iteración por el conjunto, un elemento es llevado hasta su posición final y tiene que ser por lo tanto ignorado en las siguientes. Esto se traduce en que, a cada paso, se debe compara un elemento menos que en el anterior. Si N es el número de items en la lista, entonces en la primera iteración necesitamos comparar N – 1; en la segunda, N – 2, y así sucesivamente. Este tipo de códigos basado en bucles dependientes se resuelven muy fácilmente:

function bubbleSort(myArr){
  var size = myArr.length;
 
  for( var pass = 1; pass < size; pass++ ){ // outer loop
    for( var left = 0; left < (size - pass); left++){ // inner loop
      var right = left + 1;
      if( myArr[left] > myArr[right] ){
        swap(myArr, left, right);
      }
    }
  }
 
  return myArr;
}

El código anterior, resulta muy sencillo de seguir. Un bucle externo recorre nuestro array tantas veces como elementos tenga menos uno. El bucle interno compara cada uno de los valores que encuentra (left) con aquel que inmediatamente posterior (right). Si left es mayor que right, se intercambia la posición y se continúa con el siguiente par.

Comprobamos nuestro código anterior con un array simple:

var myArr = ['d', 'f', 'd', 'c', 'a', 'e', 'b'];
console.log( bubbleSort( myArr ) ); // ["a", "b", "c", "d", "d", "e", "f"]

La función nos devuelve nuestro array ordenado aunque, como seguramente intuimos, es probable que estemos realizano un alto número de iteraciones para ello…

Más adelante, mediremos el rendimiento de este algoritmo para compararlo con los dos restantes.

Selection sort (u ordenamiento por selección)

Imaginemos que tenemos una estanteria llena de libros de diferente tamaño (altura). Como no hemos seguido ningún criterio a la hora de colocarlos, están dispuestos de forma aleatoria y nos gustaría cambiar esto. Querríamos tenerlos colocados según su tamaño de tal modo que en el extremo izquierdo tuviéramos al más alto y en el derecho al más bajo.

Sin embargo, son libros pesados y no parece interesante estar desplazándolos uno a uno como en el caso anterior. Lo ideal sería revisar todos los libros, seleccionar el siguiente según el orden que hemos establecido y colocarlo directamente en su posición final. Esta selección que da nombre al algoritmo permite tomar un elemento y desplazarlo en un único movimiento a su posición definitiva.

En varias ocasiones, mientras escaneamos los libros, encontraremos que éstos están ya en su posición final y que no es necesario moverlos. También notaremos que tras cada movimiento, el conjunto de libros ordenados crece mientras que el de los desordenados disminuye lo que muestra el patrón que permite concluir el proceso.

La secuencia completa para ordenar el resto de los libros sería el siguiente:

Como hemos comentado más arriba, en este tipo de ordenaciones, a diferencia de lo que ocurre con el método de burbuja, podemos encontrarnos continuamente con que un elemento ya está ordenado y no requiere de ese intercambio. Para ahorrar ese paso, modificaremos ligeramente la función swap:

function swap(myArr, indexOne, indexTwo){
  if( indexOne == indexTwo ){
    return myArr;
  }
  var tmpVal = myArr[indexOne];
  myArr[indexOne] = myArr[indexTwo];
  myArr[indexTwo] = tmpVal;
  return myArr;
}

Ahora estamos comprobando que las posiciones a intercambiar no sean la misma y, por tanto, estemos realizando una operación inútil.

La implementación del selection sort se construye a partir de un buble externo y otro interno, como en el anterior, pero con sutiles diferencias.

En primer lugar, el exterior recorre los valores entre cero y N-2 en lugar de entre 1 y N-1. Aunque en realidad se trate finalmente del mismo número de pasos (N-1), operamos directamente sobre los slots para enviar ahí el valor correcto en cada una de las iteraciones. Por ejemplo, en el primer paso, nuestro objetivo es desplazar el elemento correcto hasta la posición cero; en el segundo, nuestro objetivo es rellenar la posición 1, y así sucesivamente.

De nuevo, necesitamos un número de iteraciones N-1 puesto que tras cada ciclo, tendremos un elemento ubicado en su posición definitiva que podemos ignorar.

El código sería el siguiente:

function selectionSort( myArr ){
  var size = myArr.length;
  for( var slot = 0; slot < size -1; slot ++ ){ // outer loop
    var smallest = slot;
    for( var check = slot + 1; check < size; check++ ){ // inner loop
      if( myArr[check] < myArr[smallest] ){
        smallest = check;
      }
    }
    swap( myArr, smallest, slot );
  }
  return myArr;
}

Lo probamos:

var myArr = ['d', 'f', 'd', 'c', 'a', 'e', 'b'];
console.log( selectionSort( myArr ) ); // ["a", "b", "c", "d", "d", "e", "f"]

Como ocurría con el método anterior, un simple vistazo a la lógica del código nos puede poner sobre la pista de que quizá, hacemos más comparaciones de las que podrían ser necesarias. Eso por no entrar en la complejidad ciclomática de tres niveles que presenta.

Insertion Sort (u ordenación por inserción)

Este algoritmo es muy similar al que utilizaríamos para ordenar las cartas en una mano de póquer a medida que nos las van sirviendo.

La idea tras este concepto es la siguiente:

• Separamos según los palos en el siguiente orden: picas, tréboles, diamantes y corazones.
• Por cada uno de esos palos, ordenamos de forma ascendiente: As, 2, 3, …, 9, 10, jota, reina y rey.

La siguiente sucesión de imágenes nos mostraría el proceso de ordenación según fuéramos descubriendo cartas:

Inicialmente se tiene un solo elemento, que obviamente es un conjunto ordenado. Después, cuando hay K elementos ordenados de menor a mayor, se toma el elemento K + 1 y se compara con todos aquellos ya ordenados, deteniéndose cuando se encuentra uno menor (todos los elementos mayores han sido desplazados una posición a la derecha). En este punto se insertaría el elemento K + 1 desplazándose al resto.

Avanzando en el ejemplo anterior, la siguiente carta se ordenaría siguiendo el mismo criterio:

El resto de la secuencia sería:

El código sería el siguiente:

function insertionSort( myArr ) {
  var size = myArr.length,
      slot,
      tmp;
 
  for ( var item = 0; item < size; item++ ) { // outer loop     
    tmp = myArr[item];
    for ( slot = item - 1; slot >= 0 && myArr[slot] > tmp; slot-- ){ // inner loop
      myArr[ slot + 1 ] = myArr[slot];
    }
    myArr[ slot + 1 ] = tmp;
  }
  return myArr;
};

Y la comprobación de rigor:

var myArr = ['d', 'f', 'd', 'c', 'a', 'e', 'b'];
console.log( insertionSort( myArr ) ); // ["a", "b", "c", "d", "d", "e", "f"]

Es cierto que este código es más difícil de seguir a simple vista y quizá no seamos capaces de advertir qué nivel de complejidad presenta. Pero no hay problema; ha llegado el momento de medir cada uno de los métodos anteriores y comparar los resultados.

Comparando los algoritmos de ordenación básicos

Una vez que hemos presentado algunos de estos algoritmos básicos, vamos a analizar su rendimiento de un modo práctico. Esta comparación no será definitiva en tanto a qué método escoger independientemente del escenario, sino que supone un ejemplo de cómo implementar un sistema de métrica sencillo sobre un código a evaluar.

Para ello, debemos contemplar los tres escenarios clave a la hora de medir un algoritmo de ordenación:

• Todos los datos se encuentran de partida ya ordenados (el mejor de los casos).
• Todos los datos se encuentran de partida ya ordenados pero en sentido inverso al deseado (el peor de los casos).
• Los datos se encuentran dispuestos en cualquier orden (el caso más habitual).

Para simular cada uno de estos estados, crearemos 3 listas diferentes de 1000 elementos sobre la que aplicaremos nuestros algoritmos y sus mediciones:

var TEST_SIZE = 1000,
    sortedArr = [],
    reverseArr = [],
    randomArr = [];
 
for( var x = 1; x0; x-- ){
  reverseArr.push(x);
}
 
for( var x = 1; x

Con nuestros arrays preparados, nos falta implementar algún tipo de contador para medir el número de iteraciones que realizan nuestros algoritmos. Para ello, nos valdremos de una variable contadora que introduciremos en el interior (inner loop) de cada una de nuestras funciones:

var counter = 0;
 
function bubbleSort(myArr){
  var size = myArr.length;
  counter = 0;
 
  for( var pass = 1; pass < size; pass++ ){ // outer loop
    for( var left = 0; left < (size - pass); left++){ // inner loop       
      var right = left + 1;
      counter++;
      if( myArr[left] > myArr[right] ){
        swap(myArr, left, right);
      }
    }
  }
  console.log('Bubble Sort: ', counter );
  return myArr;
}
 
function selectionSort( myArr ){
  var size = myArr.length;
  counter = 0;
 
  for( var slot = 0; slot < size -1; slot ++ ){ // outer loop
    var smallest = slot;
    for( var check = slot + 1; check < size; check++ ){ // inner loop
      counter++;
      if( myArr[check] < myArr[smallest] ){
        smallest = check;
      }
    }
    swap( myArr, smallest, slot );
  }
  console.info( 'Selection  Sort: ', counter );
  return myArr;
}
 
function insertionSort( vector ) {
  var innerCounter = 0;
  counter = 0;
  for (var i=1; i < vector.length; i++) {
    var temp = vector[i];
    var j = i-1;
    counter++;
    while (j >= 0 && vector[j] > temp) {
      innerCounter++;
      vector[j + 1] = vector[j];
      j--;
    }
    vector[j+1] = temp;
  }
  console.info('Insertion Sort: ', innerCounter || counter );
  return vector;
};

El contador de la función insertionSort es diferente a los otros dos ya que aquí puede darse el caso (improbable) de que no se entre en el bucle interno. Esto pasaría, efectivamente, si la lista que manejáramos correspondiese a la que hemos etiquietado como el ‘mejor caso’; es decir, donde todos sus elementos estuviesen ya ordenados.

Con nuestros contadores ya preparados, solo tenemos que ejecutar los algoritmos de ordenación sobre cada uno de los arrays que hemos preparado antes. El resultado que obtenemos es el siguiente:

bubbleSort( sortedArr ); // 499500
bubbleSort( reverseArr ); // 499500
bubbleSort( randomArr ); // 499500
 
selectionSort( sortedArr ); // 499500
selectionSort( reverseArr ); // 499500
selectionSort( randomArr ); // 499500
 
insertionSort( sortedArr ); // 999
insertionSort( reverseArr ); // 499500
insertionSort( randomArr ); // 257994

Tenemos varios datos interesantes en estas mediciones:

• La ordenación por burbuja y por selección relaizan siempre el mismo número de comparaciones.
• El número de comparaciones que requieren la ordenación por burbujas y por selección es independiente del estado de los datos de entrada.
• El número de comparaciones requeridas por el algoritmo de inserción es muy sensible al estado inicial de los datos. En el peor de los casos, requiere el mismo número de comparaciones que los otros; en el mejor, le basta con una iteración menos que el número total de elementos que contiene el array.

Lo más importante de los datos anteriores es que tanto la burbuja como la selección son insensibles al estado de los datos. Pueden considerarse así como algoritmos de “fuerza bruta” en oposición a la inserción que puede describirse como adaptable: si precisa menos trabajo, realiza menos trabajo.

Conclusión

Tras los datos arrojados por los métodos anteriores, podemos hacernos una idea de como rinden estos métodos básicos que hemos presentado. Sin embargo, hay que tener cuidado con no extraer más conclusiones de la cuenta.

Para realmente conocer la diferencia entre sus comportamientos, deberíamos también medir diferentes escenarios como cuánto afecta el número de objetos que componen cada lista de forma precisa (esto sería la escalabilidad) y el tiempo de ejecución real de cada sistema de ordenación (el coste de CPU).

Como idea final, podemos obtener que, por lo general, un algoritmo de inserción realiza, como mínimo, un trabajo similar al de la burbuja o la selección. Para la gran mayoría de escenarios, sin embargo, su rendimiento se demuestra muy superior y, por tanto, resulta una opción mejor.

Para la segunda parte de este artículo, estudiaremos algoritmos avanzados como el shellsort, el célebre quicksort o el potente mergesort. Al igual que con los básicos, realizaremos métricas sobre su rendimiento para tener una primera impresión sobre cuál es el método más adecuado para cada uno de los posibles escenarios que pueden presentarse.

Es muy frecuente que, durante la etapa de debug de un código, tengamos que realizar diversas comparaciones entre objetos. Por ejemplo, uno de los métodos más recurrentes cuando realizamos TDD es el assertEquals donde pasamos dos términos y esperamos comprobar si ambos son iguales.

Sin embargo, pese a que cuando comparamos cadenas y números no hay ningún problema, no ucurre lo mismo cuando nos enfrentamos a objetos o arrays. Un ejemplo de resultados poco intuitivos son los siguientes:

console.log( [1, 2] == [1, 2] ); // false
console.log( [1, 2] === [1, 2] ); // false
 
console.log( { foo : 'Hello World'} == { foo : 'Hello World'} ); // false
console.log( { foo : 'Hello World'} === { foo : 'Hello World'} ); // false

Como podemos ver, ni la comparación simple ni la estricta, resultan útiles a la hora de trabajar con objetos y arrays. Como cabe esperar, si la estructura fuera más complicada, con más elementos anidados, el resultado sería siendo el mismo.

Preparando el terreno

Para conseguir una comparación estricta (o como algunos frameworks lo llaman profunda), tenemos que crear una función personalizada. Y para ello, no existe ningún otro método que no se base en la fuerza bruta: hay que iterar por cada método o valor de nuestros objetos para poder realizar la comparación.

Para facilitar el trabajo, vamos a recurrir a uan vieja conocida: la función toType() que vimos en un artículo anterior. Gracias a este pequeño snippet, podemos determinar de forma precisa el tipo de dato de de un objeto superando así las capacidades del operador nativo typeof.

El código de dicha función es el siguiente:

var toType = function (obj) {
  if (typeof obj === "undefined") {
    return "undefined";
 
    // consider: typeof null === object
  }
  if (obj === null) {
    return "null";
  }
 
  var type = Object.prototype.toString.call(obj).match(/^\[object\s(.*)\]$/)[1] || '';
 
  switch (type) {
  case 'Number':
    if (isNaN(obj)) {
      return "nan";
    } else {
      return "number";
    }
  case 'String':
  case 'Boolean':
  case 'Array':
  case 'Date':
  case 'RegExp':
  case 'Function':
    return type.toLowerCase();
  }
  if (typeof obj === "object") {
    return "object";
  }
  return undefined;
};

Si prestamos atención, este código es ligeramente diferente al que aparece en el citado artículo: se ha mejorado la detección para los casos NaN y Number; por lo demás, su funcionamiento no ha variado:

console.log( toType( [ 1, 2 ] ) ); // array
console.log( toType( { foo: '1' } ) ); // object
console.log( toType( undefined ) ); // undefined
console.log( toType( NaN ) ); // nan
console.log( toType( / \s+/ ) ); // regexp

Creando la función “equals”

Existen básicamente dos formas de implementar nuestra función: la primera es como tal, una función que acepte dos parámetros y nos devuelva un valor booleano con el resultado de la comparación. La segunda es como una extensión del Object mediante su prototipo para que esté siempre disponible independientemente del scope en el que nos encontremos.

Según lo anterior, invocariamos nuestra función de las siguientes formas:

// Normal function
equals( a, b );
 
// Prototype extend
a.equals( b );

Personalmente, siempre prefiero la primera opción ya que, aunque más lenta (dependiendo de dónde se invoque hay que remontar los scopes necesarios hasta alcanzar su definición), es más segura: no hay problemas con posibles colisiones ya sean en el intérprete o con bibliotecas de terceros.

La función completa se muestra a continuación y ha sido extraída del framework QUnit que ya estudiamos en su día; la autoría corresponde a Philippe Rathé. El código está lo suficientemente comentado para ser autoexplicativo:

var equals = function () {
 
  var innerEquiv; // the real equiv function
  var callers = []; // stack to decide between skip/abort functions
  var parents = []; // stack to avoiding loops from circular referencing
  // Call the o related callback with the given arguments.
 
  function bindCallbacks(o, callbacks, args) {
    var prop = toType(o);
    if (prop) {
      if (toType(callbacks[prop]) === "function") {
        return callbacks[prop].apply(callbacks, args);
      } else {
        return callbacks[prop]; // or undefined
      }
    }
  }
 
  var callbacks = function () {
 
    // for string, boolean, number and null
 
    function useStrictEquality(b, a) {
      if (b instanceof a.constructor || a instanceof b.constructor) {
        // to catch short annotaion VS 'new' annotation of a
        // declaration
        // e.g. var i = 1;
        // var j = new Number(1);
        return a == b;
      } else {
        return a === b;
      }
    }
 
    return {
      "string": useStrictEquality,
      "boolean": useStrictEquality,
      "number": useStrictEquality,
      "null": useStrictEquality,
      "undefined": useStrictEquality,
 
      "nan": function (b) {
        return isNaN(b);
      },
 
      "date": function (b, a) {
        return QUnit.toType(b) === "date" && a.valueOf() === b.valueOf();
      },
 
      "regexp": function (b, a) {
        return QUnit.toType(b) === "regexp" && a.source === b.source && // the regex itself
        a.global === b.global && // and its modifers
        // (gmi) ...
        a.ignoreCase === b.ignoreCase && a.multiline === b.multiline;
      },
 
      // - skip when the property is a method of an instance (OOP)
      // - abort otherwise,
      // initial === would have catch identical references anyway
      "function": function () {
        var caller = callers[callers.length - 1];
        return caller !== Object && typeof caller !== "undefined";
      },
 
      "array": function (b, a) {
        var i, j, loop;
        var len;
 
        // b could be an object literal here
        if (!(toType(b) === "array")) {
          return false;
        }
 
        len = a.length;
        if (len !== b.length) { // safe and faster
          return false;
        }
 
        // track reference to avoid circular references
        parents.push(a);
        for (i = 0; i < len; i++) {
          loop = false;
          for (j = 0; j < parents.length; j++) {
            if (parents[j] === a[i]) {
              loop = true; // dont rewalk array
            }
          }
          if (!loop && !innerEquiv(a[i], b[i])) {
            parents.pop();
            return false;
          }
        }
        parents.pop();
        return true;
      },
 
      "object": function (b, a) {
        var i, j, loop;
        var eq = true; // unless we can proove it
        var aProperties = [],
          bProperties = []; // collection of
        // strings
        // comparing constructors is more strict than using
        // instanceof
        if (a.constructor !== b.constructor) {
          return false;
        }
 
        // stack constructor before traversing properties
        callers.push(a.constructor);
        // track reference to avoid circular references
        parents.push(a);
 
        for (i in a) { // be strict: don't ensures hasOwnProperty
          // and go deep
          loop = false;
          for (j = 0; j < parents.length; j++) {
            if (parents[j] === a[i]) loop = true; // don't go down the same path
            // twice
          }
          aProperties.push(i); // collect a's properties
          if (!loop && !innerEquiv(a[i], b[i])) {
            eq = false;
            break;
          }
        }
 
        callers.pop(); // unstack, we are done
        parents.pop();
 
        for (i in b) {
          bProperties.push(i); // collect b's properties
        }
 
        // Ensures identical properties name
        return eq && innerEquiv(aProperties.sort(), bProperties.sort());
      }
    };
  }();
 
  innerEquiv = function () { // can take multiple arguments
    var args = Array.prototype.slice.apply(arguments);
    if (args.length < 2) {
      return true; // end transition
    }
 
    return (function (a, b) {
      if (a === b) {
        return true; // catch the most you can
      } else if (a === null || b === null || typeof a === "undefined" || typeof b === "undefined" || toType(a) !== toType(b)) {
        return false; // don't lose time with error prone cases
      } else {
        return bindCallbacks(a, callbacks, [b, a]);
      }
 
      // apply transition with (1..n) arguments
    })(args[0], args[1]) && arguments.callee.apply(this, args.splice(1, args.length - 1));
  };
 
  return innerEquiv;
 
}();

Un rápido vistazo por el código nos muestra que se basa una comprobación sistemática de los argumentos aplicando a cada uno el algoritmo de comparación más adecuado.

Para el caso de los objetos y los arrays, el proceso pasa por iterarlos comparando si en cada paso los valores se correspondan con los esperados.

La función, al basarse en la fuerza bruta, puede resultar lenta cuando comparamos objetos muy complejos y anidados. Afortunadamente, el recorrido de circuito corto característico de Javascript permite salir inmediatamente de la función tras la primera comparación fallida evitando realizar las restantes.

Conclusión

A veces, los métodos y operadores nativos de Javascript no permiten efectuar algunas operaciones que podríamos considerar básicas. En este caso concreto, nos encontramos con la inconsistencia del lenguaje a la hora de comparar objetos y arrays en lo que sería algo trivial durante un desarrollo dirigido por tests.

Gracias al ejemplo anterior, podemos contar con una pieza de código reutilizable que puede sacarnos de un apuro en más de una ocasión.

No tenía pensado hacer una continuación del anterior artículo ‘Estudiando el diseño de jQuery paso a paso‘ pero, a raíz de los comentarios de algunos usuarios, he visto interesante que continuemos profundizando en esta arquitectura para comprender mejor cómo construir nuestros propios frameworks o bibliotecas.

Aplicando métodos por referencia

Uno de los aspectos más interesantes en el uso de jQuery es la aplicación de sus métodos por referencia. Nosotros, en el ejercicio anterior, habíamos creado un objeto donde, para aplicar una funcionalidad concreta a una cadena, ésta se pasaba como argumento del correspondiente método:

$.trim('   Hola Mundo '); // Hola Mundo

Sin embargo, a la hora de trabajar con la API pública de nuestra biblioteca, resulta mucho más cómodo cuando la funcionalidad se aplica sobre un argumento asociado al objeto y no al método. Siguiendo el ejemplo anterior, la nueva propuesta de sintaxis sería:

$('  Hola Mundo   ').trim();

De este modo, ganamos en legibilidad a la vez que abrimos las puertas a otros comportamientos interesantes que veremos más adelante.

Para permitir este tipo de construcciones, tenemos que realizar varios cambios en nuestra biblioteca; modificaciones que van en la línea de lo que hacen otros frameworks y que nos permitirá conocer un poco mejor estas estructuras relativamente complejas del lenguaje.

Lo veremos a continuación en detalle pero, para ir poniéndonos sobre la pista, la idea general es permitir que nuestro objeto se comporte bien como una función o bien como un objeto tradicional según la forma en que sea invocado.

El nuevo patrón

Para este ejemplo, vamos a renombrar nuestro framework como ‘Utils‘ evitando así posibles colisiones con la biblioteca jQuery genuina. Por el mismo motivo, cambiaremos también el álias y utilizaremos ‘$$‘ (doble símbolo de dólar) como método abreviado para llamarla.

La estructura básica quedaría como sigue:

(function (undefined) {
 
  var utils = (function () {
 
  })();
 
  window.utils = window.$$ = utils;
 
})();

Por el momento no hemos realizado ningún cambio; recurrimos al patrón de módulo modificado donde asociamos directamente el objeto creado al ámbito global representado por window.

Ahora, para que los métodos que tengamos en nuestro framework puedan trabajar directamente con los argumentos del objeto general, tenemos que observar un detalle importante que se ve más claro cuando aislamos un caso de uso:

$$('Hola Mundo');

Nuestra biblioteca, así invocada, está funcionando realmente como una función a la que se le asigna un argumento, no como un objeto en el que buscamos un método ($$.myMethod()). Por lo tanto, nuestro framework tiene que comportarse como una función o como un objeto según sea el caso.

Para conseguir el primer objetivo, el que utils responda al comportamiento de una función, crearemos una en su interior que nos servirá de contenedor y que permitirá pasar los argumentos a los métodos que sean llamados a continuación. A esta nueva función la llamaremos core (núcleo) y la implementamos paso a paso de la siguiente forma:

(function (undefined) {
 
  var utils = (function () {
 
    var core = function ( args ) {
      /* ... */
    };
 
    // Methods goes here
 
    // Return
    return core;
 
  })();
 
  window.utils = window.$$ = utils;
 
})();

Tenemos ahora un núcleo general

Hemos creado un nuevo objeto, en realidad una función, que puede recibir sus correspondientes argumentos (en este caso de momento solo args). Si avanzamos hasta el final, vemos un return que devuelve directamente dicho objeto/función. De esta forma estamos haciendo que al escribir,

$$('Hola Mundo');

nuestro framework se comporte como una función normal que recoge parámetros (‘Hola Mundo’). Tenemos ya una parte importante adelantada!

El siguiente paso es sencillo: como sabemos que el flujo de nuestro framework pasa ahora por core cuando utilizamos la fórmula anterior, podemos almacenar sus argumentos en una propiedad del objeto para recuperarla más adelante en los métodos.

El código para conseguir este paso puede parecer complejo a priori pero, una vez analizado con detenimiento, es en realidad muy simple:

(function (undefined) {
 
  var utils = (function () {
 
    var core = function ( args ) {
      return new core.fn.init( args );
    };
 
    core.fn = core.prototype = {
      init: function ( args ) {
        core._args = args;
        return core;
      }
    };
 
    // Methods goes here
 
    // Return
    return core;
 
  })();
 
  window.utils = window.$$ = utils;
 
})();

La jugada es devolver desde core, con return, una nueva función que definimos un poco más adelante. Al utilizar la palabra reservada new, hay que recordar que estamos utilizando dicha función como constructor y que, en realidad, estamos creando un nuevo objeto con los atributos que la componen. De este modo, hemos convertido nuestra función inicial en un objeto que ahora acepta métodos.

En esta estructura, init nos sirve como inicializador mejorado del objeto final: desde aquí, podemos pasar tantos argumentos como necesitemos para, por ejemplo, preconfigurar varios atributos de nuestro objeto final. En este caso, para simplificar el ejercicio, solo pasamos aquello que nos está llegando desde la API pública ( es decir, lo que un usuario haya especificado mediante una sintaxis del tipo $$(‘my string’).myMethod() ).

init coge los argumentos y los asocia (guarda) en el mismo core como una nueva propiedad (_args) que será la que usaremos más adelante cuando tratemos los métodos. Finalmente, devuelve el mismo objeto pero ya modificado y listo para añadirle funcionalidad.

NOTA: Al nombre de la propiedad le hemos añadido un guión bajo para indicar que se trata de un método privado (no accesible desde la API pública); una convención útil cuando trabajamos con objetos grandes.

Los métodos de la API pública

Con nuestros elementos ya accesibles, solo tenemos que comenzar a añadir métodos que los recojan y modifiquen de alguna manera. Como ejemplo, retomaremos de los ejercicios anteriores nuestra función trim() para eliminar los espacios al pricipio y final de una cadena dada.

NOTA: Ya que el código necesario para llevar a cabo esta funcionalidad es muy sencillo, permite que nos concentremos mejor en cómo se implementa en lugar de en cómo trabaja.

Para que los métodos sean accesibles éstos deben ser ahora parte del core, por lo que únicamente tenemos que extender dicho objeto usando el sistema tradicional:

(function (undefined) {
 
  var utils = (function () {
 
     var core = function ( args ) {
      return new core.fn.init( args );
    };
 
    core.fn = core.prototype = {
      init: function ( args ) {
        core._args = args;
        return utils;
      }
    };
 
    // Methods goes here
    core.trim = function (str) {
      core._args && (str = core._args);
      return str.replace(/^\s+|\s+$/g, '');
    };
 
    // Return
    return core;
 
  })();
 
  window.utils = window.$$ = utils;
 
})();

Como vemos, la idea es que cada método que implementemos extienda al núcleo con una nueva función. En este caso, es interesante observar que podemos recoger un argumento. Esto es así para conservar la compatibilidad con la forma anterior. Es decir, que podemos obtener el mismo resultado tanto pasándole un argumento al objeto general como al método en particular:

console.log( $$.trim( '  Hola Mundo  ') ) ;  // Retrocompatibilidad con la forma anterior.
console.log( $$('  Hola Mundo  ').trim() ) ; // Nueva invocación por declaración.

Para que el framework sepa de dónde tomar el parámetro, hemos añadido un condicional:

core._args && (str = core._args);

Esto lo que hace es preguntar si existen argumentos ya cacheados. En caso de que existan, los tomamos como argumentos; si no, buscamos aquellos pasados directamente al método trim().

La línea de código anterior, aunque parece compleja, es un simple shotcut de las siguientes:

if( core._args ){
  str = core._args
}

La sintaxis propuesta funciona porque, como hemos mencionado en varias ocasiones, Javascript es un lenguaje de circuito corto (o cortocircuito). Esto quiere decir que cuando realizamos comparaciones lógicas (booleanas), los términos se evalúan de izquierda a derecha rompiéndose inmediatamente la secuencia tras la primera disconformidad. En este condicional, si la primera parte de la expresión es correcta (si existe core._args), se evalúa el siguiente término. Dicho término (str = core._args) es una expresión, por lo que será ejecutada sin más. Es una forma elegante de ahorrarnos un if y aligerar (aunque sea de forma virtual) la complejidad ciclomática del código.

Sin embargo, falta un paso más para que esto funcione: en caso de que el usuario haya utilizado la forma anterior de enviar su argumento asociado al método, tenemos que decirle a nuestro código que lo coja de ahí. También es necesario borrar el argumento cacheado tras su uso para que a la siguiente invocación del método, si no hemos asignado ningun elemento sobre el que actuar, no se utilice el que teníamos guardado de la vez anterior.

Por lo tanto, para llevar a cabo estas dos modificiaciones, necesitamos un par de líneas nuevas justo detrás de la que acabamos de explicar:

core._args && (str = core._args);
str || (str = '');
core._args = '';

De nuevo se comprueba si str se corresponde con un valor nulo o indefinido en cuyo caso, lo reasignamos como cadena vacía.

La siguiente línea únicamente borra cualquier valor almacenado en el atributo core._args para que no sea reutilizado la proxima vez que se utilice la biblioteca.

Como mejora rápida, para aligerar un poco el código, las dos primeras líneas que hemos indicado pueden refactorizarse utilizando el mismo principio del cortocircuito anterior. Quedaría como sigue:

str = core._args || str || '';
core._args = '';

Si lo unimos todo, nuestro código tiene ahora el siguiente aspecto:

(function (undefined) {
 
  var utils = (function () {
     var core = function ( args ) {
      return new core.fn.init( args );
    };
 
    core.fn = core.prototype = {
      init: function ( args ) {
        core._args = args;
        return utils;
      }
    };
 
    // Methods goes here
    core.trim = function (str) {
      core._args && (str = core._args);
      str || (str = '');
      core._args = '';
      return str.replace(/^\s+|\s+$/g, '');
    };
 
    // Return
    return core;
 
  })();
 
  window.utils = window.$$ = utils;
 
})();

Bien! Ahora toca probarlo para ver si funciona como se espera:

var sample1 = '  Hello World  ';
var sample2 = '   Good bye Lenin    ';
 
console.log( '1', $$.trim( sample1 ) ); // 'Hello World'
console.log( '2', $$.trim( sample2 ) ); // 'Good bye Lenin'
console.log( '3', $$( sample1 ).trim() ); // 'Hello World'
console.log( '4', $$( sample2 ).trim() ); // 'Good bye Lenin'
console.log( '5', $$.trim( sample2 ) ); // 'Good bye Lenin'
console.log( '6', $$.trim() ); // ''
console.log( '7', $$().trim() ); // ''
console.log( '8', $$.trim() ); // ''
console.log( '9', $$( sample1).trim( sample2 ) ); // 'Hello World'
console.log( '10', $$().trim() ); // ''
console.log( '11', $$( sample1 ).trim( sample2 ) ); // 'Hello World'
console.log( '12', $$.trim() ); // ''
console.log( '13', $$( sample1 ).trim( sample2 ) ); // 'Hello World'
console.log( '14', $$().trim() ); // ''
console.log( '15', $$( sample1 ).trim( sample2 ) ); //'Hello World'

Mejorando un poco el patrón

Llegados a este punto, con nuestra estructura básica ya completa y con uno de sus posibles métodos ya implementados, podríamos decir que nuestro framework es funcional: los resultados son los esperados y el código resulta sencillo de extender y mantener. Sin embargo, como desarrolladores, podemos estar ya pensando en varias mejoras que complementen el trabajo realizado hasta ahora. Por ejemplo:

- Una fuerte comprobación de tipos en la entrada de argumentos.
- Un robusto sistema de manejo de excepciones para casos inesperados.
- Implementar un motor tipo Sizzle para ofrecer así soporte completo al API DOM.
- …

Aunque todo lo anterior podría resultar un buen ejercicio para comprobar si nos manejamos bien con esta estructura, quedaría pendiente una feature muchos más interesante: implementar un patrón de diseño encadenado que permita enlazar varios métodos sobre una misma referencia/entrada.

La finalidad de esta mejora sería conseguir una sintaxis similar a:

$$('  Hello World  ').trim().method2().method3(); // And so on...

En una próxima entrega, veremos qué cambios tenemos que realizar en nuestro framework para conseguir este comportamiento, las ventajas que presenta y también sus inconvenientes en lo que a calidad de código se refiere. En relación a esto último, haremos alusión a la conocida Ley de Demeter y a cómo la enfrentan otras bibliotecas similares.

Conclusión

En este artículo hemos visto como, partiendo del patrón tipo jQuery que presentamos en otro artículo, podemos conseguir una arquitectura mejorada de gran flexibilidad a la hora de aplicar distintas funcionalidades sobre aquellos elementos en los que lo necesitemos.

Finalmente, hemos presentado una mejora importante (aún sin implementar) como es la que ofrece el patrón encadenado (chaining pattern) gracias a la cual, podremos aplicar varios métodos (funciones) sobre un mismo argumento en lo que resulta una sintaxis muy clara y legible.

El estamento for-in es uno de esos pocos incomprendidos en Javascript. Su papel principal es el de recorrer un objeto pasando por cada una de sus propiedades para actuar sobre ellas de alguna manera; sin embargo, dado que en Javascript los arrays son también objetos, podemos encontrarlo iterando por cada uno de los valores de estos últimos.

Se han escrito muchos artículos al respecto de este uso, sobre si es correcto o no, sobre el orden de enumeración obtenido, rendimiento, etc… Echemos un vistazo detenido a esta instrucción para ver cómo funciona con más detalle y corroborar o desmentir lo que sobre ella se dice.

Empecemos por lo básico

La especificación ECMAScript 262 define dos modos diferentes de declaración:

// Method 1:
for ( var VariableDeclarationNoIn in Expression )
 
// Method 2:
for ( LeftHandSideExpression  in  Expression  )

Como vemos a simple vista, la única diferencia entre ambas fórmulas es el uso de var junto al primero de sus términos.

El método 1 es el más común y el que nos puede resultar más familiar. Declaramos una variable la cual recogerá a cada iteración el valor de los atributos que componen el objeto a recorrer. Destaco la palabra objeto porque con ella quiero englobar tanto al objeto considerado clásico (aquel de propiedades definidas mediante pares de nombre/valor), como a los array ya mencionados.

Un ejemplo sencillo sería el siguiente:

var myObj = {
  foo : 1,
  bar : 2,
  anotherProperty : 3
}
 
for( var property in myObj ){
  console.log( property );
}
 
// foo
// bar
// anotherProperty

Nótese que el valor devuelto se corresponde con el nombre de la propiedad; para acceder a su contenido, tendríamos que utilizar dicho nombre como índice del objeto:

var myObj = {
  foo : 1,
  bar : 2,
  anotherProperty : 3
}
 
for( var property in myObj ){
  console.log( myObj[property] );
}
 
// 1
// 2
// 3

El segundo método, es más interesante. El término LeftHandSideExpresion hace referencia a cualquier tipo de expresión que pueda ser evaluada por el intérprete Javascript. Utilizando este patrón, asignamos en cada iteración el nombre de la propiedad a la expresión resultante del primer término.

La explicación puede parecer confusa, pero un ejemplo rápido nos muestra su funcionamiento:

var myObj = {
      foo : 1,
      bar : 2,
      anotherProperty : 3
    },
    myArr = [],
    i = 0;
 
for( myArr[i++] in myObj );
 
console.log( myArr ); // ["foo", "bar", "anotherProperty"]

De nuevo, observamos que obtenemos los nombres de las propiedades y no sus valores.

NOTA: Hay que tener cuidado con el punto y coma ; que finaliza el for-in: al aceptar este estamento un bloque con instrucciones a ejecutar en cada iteración, si omitimos el punto y coma, el intérprete tomará la siguiente línea que encuentre como instrucción a ejecutar provocando comportamientos no deseados. Por ejemplo:

var myObj = {
      foo : 1,
      bar : 2,
      anotherProperty : 3
    },
    myArr = [],
    i = 0;
 
for( myArr[i++] in myObj ) // I forgot the ';'!!
 
console.log( myArr );
 
// ["foo"]
// ["foo", "bar"]
// ["foo", "bar", "anotherProperty"]

El console se ha tomado como instrucción de bloque y será ejecutado a cada iteración por las propiedades del objeto.

Como hemos mencionado, con este método solo se toman los nombres de las propiedades por lo que si queremos acceder también al valor, al no contar con ese nombre almacenado, debemos utilizar el propio array que estamos montando para preguntar al objeto:

var myObj = {
      foo : 1,
      bar : 2,
      anotherProperty : 3
    },
    myArr = [],
    myValues = [],
    i = 0;
 
for( myArr[i++] in myObj ){
  var lastItem = myArr.length - 1;
  myValues.push( myObj[ myArr[ lastItem ] ] );
}
 
console.log( myValues ); // [ 1, 2, 3 ]

No es un código muy elegante, pero parece ser la única forma de acceder al valor de una propiedad utilizando este tipo de estructura.

¿Cuánto de flexible se vuelve esto?

Podemos probar con formas más exóticas para ver qué ocurre.

Por ejemplo, la inicialización de varias variables (como haríamos por ejemplo en un for normal) produce en este caso un error inmediato:

var myObj = {
      foo : 1,
      bar : 2,
      anotherProperty : 3
    },
    myArr = [],
    myArr2 = [],
    i = 0;
 
for( myArr[i], myArr2[i++] in myObj ); // SyntaxError: invalid for/in left-hand side

Sin embargo, si que podemos alterar las expresiones mediante un doble in en nuestra estructura:

var myObj = {
      foo : 'Hello World'
    },
    j = 'bar';
 
for( var i in myObj, j in myObj );

Esta compleja construcción en realidad no se corresponde con lo esperado: el segundo in actúa sobre la expresión evaluada en el primer término por lo que en realidad equivale a:

( [ var j = foo ] in [ bar in myObj ] )

Esta estructura, como nos comentan en @kuvos, tiene una consecuencia interesante en Javascript: eventualmente producirá un error, pero no en la fase de construcción sintáctica (es decir, no dará un error de sintaxis) sino en la de trazado del resultado. Esto hace a este estamento único dentro del lenguaje ya que es al parecer la única instrucción que requiere de un trazado hacia atrás una vez que el intérprete ha validado su sintaxis. Si esa expresión no resulta lógica, pese a ser correcta, producirá un error en tiempo de ejecución.

¿Sobre qué propiedades itera?

Pues según la especificación, esta instrucción itera por todas aquellas propiedades que poseen el valor interno [[Enumerable]] como verdadero. En la práctica, esto concierne a las propiedades definidas de facto en el objeto, a su prototipo, al prototipo del prototipo y así sucesivamente mientras nos remontamos en su cadena. Sin embargo, no se recogerían aquí las propiedades de los prototipos que hayan sido ocultadas por existir en dicha cadena prototípica un objeto anterior con una propiedad de igual nombre.

Para evitar todos estos elementos que en la mayoría de  ocasiones solo suponen ruido en los resultados, Douglas Crockford nos recomienda el uso del método hasOwnProperty para filtrar todo aquello que provenga de herencia. Así tendríamos:

var arr = ['a','b','c'],
    indexesDefault = [],
    indexesClean = [];
 
Array.prototype.each = function() {/*blah*/};
 
for (var index in arr) {
	indexesDefault.push( index );
 
  if (arr.hasOwnProperty(index)) {
		indexesClean.push( index );
	}
}
 
console.log( indexesDefault ); // ["0", "1", "2", "each"]
console.log( indexesClean ); // ["0", "1", "2"]

Como vemos, con hasOwnProperty podemos suprimir de la ecuación aquellas propiedades/métodos legados mediante herencia.

¿Y qué ocurre con los arrays?

Como se ha dicho al principio, esta instrucción permite iterar por las propiedades de un objeto y en Javascript, un array es un objeto más:

var myArr = [ 'foo', 'bar', 'hello'];
typeof myArr // "object"

Visto esto, podemos concluir pues que su uso es legítimo cuando se trata de recorrer los elementos que componen un array:

var myArr = [ 'foo', 'bar', 'hello'];
 
for( var element in myArr ){
  console.log( myArr[element] );
}
 
// foo
// bar
// hello

Nótese que en la iteración, element guarda el índice del array en lugar del valor; es por ello que debemos acceder al mismo utilizando la estructura myArr[element].

El resultado es el esperado. Sin embargo, debemos tener cuidado con una de las características de esta instrucción: el estándar no define el orden en que se recorrerá un objeto. De hecho, cuando recorremos un objeto tradicional, encontramos inconsistencias en un entorno multinavegador:

var obj = {3:'a', 2:'b', 'foo':'c', 1:'d'}, result = [];
 
for (var prop in obj) {
    result.push(prop);
}
 
result.toString();
//Chrome -> "1, 2, 3, foo"
//Other browsers -> "3, 2, foo, 1"

En el caso de un array, parece respetarse el orden de los índices en todas las plataformas testadas. Sin embargo, al no estar estandarizado este comportamiento, no deberíamos confiar en que siempre se devuelvan los valores en el orden esperado. Si dicho orden no resulta crítico para el flujo de nuestra aplicación, podemos entonces utlizar este método de forma segura.

¿Y si hablamos de rendimiento?

Visto el punto anterior, puede resultar interesante analizar qué resulta más óptimo cara al rendimiento de un script: recorrer un array con un bucle for tradicional o mediante esta variante del for-in… Pues midamos!

Para realizar las métricas, utlizaremos el servicio online JSPerf en el que se han montado los siguientes scripts:

// Testing 'for' performance
var myArr = [ 'En', 'un', 'lugar', 'de', 'la', 'Mancha', 'de', 'cuyo', 'nombre', 'no', 'quiero', 'acordarme' ],
    myArrClone = [];
 
// Preparo un array de pruebas
for( var x = 0, i = myArr.length; x < i; x++ ){
    myArrClone.push( myArr[x] );
}

Y, para la variante for-in:

// Testing 'for-in' performance
var myArr = [ 'En', 'un', 'lugar', 'de', 'la', 'Mancha', 'de', 'cuyo', 'nombre', 'no', 'quiero', 'acordarme' ],
    myArrClone = [];
 
for( var element in myArr ){
  myArrClone.push( element );
}

Los resultados son claros:

Cuando hablamos de recorrer un array, el método tradicional resulta hasta un 400% más rápido.

Conclusión

Tras revisar las métricas anteriores, queda de manifiesto que el uso del bucle for-in debería limitarse únicamente a recorrer un objeto tradicional (aquel que implementa pares de nombre/valor) y nunca un array. Esta afirmación responde a una cuestión de rendimiento patente en las estadísticas.

Una vez asumido el punto anterior, conviene saber que existen dos formas de construir este estamento: una básica en la que definimos una variable y a la que se asigna el nombre de la propiedad correspondiente en cada iteración y, una segunda en la que dicho nombre se asocia al resultado de evaluar una expresión. Con respecto a esta última estructura, descubrimos que podemos obtener errores inesperados debido a que el intérprete puede encontrarse con expresiones sin sentido (aún correctas sintácticamente) dentro de la lógica de la instrucción.

No podemos garantizar en ningún caso el orden en que se recorreran las propiedades de nuestro objeto por lo que, en caso de que dicho orden resulte crítico para nuestra aplicación, debemos buscar alguna forma alternativa de almacenamiento como, por ejemplo, un array tradicional.

Para saber más

Angus Croll, Exploring JavaScript for-in loops
Peter van der Zee, for-in grammar
ECMA262, The for-in Statement