martes, 27 de mayo de 2014

Ejemplo juego 4 en raya con KnockoutJS

Hola de nuevo,
Con mi último proyecto MVC utilizando jQuery, he podido comprobar quan maravilloso es este framework, no obstante también me he encontrado con un problema muy conocido también por la comunidad, en el escenario de aplicaciones con lógica de cliente compleja, jQuery presenta problemas de mantenimiento.

El problema radica en que la lógica queda muy vinculada a las clases definidas en el DOM, lo que provoca que cualquier cambio CSS/HTML afecte directamente a la programación jQuery.

Para esto viene a rescatarnos KnockoutJS, cómo bien digo en otros posts, no me gusta repertir, si quereis aprender KnockoutJS visitar su página. Aquí dejo una pequeña aportación de un juego realizado con KnockoutJS, se puede descargar de este link de google drive, pero os recomiendo echarle un vistazo al artículo de codeproject, donde está documentado el código, además de estar disponible siempre la última versión.

Utilidad: Divertirse y ver un ejemplo de binding de KnockoutJS a un array de objetos, se puede apreciar que el binding bidireccional (MVVM) que provee este framework facilita mucho la programación de la interfaz.

Aquí un screenshoot


martes, 8 de abril de 2014

Patrón Service Locator en C#

Ejemplo de patrón Service Locator en C#

Para aplicar el principio de inversión de dependencias, son muy conocidos los contenedores IoC y la inyección de dependencias, otra forma de aplicar el principio, es crearse un repositorio donde parametrizar la creación de objetos, y llamar a este repositorio dentro de la clase que lo necesite, sin inyectarlo a través del constructor.

Utilizar un repositorio de este tipo es conocido cómo el patrón "Service Locator", a continución se muestra un sencillo ejemplo de uso e implementación.

Dada una interfaz de objetos:
  public interface InterfaceX

, y una clase Y, que necesita utilizar un objecto de la InterfaceX, podemos aplicar el patrón de inversión de dependencias aplicando el patrón Service Locator, de la siguiente forma:

   public class Y{
       public InterfaceX data { get; set; }
       public Y()
       {
            //aplicar el patrón Service Locator con el método GetObject
            //de la clase ServiceLocator_InterfaceX definida abajo
            data = ServiceLocator_InterfaceX.GetObject("ClaseX1");
       }
   }

Implementación del repositorio Service Loctor

 public static class ServiceLocator_InterfaceX
    {
        public static InterfaceX GetObject(string ObjectName)

        {
            switch (ObjectName){
                case "ClaseX1":
                    return new ClaseX1();
                default:
                    break;

            }
            return new ClaseXDefault();
        }
   }

domingo, 16 de febrero de 2014

Desambiguación IOC y DI

Desde hace pocos años, con la moda de las buenas prácticas en programación,  SOLID y  TDD, están muy presentes en este escenario los términos IoC y DI(Dependency Inyection o Inyeccción de dependencias) más adelante explico porque tacho este término

Después de leer muchisimos artículos en Internet sobre el tema, interpreto que hay muchísima confusión con estos dos términos; voy a dar mi opinión de porque: Resulta que dentro del contexto de los principios SOLID de la POO, está el principio D, que se llama Inversión(no inyección) de Dependencias y dice que debemos depender de abstracciones, no de concreciones.

En el contexto de una clase, se tiene por norma la siguiente regla basada en este principio:
Nunca instanciar una clase B dentro de una clase A, lo correcto es: 
o bien recibir por parámetro la clase B (o interfaz B)
, o depender de una interfaz de la clase B, pero nunca de una clase concreta

¿Y cómo aplicamos la regla basada en este principio?, pues bien hay dos opciones:

  1. Inyectar la clase por el constructor, o también una interfaz, al instanciar la clase pasarle por parámetro el objeto concreto.A esta técnica o patrón se le llama DI (Inyección de dependencias), y debido a su similitud léxica con el principio D(Inversión de dependencias) es la causa de confusión entre los términos, porque el principio es inversión, no inyección, y la técnica o patrón sí que es la inyección.
    En muchos posts sobre el tema leeremos,
    "aplicar el principio de Inyección de Dependencias"
    , pero esto no es correcto, porque el principio es la inversión, no la inyección.

  2. Crear un repositorio de factoría de objetos en el que asociar interfaces con objetos concretos (vease este post), dentro de la clase está permitido llamar al repositorio para obtener objetos, pero nunca instanciar objetos directamente.

    Este segundo patrón se puede combinar con el primero puesto que son compatibles, es decir, tener un repositorio de objetos e inyectar a la clase la interfaz. Esto es lo que hacen muchos IoC contaniers (Unity, Ninject, spring.NET, etc...)

    En este contexto opino que es correcto llamar al repositorio de objetos IoC, puesto que este es un agente que servirá para instanciar objetos, no será necesario que los instanciemos nosotros, de hecho este término se cita en algunos posts aludiendo al principio de Hollywood ("No nos llame, le llamaremos nosotros")

    Opino por tanto que sí que es correcto el uso de este término, aunque puede crear cierta confusión con respecto a lo que IoC significa, ya que IoC es un término que ya se usaba antes en informática y está vinculado al patrón Observer, es decir que cualquier evento se puede decir que está usando IoC, por ejemplo el clic de un botón..., en cualquier caso no es el objetivo de este post discutir sobre este término sino sobre el de DI.

En el contexto de combinación de los dos patrones, podemos encontrar en muchos posts 
"Aplicamos el principio Inyección de Dependencias utilizando IoC"
, púes bien opino que esto no es correcto, que se está definiendo así en muchos posts debido a la confusión del término que he descrito antes, y lo correcto sería decir
"Aplicamos el principio Inversión de Dependencias combinando Inyección de dependencias e IoC"

Bueno, al menos esta es mi opinión sobre porque el uso del principio Inversión de de dependencias se ha confundido con el patrón Inyección, no obstante se aceptan alegaciones en contra.

jueves, 13 de febrero de 2014

IoC y el patrón Factory


IoC y el patrón Factory , o, ¿Porqué lo llaman IoC cuando quieren decir repositorio de objetos?

El objetivo de este post es relacionar el concepto IoC con el patrón Factory y presentar un ejemplo de aplicación, pero no define con detalle que es, ni tampoco explica ninguno de los numerosos frameworks que hay para ello (Unity, Spring.Net, Ninject, Windsor, y alguno más que me dejo...).

Siguiendo la linea habitual de este blog, no prentendo ni  voy a tratar de explicar que es IoC, así me evito que nadie me entienda (no os sintáis ofendidos, yo tampoco me entendería), voy a exponer un ejemplo de cómo aplicar el patrón en el que se aprecia su relación con el patrón Factory.

Bien, para mi, a groso modo, IoC en el contexto de inyección de depencencias, es simplemente un repositorio de creación (instanciación) de objetos, fuera de este contexto es otra cosa (quizás algún día decida hacer un post sobre esto), sin embargo la moda a día de hoy es hablar de IoC en este contexto, y cómo este es un blog moderno, pués es de lo que vamos a hablar.

¿Y cómo se crea un repositorio de creación de objetos?, pues fácil, aplicando el patrón Factory, así que, si queremos jugar a reinventar la rueda, divertirnos un poco, y de paso, entender lo que estamos haciendo cuando usamos IoC (En el contexto de inyección de dependencias), te invito a que le eches un vistazo. Por contro si lo que buscas es un framework IoC, pues te reecomeniendo que te mires Unity, Ninject o Spring.NET.


Bien, para no hacer tropocientas lineas de código pongo un ejemplo facilito y conceptual del tema. Para entenderlo se asume que estas familiarizado con las interfaces, y el concepto de inyección de dependencias.

Dada una interfaz de objetos:
  public interface InterfaceX

, y una clase Y, que necesita usar un objeto de la InterfaceX, y a la que queremos aplicar inyección de dependencias
   public class Y{
       public InterfaceX data { get; set; }
       public Y()
       {
            //aplicar IoC con el método GetObject
            //de la clase FactoryObjects_InterfaceX definida abajo
            data = FactoryObjects_InterfaceX.GetObject("ClaseX1");
       }
   }

, Si construimos una clase estática como la que pego abajo, ya estamos aplicando IoC a través del patrón Factory, sin usar ningún framework, y dicho sea de paso reinventando la rueda.

 public static class FactoryObjects_InterfaceX
    {
        public static InterfaceX GetObject(string ObjectName)

        {
            switch (ObjectName){
                case "ClaseX1":
                    return new ClaseX1();
                default:
                    break;

            }
            return new ClaseXDefault();
        }
   }
Observar que lo único que se está haciendo es llamar a una factoría de objetos pasándola por parámetro el nombre de una clase para que esta nos devuelva la instancia. Pues bien, a toda esta monserga es a la que hoy en día los posts de Internet llaman IoC,  o DI con IoC,  o IoC con DI, no se ponene de acuerdo, y yo me pregunto, ¿porque tanto llamarlo IoC cuando quieren decir repositorio de objetos? , cómo antes he dicho IoC es un concepto más general del que tal vez me anime a hablar otro día.

En definitiva que para no cumplir con mi promesa inicial, digamos que para mi, "lo que a día de hoy" todos llaman  IoC es:

"Aplicar el patrón factory para instanciar objetos a través de un repositorio centralizado, de esta forma se consigue que en el contexto de una clase, se puedan desacoplar la instanciación de otras clases, consiguiendo así clases más limpias, que, al menos en ese contexto respetan el principio S(Single Responsability) y como consecuencia de ello son mejores para mantener, reutilizar, y probar."

Esto de que se puedan probar es otro tema, digamos que podemos aplicar la técnica descrita y tendremos clases más testeables, lo cual no quiere decir que necesariamente lo vayamos a hacer ni que estemos aplicando TDD, pero al menos estamos aplicando preTDD,  "Desarrollo Guiado Para Que Se Pueda Probar".

¿Has llegado hasta aquí? gracias y enhorabuena.





sábado, 8 de febrero de 2014

Grid MVC edit inline

Aquí dejo el link de mi artículo en codeproject.com sobre cómo hacer un grid estilo excel, con edición rápida en linea, utilizando MVC, JQuery y AJAX.

http://www.codeproject.com/Tips/720348/MVC-Grid-Inline-Edit


sábado, 1 de febrero de 2014

Art programming

Hola,
 hoy vamos a hablar del Art programming, a ver si mi colega Canx se anima, ahí va una pequeña pieza de arte:

public void AnyFunction(){
    //cosas
    //más cosa
    using(new España()){
    }
    //y más cosas
}

Canx, ¿Sigues?

jueves, 14 de noviembre de 2013

Prototype en Javascript. ¿Y eso que es?

Hola de nuevo,

Voy a tratar el tema de prototype de forma "literaria", los artículos más técnicos de momento los publico en codeproject.com, ya que tiene más lectores que este estupendo blog.

El tema a tratar hoy es:

Prototype en Javascript. ¿Y eso que es?

Permitirme el defecto de formato, que no de forma, en el título, cosas del SEO :-)

Bien, vayamos al grano, mi profesor del colegio, JA, decía que hay dos normas básicas a la hora de definir algo, una es no incluir la propia palabra en la definición, y la otra es "no decir lo que no es".
Pues bien, para el caso de prototype, encaja bien decir "lo que no es" ya que es una "cosa" que da lugar a mucha confusión según el contexto donde lo leas y quien lo haya escrito, así que mi primer consejo para comprender que es prototype es leer este post, y después no volver a leer ningún otro nunca más, así no nos invadirán las dudas.

Siendo científicos prototype es
"Una propiedad de todos los objetos de Javascript, que actúa como plantilla para los objetos"
 o,
"Una propiedad para añadir propiedades y/o métodos a una clase".

Bien, pues después de estas definiciones wikipedikas, que no ha entendido nadie, yo tampoco, voy a seguir con mi definición de "lo que no es", ya que enciclopedias ya hay muchas, y esto es literatura,

Prototype NO:

1) No son métodos estáticos, "son algo parecido"

2) No son métodos de extensión aunque pueden servir para este propósito

3) Puede servir como herencia, pero no es herencia

Porqué:

1) Es la forma correcta de declarar métodos dentro de objetos (funciones, esto es otro tema) en javascript. Según el ejemplo que veas en Internet, permiten una sintaxis que "hace pensar" que son métodos estáticos, pero en realidad no lo son. Esa sintaxis es la siguiente:
 
           NombreClase.prototype.metodo = function () { codigo }

Bien, ¿Verdad que parece un método estático? Pues bien, no lo es, ya que los métodos declarados de esta forma son llamados por instancias de objetos y el código de estos métodos tiene acceso a las propiedades del mismo. Por tanto no son métodos estáticos aunque su sintaxis lo parezca.

Es la forma correcta de declarar métodos en una clase, pero por un tema de funcionamiento interno de javascript, al añadir los métodos dentro de la propiedad prototype, su definición solo se almacena una sola vez en memoria, cosa muy recomendable si vamos a crear múltiples instancias de una clase, e insignificante si la utilizamos como singleton o "pairLeton". Pero las buenas prácticas, dicen que debes declararlo así.

En Javascript, realmente no existen los métodos estáticos. Eso sí, si un método de prototype no accede a ninguna propiedad de la clase, se parece bastante a un método estático, ¿no?
Pues se podría decir que sí, que "se parece", pero no lo es.

2) No son métodos de extensión, veamos este ejemplo:

Date.prototype.mondayOfWeek = function () {
    return (this.addDays((6 - (7 + (this.getDay() - 2)))));
}

A ver, eso en C# se llama método de extensión.   Cierto, a la clase Date, clase nativa de Javascript de la que no tenemos acceso a su código,  le estamos añadiendo la propiedad "mondayOfWeek", eso sin ninguna duda en .NET se llama método de extensión.

Sí, pero prototype no tiene solo esta finalidad, por tanto prototype "sirve para extender métodos, pero no es exclusivamente eso, por tanto no es un método de extensión. Por hacer una comparativa un "yogur tiene leche" pero "no es leche"

Ojo al dato, prototype también se puede usar para añadir métodos a instancias concretas de objetos, por tanto en ese caso estaría actuando como "decorador"

3) No es herencia pura, sirve para hacer herencia, pero no la herencia que estudiamos de toda la vida, con propiedades publicas/privadas/protegidas, es más bien composición. Con prototype se consigue que una clase "Hijo" contenga a toda una clase "Padre" de la siguiente forma

Hijo.prototype= new Padre();

pero esto no significa que "Hijo" hereda de "Padre" y accede a sus métodos públicos y protegidos, sino que directamente Hijo "Tiene" un Padre entero. Ciertamente se aproxima bastante a la herencia, pero no la de los libros. Todas las instancias de la clase "Hijo" contendrán todas las propiedades y métodos de la Padre, sin distinción de acceso privado/publico.  Se podría decir que es "herencia Full", termino que no debéis buscar porque creo que no existe, pero se entiende, o eso creo, no esto seguro...


Bueno, pues en resumidas cuentas prototype se podría definir como:

"Una propiedad de todos los objetos de Javascript con la que se pueden implementar/simular las características principales de la POO: Herencia, extensión, polimorfismo, decoración, métodos estáticos" 

Si nos podemos a mirar con lupa cada una de estas características siempre encontraremos matices, peros, en los que nos podremos basar para afirmar que "se parece a Herencia, .... " pero "NO lo es"

Y es que los tipets que implementaron prototype para Javascript creo que debían estar pensando en lo siguiente

"La gente critica Javascript porque dicen que no es un lenguaje con funcionalidades POO, pues bien, vamos a hacer una 'cosa', con la que se podrá 'simular' los aspectos principales de la POO"

Y a mi entender, lo consiguieron, efectivamente, y es que estos últimos meses, estoy encantado de conocer mejor Javascript, un lenguaje muy flexible que como mi buen amigo Cancho (principal, y casi único lector de este blog) dice, ha sido injustamente tratado, tal vez por desconocimiento


Bueno, como decía al principio, el blog lo dejo para reflexiones filosóficas, si a alguien le interesan los temas más técnicos puede seguirme en codeproject.com, aquí dejo el link a un articulo, "simular" LINQ para JQuery.
http://www.codeproject.com/Tips/665477/LINQ-to-JQuery

Y en el próximo post hablaré de un cuento muy divertido de los "three monkeys", dejaré un link al cuento, contaré una anécdota y daré mi opinión sobre el.

Si has llegado hasta aquí, tiene mérito, saludos.