Archivo etiqueta Ingenieria del software

Closures en JavaScript. Patrón Modulo

Si hace un tiemplo comentaba que en JavaScript el patrón singleton es implícito, voy a revisar otro patrón que sirve para modularizar nuestro código. Las clausuras de JavaScript o Closure es algo que tiene que conocer cualquiera que se dedique en profundidad a este lenguaje.

Closures
Una closure es en definitiva un objeto que es definido e instanciado en el momento de su declaración. Así hay que tener en cuenta que esta metodología cumple el patron modulo, al declarar el módulo, y el singleton, ya que no permite reinstanciaciones del mismo objeto porque se declara y se ejecuta.

var clos = (function(){

	var vprivada=999; // solo accesible desde esta closure

	function fprivada(param){
		vprivada=param;
	}

	var prop={};
	prop.funcion=function(){
		document.write("123456789");
	}
	prop.variable=119;

	return prop;

}());

Como la función es ejecutada al mismo tiempo que es declarada es necesario devolver el objeto que se genera dentro de ella. Si no asignamos la función a nada la closure es anónima, pero no deja de ejecutarse por ello.

Aumentar la closure
Para ampliar las propiedades de nuestro objeto podemos escribir otra closure y asignársela, el problema es que si lo hacemos sin más perdemos las propiedades anteriores, por eso debemos pasarle por parámetro todo el código anterior, es decir, la misma closure.

var clos=(function(prop2){

	prop2.funcion2=function(){
		document.write("999888777");
	}
	prop2.variable2=219;

	return prop2;
}(clos));

En caso de que no exista podemos crear una nueva closure al vuelo para evitar los errores de ejecución.

var clos=(function(prop){

	...

	return prop;
}( clos|| {} ));

De esta manera podemos distribuir nuestro código entre distintos archivos en caso de que fuese necesario. En una página donde tengamos implementadas pocas funcionalidades esto no es necesario, pero cuando va creciendo la cantidad de cosas que queremos hacer con JavaScript, modularizar el código de esta manera resulta bastante útil.

También es importante saber que podemos extender nuestra closure con otras para hacerla más rica. Así incorporando librerías de terceros (como jQuery) podemos personalizar el producto a nuestras necesidades. Esto podria considerarse un tipo de herencia implicita, para ver la herencia explicita aquí.

Ya he visto que en ciertos perfiles laborales se indica explícitamente el conocimiento de closures. Cuando estamos programando en paralelo con un compañero de trabajo y se dividen las funcionalidades a programar, debe de hacerse con aumentos de closures, que hace fácil unificar el código y también puede permitir acotar a la hora de buscar fallos.

, , , , , , ,

No hay Comentarios

Patrón Singleton implícito en JavaScript

Uno de los tantos patrones arquitectónicos en ingeniería del software es el llamado Singleton. No voy a explicar el patrón singleton por completo, simplemente decír que como idea principal se define una clase de la que solo existirá una instancia.

Por lo tanto en una clase qu cumpla con el singleton se define el método getInstancia() que solo se ocupa de devolver la única instancia existente. Así que el constructor no se ejecuta siempre, solamente invoca cuando no existe ninguna instancia. Cuando si la hay se devuelve la referencia a ella. Así de sencillo.

Y esto se implementa así en cualquier lenguaje orientado a objetos. De hecho incluso en JavaScript se puede implementar una clase con estas caracteristicas, el unico problema es que en JavaScript no hay métodos privados y siempre podría hacer un new miClase() y me devolveria una instancia nueva.

Pues bien, hay una caracteristica en JavaScript que me hace pensar que esto se puede hacer sin ningun problema, solo por las caracteristicas del propio lenguaje, ya que una funcion es una funcion y una variable también puede serlo etc. y jugando con esto podemos definir una clase que compla el partrón implicitamente y otra que no.

Definir el objeto

Objeto que no cumple el patrón singleton:

function objetoNoSingleton(){
   this.cadena = "cadena de texto";
   this.metodo = function(){
      alert(cadena);
   }
}

Objeto que cumple el patrón singleton:

var objetoSingleton = {
   cadena : "cadena de texto",
   metodo : function() {
      alert(cadena);
   }
}

Este objeto singleton es una variable y un objeto, pero es un objeto de clase irreproducible, de hecho al ejecutar new objetoSingleton() la instrucción falla.

Añadiendo funcionalidades

Existen diferencias de sintaxis debido al lenguaje. De hecho si queremos utilizar la propiedad prototype (no la libreria) para añadir métodos o variables a los objetos también existen diferencias.
Objeto que no cumple el patrón singleton:

objetoNoSingleton.prototype.valor2 = "valor dos";
objetoNoSingleton.prototype.metodo2 = function(){
   alert(valor2);
}

Para ser ejecutado necesitamos una instancia ya que estamos añadiendo funcionalidades a una clase no a un objeto en particular:

var instanciaNoSingleton = new objetoNoSingleton();
instanciaNoSingleton.metodo2();

Objeto que cumple el patrón singleton no hay que usar prototype. Crear un nuevo elemento en el objeto es simplemente nombrarlo y asignarle valor porque ya es una instancia.

objetoSingleton.valor2 = "valor dos";
objetoSingleton.metodo2 = function(){
   alert(valor2);
}

objetoSingleton.metodo2();

Con un objeto único se elimina el método getInstancia() típico del patrón Singleton, pero en si también desaparece la función new, por lo que en realidad el objeto a usar va a ser siempre la misma instancia.

, , ,

1 Comentario

UP y desarrollo ágil. Estragegia para triunfar en un proyecto

Las metodoligías ágiles, en lo que a modelos de proceso se refiere no son ya algo nuevo, pero puede que sí lo sea su uso. Como en general todo lo que se decidió usar a raíz de la crisis del software, hace más de 20 años, es en la actualidad cuando la industria del software se va dando cuenta que es útil.

El proceso unificado (UP) combina buenas prácticas comunmente aceptadas, un ciclo de vida iterativo y desarrollo dirigido por los riesgos (risk-driven), esto es, los riesgos son abordados para ser solucionados cuanto antes. Se considera un riesgo aquellas partes en las que las decisiones a tomar son criticas.

Etapas del UP

Etapas del UP

El proyecto software será dividido en iteraciones. Las iteraciones se pueden considerar unidades de desarrollo. Cada una es un miniproyecto. En la literatura (larman.pdf) al respecto del modelo UP (o RUP en ocasiones por Rational UP) se puede encontrar como consejo a la duracion de una iteración entre 2 y 6 semanas. Y a demas las iteraciones seran de duración fija, así que si en una iteración tenemos demasiado trabajo es momento de no dormir, y planificar menos tareas para la proxima iteración.

El resultado de una itración es un sistema ejecutable pero incompleto, NO un prototipo, el desarrollo iterativo no es prototipado. Lo que se tendrá es un subconjutno del sistema final.

Pero lo que caracteriza realmente los modelos ágiles es la relacion con el cliente. El cliente siempre que se le entrege algo lo probará y dira:  “sí, es lo que yo queria … pero”. Las continuas entregas y rectificaciones del cliente nos ayuda a adaptar el producto a las necesidades de quien nos contrata para desarrollarlo.

Así cada ciclo de desarrollo se convierte en un proceso de:

Construcción-Retroalimentación-Adaptación

Entregarle al cliente lo que él quiere y no lo que pensó sin mucha idea cuando firmó el contrato es lo que hace que los proyectos concluyan satisfactoriamente. Dentro de los modelos ágiles hay muchas variantes, el UP es una de ellas que da buenos resultados.

, , , ,

2 Comentarios