Jorge Serrano - MVP Visual Developer - Visual Basic : .NET Framework 3.0, Visual Studio 2010

Objetos Singleton, Objetos Transient y Persistencia de objetos - Lo que un Dummy debe saber

Jorge Serrano — Fri, 18 Nov 2011 14:00:00 GMT

Introducción

Continuando con las entradas tipo Dummies, vamos con otra.

En esta ocasión le toca el turno al patrón Singleton y a Transient, que a veces escuchamos o podemos escuchar y que nos deja un poco fuera de juego, pero como veremos, no es ninguna idea nueva maléfica ni nada por el estilo. Finalmente, comentaré de forma muy breve algún detalle sobre Persistencia simplemente para tenerlo ahí en la mente.

¡Vayamos allá!.

Singleton

Empezamos por el patrón Singleton. Quizás el único patrón realmente simple.
Y ya que nombro la palabra "único", eso es precisamente lo que es un Singleton.
Un patrón de diseño que identifica una única instancia de una clase, proporcionando de esta forma, un único camino o punto de acceso al objeto.
Esto significa que en memoria tendremos siempre un único objeto del tipo que implemente el patrón Singleton.

Ahora bien, como buen patrón, deberemos diseñarlo adecuadamente. Y es quizás el matiz "adecuadamente" el que debemos cuidar... pero no nos anticipemos aún.
La idea detrás del diseño del patrón Singleton es preguntar si ya existe en memoria (si está instanciado ya), y en base a ello, reutilizar su instanciación, o bien, instanciar el objeto en memoria.

No tiene más complicaciones. Así de primeras, parece sencillo ¿verdad?.
Pese a todo, quizás la duda resida a la hora de implementar el patrón en una clase que diseñemos, así que vamos a resolver esta posible duda creando una clase de ejemplo que nos sirva para mostrar como trabajar con el patrón Singleton.

Partiremos de la siguiente clase.

namespace OOP

{

     public class Saludo

     {

        private string name = string.Empty;

  

        public Saludo() 

        {

        }

  

        public string GetName() 

        {

            return name;

        }

  

        public void PutName(string personName) 

        {

            name = personName; 

        }

    }

}

Para consumir esta clase, ejecutaremos el siguiente ejemplo de código dentro de un formulario de Windows.

OOP.Saludo saludo1 = new OOP.Saludo(); 

saludo1.PutName("Paula");

OOP.Saludo saludo2 = new OOP.Saludo(); 

saludo2.PutName("Antonio"); 

MessageBox.Show(saludo1.GetName() + 

                Environment.NewLine + 

                saludo2.GetName());

El resultado de ejecutar esta instrucción sería:

Paula
Antonio

Como podemos apreciar, una clase sencilla de utilizar y de entender.
Ahora bien, tal y como vemos aquí, lo que en realidad tenemos es un objeto Saludo y dos instancias del mismo objeto en diferentes lugares de memoria, es decir, dos objetos totalmente independientes.

Esto como podemos entender, no es lo que buscamos, ya que lo que perseguimos es crear una instancia única en memoria, es decir, que sólo haya un objeto Saludo y que éste sea accesible en el mismo punto, y aquí obtenemos dos instancias independientes, por lo que esto que hemos intentado no es el patrón Singleton. Sin embargo, nos apoyaremos en esta clase para crearla como Singleton tal y como veremos a continuación.

La creación de la instancia única debería ser por otro lado y en principio, responsabilidad de la propia clase que deseamos que actúe como Singleton. ¿Para qué delegar esta responsabilidad en "algo externo" cuando la propia clase puede conocer si ya está instanciada o no?.
Ella mejor que nadie que controle esta característica digo yo.
Una rápida aproximación de un patrón Singleton teniendo en cuenta todas estos requisitos sería la siguiente clase Saludo que reutiliza la base de la clase apuntada anteriormente, y que queda de la siguiente forma:

namespace OOP 

{ 

    public class Saludo 

    {

        private static Saludo saludo = null;

        private string name = string.Empty;

    

        public Saludo() 

        { 

        }

   

        public string GetName() 

        { 

            return name; 

        }

  

        public void PutName(string personName) 

        { 

            name = personName; 

        }

  

        public static Saludo GetSingletonInstance() 

        { 

            if (saludo == null) 

            { 

                saludo = new Saludo(); 

            } 

            return saludo; 

        } 

    } 

}

El consumo de esta clase quedará ahora de la siguiente forma:

OOP.Saludo saludo1 = OOP.Saludo.GetSingletonInstance();

saludo1.PutName("Paula"); 

OOP.Saludo saludo2 = OOP.Saludo.GetSingletonInstance(); 

saludo2.PutName("Antonio"); 

MessageBox.Show(saludo1.GetName() + 

                Environment.NewLine + 

                saludo2.GetName());

El resultado de ejecutar esta instrucción sería:

Antonio
Antonio

El hecho es que la referencia de saludo1 y saludo2 apuntan al mismo objeto, instancia única de Saludo, que actúa como Singleton:

Ahora bien, ¿hemos acabado ya?... pues no, esto no es suficiente como trataré de explicarte a continuación.
El patrón Singleton que he representado anteriormente sobre la clase Saludo es mejorable.
Aunque pueda funcionar en algunos escenarios, sabemos a ciencia cierta que no va a funcionar en todos los escenarios posibles, así que la mejor forma de resolver el problema es hacer que nuestro Singleton sea estable.

Voy a ser un poco estricto en mis argumentos.

El hecho es que al trabajar con múltiples hebras, el patrón representado podría generar conflictos o problemas de concurrencia.
Otro problema asociado y que he dejado abierto, es que la clase no está sellada (sealed), por lo que si alguien hereda de la clase, podría generar en principio más instancias de las que yo mismo querría. Pero pese a que no fuera inicialmente una clase decorada como sealed, podríamos evitarnos el problema de crear más instancias declarando el constructor público como privado, impidiendo crear una instancia de la clase, algo que intentamos evitar.
No obstante, algo que sí hemos resuelto aquí es la inicialización de la clase que podríamos definir como perezosa, es decir, instanciaremos la clase con GetSingletonInstance sólo y cuando la vayamos a utilizar. Pero pese a que tenemos una función GetSingletonInstance, ésta no resuelve el problema de la concurrencia (dos hebras intentando al mismo tiempo instanciar la clase cuando aún no está creada).

Sin resolver aún el problema de la concurrencia, volvamos a revisar como quedaría nuestra clase con las otras modificaciones aplicadas:

namespace OOP 

{ 

    public sealed class Saludo 

    { 

        private static Saludo saludo = new Saludo();

        private string name = string.Empty;

  

        private Saludo() 

        { 

        }

  

        public string GetName() 

        { 

            return name; 

        }

  

        public void PutName(string personName) 

        { 

            name = personName; 

        }

  

        public static Saludo GetSingletonInstance() 

        { 

            if (saludo == null) 

            { 

                saludo = new Saludo(); 

            } 

            return saludo; 

        } 

    } 

}

El uso de esta clase quedará de la siguiente manera:

OOP.Saludo saludo1 = OOP.Saludo.GetSingletonInstance(); 

saludo1.PutName("Paula"); 

OOP.Saludo saludo2 = OOP.Saludo.GetSingletonInstance(); 

saludo2.PutName("Antonio"); 

MessageBox.Show(saludo1.GetName() + 

                Environment.NewLine + 

                saludo2.GetName());

En este caso, obtendremos como resultado:

Antonio
Antonio

Bien, vamos afinando nuestro Singleton, pero aún no es suficiente. Seguimos dejando abierto el problema de la concurrencia que comentaba anteriormente.
Así que sin seguir ahondando más en los posibles problemas, vamos a remangarnos y a pensar en mejoras o soluciones al respecto.

Para resolver los problemas de concurrencia, podemos hacer uso del chequeo doble, que consiste en que primero preguntamos si la instancia es null (tal y como hacemos hasta ahora), y una vez preguntado esto, chequeamos nuevamente.
Antes de continuar diré que la pregunta de si la instancia es null o no, no evita la problemática de que dos hebras entren en el mismo tiempo t al mismo punto y continúen, por lo que en este caso generarán dos instancias en lugar de una, de ahí que tengamos que chequear nuevamente.
Este nuevo chequeo consiste en que una vez pasada la validación de si es null, bloqueamos el objeto de forma que sólo una de las hebras que han entrado justo en el mismo momento t, pueda crear la instancia. La otra hebra (hablamos de milisegundos) entrará en el segundo chequeo una vez que la primera hebra ha liberado el bloqueo.
Dentro de este chequeo volvemos a preguntar si la instancia es null, así que si la primera hebra entró, cambiaría la instancia por not null y por lo tanto, las hebras que realizaron la petición en el mismo instante t, se encontrarán la hebra creada y no creará una nueva instancia.

Una imagen que resuelva esto es la que indico a continuación:

1) De acuerdo a esta imagen, dos hebras entran en el mismo momento t de ejecución a pedir una instancia de Saludo a la función GetSingletonInstance.
2) Ambas en un tiempo t que puede oscilar milisegundos con ínfimo margen de diferencia entre una y otra petición, preguntan si la instancia de la clase es null, recibiendo ambas peticiones la respuesta afirmativa.
3) En ese instante utilizamos la instrucción lock.
Esta instrucción tiene como propósito general bloquear exclusivamente una porción de código.
Ojo con el uso de lock porque podemos generar bloqueos que impidan la normal ejecución del resto de procesos que están esperando a que finalice el bloqueo.
El objetivo de lock es que sólo un subproceso podrá estar dentro de la sección identificada como lock, impidiendo que otro subproceso entre cuando hay alguien dentro.
La forma más sencilla de entender esto es pensar en dos personas que entran al mismo tiempo en los baños de un bar. Sólo hay un retrete y los dos quieren acceder al mismo lugar. Uno de ellos entrará dentro y bloqueará la puerta. Hasta que no desbloquee la puerta y salga, el otro no podrá entrar.
4) Imaginemos ahora que la hebra 1 es la que entra dentro de lock, quedando la hebra 2 en espera de poder entrar.
5) La hebra 1 pregunta nuevamente si la instancia de la clase es null, recibiendo una respuesta afirmativa.
6) Dentro de lock aún, la hebra 1 creará la instancia única.
7) Como nota adicional, si ahora entrara una hebra 3, ésta preguntaría al principio de todo si la instancia de la clase es null, recibiendo una respuesta negativa y obteniendo la correspondiente instancia. Cuando esto, porque a veces los bloqueos pueden llegar a penalizar la espera, y en este caso concreto, aunque estemos hablando de milisegundos, es la hebra 2 la que aún está esperando su oportunidad, habiendo llegado la hebra 3 antes que la hebra 2 y obteniendo respuesta antes. ¡Ojo con los bloqueos que podemos crear un desastre!.
8) Continuando con el flujo, cuando la hebra 1 sale de lock, lo libera, y automáticamente entra la hebra 2 que estaba esperando.
9) La hebra 2 preguntará si existe una instancia de la clase, obteniendo una respuesta positiva, por lo que saldrá de lock y obtendrá la instancia.
10) El resto de peticiones entrantes, no llegarán ya nunca más a lock, ya que éste sólo es accesible cuando la instancia de la clase es null, y como ya hemos visto, ya ha quedado creada.

Ahora vamos a ver como queda todo esto en código.

Nuestra clase quedará por lo tanto ahora de la siguiente manera:

namespace OOP 

{ 

    public sealed class Saludo 

    { 

        private static Saludo saludo = new Saludo();

        private static readonly object objectLock = new object();

        

        private string name = string.Empty;

     

        private Saludo() 

        { 

        }

    

        public string GetName() 

        { 

            return name; 

        }

    

        public void PutName(string personName) 

        { 

            name = personName; 

        }

    

        public static Saludo GetSingletonInstance() 

        { 

            if (saludo == null) 

            {

                lock (objectLock) 

                { 

                    if (saludo == null) 

                    { 

                        saludo = new Saludo(); 

                    } 

                } 

            } 

            return saludo; 

        } 

    } 

}

Nota: gracias a Lluis Franco por avisarme de un gazapo que se me había pasado por alto en esta porción de código. Recomiendo leer este hilo.

El consumo de nuestra clase Singleton con un ejemplo, es prácticamente igual a lo que ya hemos visto con anterioridad:

OOP.Saludo saludo1 = OOP.Saludo.GetSingletonInstance(); 

OOP.Saludo saludo2 = OOP.Saludo.GetSingletonInstance(); 

saludo1.PutName("Paula"); 

saludo2.PutName("Antonio"); 

MessageBox.Show(saludo1.GetName() + 

                Environment.NewLine + 

                saludo2.GetName());

El resultado que obtendremos al ejecutar este ejemplo es:

Antonio
Antonio

Pese a todo lo comentado hasta el momento y dependiendo de la criticidad de los sistemas, a veces se fuerza a que la generación del Singleton no sea perezosa y que desde el principio se generen todos ellos evitando posibles demoras y bloqueos. Esto por otro lado, consume una gran cantidad de recursos, sobre todo al comienzo de los procesos que funcionan de esta manera.

Una posible solución es hacer un híbrido de ambas técnicas dependiendo de los requisitos, pero como siempre, no hay una regla exacta que orden hacerlo de una manera o de otra.

Finalmente, me gustaría abordar otra posibilidad a la hora de generar un Singleton en .NET Framework 4.0, y es utilizando la clase Lazy<T>.

Esta clase se ha agregado a .NET Framework 4.0 para aportar compatibilidad con la inicialización diferida, lo cuál encaja a la perfección con el patrón Singleton.
El uso de esta clase, simplifica realmente la generación de un Singleton.
De hecho, la clase Singleton anterior equivalente utilizando Lazy<T> quedaría de la siguiente manera:

namespace OOP 

{ 

    using System;

  

    public sealed class Saludo

    { 

        private static readonly Lazy<Saludo> lazySaludo = new Lazy<Saludo>(() => new Saludo());

  

        private Saludo() 

        { 

        }

  

        public static Saludo GetSingletonInstance 

        { 

            get 

            { 

                return lazySaludo.Value; 

            } 

        }

  

        private string name = string.Empty;

  

        public string GetName() 

        { 

            return name; 

        }

  

        public void PutName(string personName) 

        { 

            name = personName; 

        } 

    } 

}

Y el código que consume el Singleton de esta otra forma:

OOP.Saludo saludo1 = OOP.Saludo.GetSingletonInstance; 

OOP.Saludo saludo2 = OOP.Saludo.GetSingletonInstance; 

saludo1.PutName("Paula"); 

saludo2.PutName("Antonio"); 

MessageBox.Show(saludo1.GetName() + 

                Environment.NewLine + 

                saludo2.GetName());

Indudablemente, el resultado obtenido en esta ocasión no difiere de lo que ya hemos visto hasta el momento:

Antonio
Antonio

Transient

Que no te confundan. En .NET y desde el punto de vista de una clase, un transient (que podríamos traducir como transitorio o fugaz) no es otra cosa que un new en una clase normal y corriente.
Generamos un objeto que se crea, se utiliza, y finalmente se destruye.
Es decir, dura lo que dura la ejecución del objeto en sí. Suele tener un ciclo de vida corto, pero dependerá de la complejidad del proceso y de otras características.

No voy a poner ejemplos porque cualquier clase general es un transient.

Cuando hablamos de Singleton y Transient, hablamos de un objeto de instancia única que puede ser generado perezosamente o no, y un objeto que sólo se crea en un momento, y cuya vida está asociada a la ejecución del proceso, que una vez finaliza es destruido.

Así de sencillo.

Persistencia

Persistir es sinónimo de mantenerse, por lo que si tenemos un objeto persistente, estamos diciendo que ese objeto está almacenándose, guardándose o salvándose en algún medio que permita luego recuperarlo y seguir operando con él si fuera necesario.

Lo más típico es escuchar hablar de persistencia de datos.
La persistencia de datos se puede realizar en memoria, bases de datos, ficheros u otro almacén fiable para llevar a cabo esa persistencia.
Aunque la memoria no es un almacén de persistencia óptimo al ser volátil, es bueno entender que la persistencia puede ser entendida desde un punto de vista purista o más amplio abarcando más posibilidades.

Lo lógico para poder persistir un objeto, es serializarlo. Si queremos serializar una clase, bastará con decorar la clase con el atributo Serializable().

No voy a hablar mucho más sobre la persistencia. Tan sólo quería dejar dos pinceladas sobre el término sin ninguna intención adicional.

Clase base, interface y clase abstracta, ¿amigas o enemigas? - Lo que un Dummy debe saber

Jorge Serrano — Thu, 17 Nov 2011 14:00:00 GMT

Introducción

En esta ocasión, me gustaría tratar aspectos relacionados con la programación orientada a objetos y algunos aspectos básicos generales.

Tengo en mente escribir (y si el tiempo me lo permite) unas cuantas entradas relacionadas con diferentes temas, pero debo empezar por algún sitio, y he creído conveniente hacerlo por la base de todos ellos, así que empiezo por esta para que los diferentes conocimientos que quiero o persigo explicar en futuras entradas tengan sentido y tomen forma.

Seguramente muchos ya conozcan lo que voy a contar, y estoy convencido de que incluso mejor que yo seguramente, así que quiero comentar aspectos relacionados con las clases base, interfaces y clases abstractas... porque... ¿son la misma cosa o no?. ¿Son amigas o enemigas? ¿Sabemos diferenciarlas o relacionarlas adecuadamente?. ¿Cuando debemos elegir una u otra?.

Antes de abordar la parte práctica del tema repasaremos un poco la parte teórica de qué es cada cosa, diferentes aplicaciones, implicaciones y demostraciones prácticas de lo que comente al respecto en cada caso, y finalizar con un pequeño desglose muy breve diferenciando entre clases abstractas e interfaces.

¡Vamos allá!.

Clase base

Una clase base es o puede ser cualquier tipo de clase. Es decir, para que una clase sea una clase base, no necesita nada especial.
Una clase base como tal, puede ser heredada (que es lo más habitual) o instanciada (si queremos acceder a la clase base de forma directa).
Sólo existe una restricción para heredar de ella, y es que la clase base esté sellada (sealed), en cuyo caso no podremos heredar de esa clase base.
Otra ventaja que tienen las clases base, es que podemos igualmente sobreescribir o reemplazar sus métodos y funciones siempre que éstas estén decoradas con virtual y las clases que heredan los métodos y funciones de la clase base, decoradas con override para sobreescribirlas (en C++ creo recordar ahora mismo de memoria que no es necesario este último detalle).
Un ejemplo típico en .NET de este tipo de clases es la clase base System.Exception.
No obstante, vamos a abordar un pequeño ejemplo que nos ayude a comprender esto un poco más.

namespace OOP

{

  

    public class Saludo

    {

        public virtual string GetSaludo()

        {

            return "Hello";

        }

  

        public string GetSaludoCompleto(string name)

        {

            return string.Format("{0} {1}", GetSaludo(), name);

        }

    }

  

    public class SaludoSpanish : Saludo

    {

        public override string GetSaludo()

        {

            return "Hola";

        }

    }

  

}

El código de llamada en un formulario Windows para cualquiera de la clases que implementa la interfaz es el que se indica a continuación:

OOP.SaludoSpanish saludo = new OOP.SaludoSpanish();

MessageBox.Show(saludo.GetSaludo() + 

                Environment.NewLine + 

                saludo.GetSaludoCompleto("Geeks.ms"));

¿Qué información obtendremos por pantalla?.

Hola
Hola Geeks.ms

Aún y así, ¿hay alguna forma de crear una función GetSaludoCompleto en la clase SaludoSpanish que reemplace a la función GetSaludoCompleto de la clase base Saludo?.

Para ver que ocurre, escribiremos el siguiente código en la clase SaludoSpanish:

public string GetSaludoCompleto(string name)

{

    return string.Format("{0} {1}, hablas español.", GetSaludo(), name);

}

En este caso, el IDE de Visual Studio 2010 nos devolverá un warning que nos indicará que estamos ocultando GetSaludoCompleto en la clase base Saludo con GetSaludoCompleto de la clase SaludoSpanish, y que utilicemos una nueva palabra clave si queríamos ocultarlo.

Pese a este aviso, el resultado que obtendremos por pantalla en este caso, sí será diferente:

Hola
Hola Geeks.ms, hablas español.

De todos los modos, ¿cómo hacerlo bien?, ¿cómo resolverlo?.

Bastará con decorar la función GetSaludoCompleto de la clase SaludoSpanish con new de la siguiente manera:

public new string GetSaludoCompleto(string name)

{ 

    return string.Format("{0} {1}, hablas español.", GetSaludo(), name);

}

De esta manera, estaremos ocultando GetSaludoCompleto en la clase base Saludo por la función de mismo nombre pero en la clase SaludoSpanish.

El resultado que obtendremos en pantalla será:

Hola
Hola Geeks.ms, hablas español.

Ahora bien, giremos un poco más la tuerca y vayamos más lejos...

Imaginemos ahora que escribimos el siguiente código con respecto a la última modificación de nuestra clase SaludoSpanish:

OOP.Saludo saludo = new 

OOP.SaludoSpanish();

MessageBox.Show(saludo.GetSaludo() +  

                Environment.NewLine +  

                saludo.GetSaludoCompleto("Geeks.ms"));

¿Qué información crees ahora que obtendremos ahora por pantalla?.

Hola
Hola Geeks.ms

En este caso, tenemos un objeto de tipo Saludo que referencia a SaludoSpanish.

   1: OOP.Saludo saludo = new OOP.SaludoSpanish();

GetSaludo será o pertenecerá en este caso a la clase SaludoSpanish ya que está sobreescrita.
Sin embargo, a la hora de acceder a GetSaludoCompleto, no está accediendo a la función de la clase SaludoSpanish.
Es más, en ningún momento estamos accediendo a la clase SaludoSpanish, sino a una clase base Saludo que referencia a la clase SaludoSpanish.
Esto significa que accedemos en todo momento a la clase base Saludo modificando los miembros, funciones y métodos sobreescritos (referenciados) en la clase SaludoSpanish.
De esta manera, accedemos a la función sobreescrita GetSaludo de la clase SaludoSpanish, pero a GetSaludoCompleto de la clase base Saludo, que corresponde con la declaración que tenemos arriba.

Clase abstracta

Muchas veces se confunde con clase base.
No es que sean muy diferentes, pero ojo, tampoco son la misma cosa. Es importante aclarar este aspecto.
De hecho, una clase abstracta puede contener lógica y funcionalidad, algo que es coincidente con una clase base.
Sin embargo, no es posible instanciar una clase abstracta, mientras que en el caso de una clase base sí tal y como comenté anteriormente.
Es decir, para utilizar una clase abstracta, no tenemos más remedio que heredar de ella.
No obstante, podemos sobreescribir los miembros, métodos y funciones de una clase abstracta, e incluso extender la clase que herede de ella con las particularidades que consideremos oportunas.

namespace OOP

{

    public abstract class Saludo 

    {

        public abstract string GetSaludo();

        public string GetSaludoCompleto(string name)

        {

            return string.Format("{0} {1}", GetSaludo(), name);

        }

    }

  

    public class SaludoSpanish : Saludo

    {

        public override string GetSaludo()

        {

            return "Hola";

        }

    }

  

    public class SaludoEnglish : Saludo

    {

        public override string GetSaludo()

        {

            return "Hello";

        }

    }

}

El código de llamada en un formulario Windows para cualquiera de la clases que implementa la interfaz es el que se indica a continuación:

OOP.SaludoEnglish saludo = new OOP.SaludoEnglish();

MessageBox.Show(saludo.GetSaludo() +  

                Environment.NewLine +  

                saludo.GetSaludoCompleto("Geeks.ms"));

En este caso, la salida por pantalla será la siguiente:

Hello
Hello Geeks.ms

Aquí podríamos aplicar los ejemplos y casuísticas que hemos mencionado anteriormente para las clases bases.

Interfaz

Quizás el uso y diferencia de las interfaces esté más claro que ninguna de las dos anteriores.
En primer lugar, debemos asociar interfaz con comportamiento o mejor aún, con contrato.
Una interfaz expone un contrato que debe cumplirse.
Un ejemplo típico del uso de contratos son los Servicios WCF en .NET.
Básicamente se trata de representar un contrato que debe cumplir cualquier clase que implemente la interfaz. Así de simple y así de sencillo.
Si creamos una interfaz ISaludo con una función GetSaludo, crearemos una clase SaludoSpanish que implemente la interfaz ISaludo y que devuelva en su función GetSaludo un "Hola".
Si creamos una clase SaludoEnglish que implementa la interfaz ISaludo y escribimos la función GetSaludo, ésta deberá devolver "Hello".
Es decir, creamos una interfaz ISaludo que especifica un contrato, en este caso el método GetSaludo.
Este método será implementado, extendido en cada una de las clases que implementen la interfaz agregando en este caso un saludo en el idioma correspondiente.
Desde el punto de vista de programación, una interfaz reúne un conjunto de miembros abstractos.
La puntualización es que en una interfaz sólo se definen los miembros, y nunca se implementa nada.
Los miembros de una interfaz (todos) son públicos por defecto.

namespace OOP

{

  

    public interface ISaludo

    {

        string GetSaludo();

    }

  

    public class SaludoSpanish : ISaludo

    {

        public string GetSaludo()

        {

            return "Hola";

        }

    }

  

    public class SaludoEnglish : ISaludo

    {

        public string GetSaludo()

        {

            return "Hello";

        }

    }

}

El código de llamada en un formulario Windows para cualquiera de la clases que implementa la interfaz es el que se indica a continuación:

OOP.SaludoSpanish saludo = new OOP.SaludoSpanish();

MessageBox.Show(saludo.GetSaludo());

También podríamos haber declarado el siguiente uso:

OOP.ISaludo saludo = new OOP.SaludoSpanish();

MessageBox.Show(saludo.GetSaludo());

Clase abstracta vs Interfaz

Adicionalmente, me gustaría detenerme un poco en la diferencia entre una clase abstracta y una interfaz.
Veo con mucha frecuencia que muchas veces no queda del todo claro.
Y es que mucha gente no conoce bien la diferencia entre una clase abstracta y una interfaz, o en su caso, las confunde... así que permitidme que me detenga aquí un momento para enumerar las coincidencias y diferencias entre ambas.

Interfaz
Como hemos comentado, una interfaz se encarga de definir comportamientos, contratos.
En cada interfaz, podemos declarar métodos, funciones, eventos, delegados o propiedades.
Todos los miembros de una interfaz son públicos y abstractos.
En otro orden de cosas, todo lo que declaremos en una interfaz, deberá ser implementado en las clases que implementen la interfaz.
Una clase por su parte, puede implementar más de una interfaz.
Finalmente, una interfaz no posee estado (data members) o implementación alguna (funciones y métodos).

Clase abstracta
Una clase abstracta puede contener funciones y métodos que serán utilizados por las clases que implementen la clase abstracta.
En cada clase abstracta, podemos declarar métodos, funciones, eventos, delegados, propiedades y variables.
Una clase abstracta puede incluir funcionalidad, al contrario que una interfaz.
Una clase sólo puede implementar una única clase abstracta, ya que no existe soporte para herencia múltiple.
Independientemente de todo lo comentado hasta ahora, una clase que herede de una clase abstracta no tiene porqué implementar ningún método abstracto de la misma ya que como clase derivada, es en sí misma una clase abstracta.
Finalmente, una clase abstracta puede contener estados (data members) e implementaciones (funciones y métodos).
En términos de velocidad o rendimiento, una clase abstracta es más rápida que una interfaz, ya que la clase que implementa la interfaz, debe preparar todas las definiciones de la misma.

Extraer los frames de un gif animado en .NET

Jorge Serrano — Tue, 23 Aug 2011 10:00:00 GMT

Introducción:

A estas alturas creo que no descubro nada si indico que para mostrar un gif animado en una aplicación Windows por ejemplo, basta con agregar el gif animado al control Image.

De esta manera, el gif animado se mostrará en toda su "expresión".

Ahora bien,... imaginemos que lo que queremos es extraer el contenido (los frames) de un gif animado.

¿Cómo lo haríamos?.

Eso es lo que vamos a ver en esta entrada, pero antes, un poco de chicha (si te aburro, puedes ir directamente al código :-D ).

Conociendo un poco más un gif animado:

Un gif animado no es otra cosa que un repositorio compuesto por un conjunto de imágenes gif en orden secuencial.

El formato Gif tiene su origen en el año 1987 (ver referencias para concocer más acerca de Gif), y la bondad de los gifs animados es que gracias a ellos podíamos utilizar en Internet lo que se denominarían banners, término que aún hoy se usa. El formato gif animado sufrió diferentes modificaciones, de hecho se conocen dos formatos, 87A y 89A. El segundo acepta además transparencias.

Lo más interesante de un gif animado es que además de poder contener una secuencia de imágenes gif en un orden determinado, podíamos indicar una frecuencia, delay y otras propiedades propias para cada frame, de tal modo que si queríamos que un frame de la secuencia durara 2 segundos por ejemplo, lo podíamos realizar sin complicaciones.

No me quiero extender más sobre los gifs animados, para eso hay mucha información en Internet.
En referencias os indico un enlace con información adicional.

Posteriormente surgiría el formato png que tenía como objetivo cubrir dos aspectos inherentes a los gifs y que desquiciaban a los diseñadores y empresas.
Por un lado, utilizar un algoritmo de compresión sin pérdida aparente (el algoritmo LZW de gif sí tenía este problema de pérdida de calidad, además de otras limitaciones), y por otro lado, evitar los problemas de patentes de Gif por el uso de LZW (algoritmo de compresión patentado por Unisys). Al ver que las limitaciones de gif eran superadas ampliamente por png, la carrera que se inició en 1995 por adoptar este formato ha sido fulgurante.

No obstante, esto no quita que los gifs animados se hayan dejado de utilizar.

Uso de gifs animados en VB 32 bits:

Recordando tiempos pasados... algo de nostalgia.

¿Cómo usábamos gifs animados en VB?.

Me acuerdo cuando delante de Visual Basic 4 32 bits, Visual Basic 5.0 y Visual Basic 6.0 (no de .NET), teníamos en nuestras empresas la necesidad de agregar gifs animados a nuestras aplicaciones.

Por aquel entonces tenía yo mi web en Internet sobre VB y tuve la oportunidad de conocer a una persona que juntos planteamos el problema de los gifs animados y como resolver este problema junto con la problemática de las licencias.

Como en este mundo el miedo es muy nuestro y teníamos auténtico pavor al tema de quebrar una licencia y desconocíamos si podíamos transgredir ese aspecto o no, me pude hacer con un código en C++ de lectura de gif y la estructura del formato de un gif animado (de esto hace ya un montón de años).

Al principio intenté hacer todo en VB, pero no dí con ello, y mis conocimientos de C++ siempre han sido limitados. Con C++ apenas he hecho una aplicación de Windows 3.1, algún pequeño control VBX y OCX, y alguna pequeñísima cosa más, pero poco más... y desde entonces C++ lo he tenido abandonado.

El caso es que pese a esta pequeña frustación, pude contactar con una persona que conocía más que yo C++ y que tenía la misma necesidad que un servidor y que mucha gente en Internet (poder leer un gif animado desde una aplicación de VB), así que a esa persona le pasé todo lo que tenía yo hecho sobre este tema, y concluyó mejor que yo lo que quería abordar.
Creó un control OCX que se hizo muy famoso y cuyo nombre era Marchoso.ocx (seguro que a más de uno le suena).

Ese control lo puse en mis páginas Web (Mundo Visual - Visual Basic inicialmente, y PortalVB.com posteriormente) y corrió como la pólvora por Internet.
Aún hoy día es fácil conseguirlo.

Creo que nunca ha sabido nadie cómo apareció este control ni de donde... y es que el miedo al tema de licenciamiento como decía anteriormente era muy grande.
Han pasado bastante años desde aquello, así que porqué no desvelar ahora esta pequeña historia. Así, alguno que se preguntara de donde venía Marchoso.ocx puede conocer algo más de la aparición del primer control OCX de VB para la lectura de gifs animados. Su creador salvo que quiera hacerlo público no lo revelaré yo, seguirá en el anonimato mientras quiera. :-)

Conociendo un poco más a Image:

Para poder obtener fácilmente los frames que forman parte de un gif animado, debemos hacer uso del control Image.

El namespace System.Drawing será el utilizado para trabajar con el control Image, sin embargo, también haremos uso de otro namespace, System.Drawing.Imaging.

Y dentro de System.Drawing.Imaging, utilizaremos la clase FrameDimension.

FrameDimension es una clase que no se puede heredar, pero que nos va a permitir interactuar con el control Image para obtener los diferentes frames que constituyen la imagen gif animada.

Gracias a estos dos namespaces, estaremos en disposición de extraer todos y cada uno de los frames que forman parte de un gif animado.

El código:

El siguiente ejemplo muestra de forma práctica como trabajar con el control Image y System.Drawing.Imaging.FrameDimension, y extraer las imágenes o frames que forman parte de un gif animado.

La aplicación de Windows contiene tres controles button y un control pictureBox.

El código de demostración de lo que hemos comentado es el que se indica a continuación:

using System;

using System.Collections.Generic;

using System.Drawing;

using System.Windows.Forms;

  

namespace AnimatedGif

{

  

    public partial class MainForm : Form

    {

  

        public MainForm()

        {

            InitializeComponent();

        } // MainForm

  

  

        private void MainForm_Load(object sender, EventArgs e)

        {

            // Indicamos la ruta y la imagen animada.

            this.Path = @"images\st_patricks_day.gif";

        } // MainForm_Load

  

        /// <summary>

        /// Propiedad con la posición máxima (frames) de la imagen.

        /// </summary>

        public int MaximunPosition { get; set; }

  

        /// <summary>

        /// Propiedad con la posición de la imagen actual.

        /// </summary>

        public int Position { get; set; }

  

        /// <summary>

        /// Ruta en la que se encuentra la imagen gif animada con la que 

        /// trabajaremos.

        /// </summary>

        private string Path { get; set; }

  

        /// <summary>

        /// Colección de imágenes que corresponde con los frames del gif

        /// animado.

        /// </summary>

        private List<Image> GifImagesCollection { get; set; }

  

        private void btnProcess_Click(object sender, EventArgs e)

        {

            // Indicamos la posición inicial (Frame 1).

            this.Position = 0;

            // Inicializamos la colección de imágenes o frames de un Gif animado.

            this.GifImagesCollection = new List<Image>();

            // Recuperamos y cargamos en memoria la imagen animada.

            Image image = Image.FromFile(this.Path);

            // Obtenemos las dimensiones o frames de la imagen. 

            System.Drawing.Imaging.FrameDimension frameDimension = new System.Drawing.Imaging.FrameDimension(image.FrameDimensionsList[0]);

            int frames = image.GetFrameCount(frameDimension);

            // Recorremos los frames e insertamos en la colección cada una 

            // de las imágenes.

            for (int i = 0; i < frames; i++)

            {

                // Activamos el frame concreto.

                image.SelectActiveFrame(frameDimension, i);

                // Agregamos la imagen a la colección de imágenes.

                this.GifImagesCollection.Add(new Bitmap(image));

            }

            // Indicamos el número máximo de frames.

            this.MaximunPosition = frames;

            // Mostramos la primera imagen.

            ShowImage();

        } // btnProcess_Click

  

        private void btnBack_Click(object sender, EventArgs e)

        {

            // Cambiamos la posición de la imagen.

            this.Position -= 1;

            // Mostramos la imagen que le corresponde.

            ShowImage();

        } // btnBack_Click

  

        private void btnNext_Click(object sender, EventArgs e)

        {

            // Cambiamos la posición de la imagen.

            this.Position += 1;

            // Mostramos la imagen que le corresponde.

            ShowImage();

        } // btnNext_Click

  

        private void ShowImage()

        {

            // Cambiamos la imagen por la que le corresponde.

            this.pbImage.Image = this.GifImagesCollection[this.Position];

            // Habilitamos y deshabilitamos los controles para mostrar

            // la imagen siguiente o anterior.

            this.btnBack.Enabled = (this.Position == 0 ? false : true);

            this.btnNext.Enabled = (this.Position == this.MaximunPosition - 1 ? false : true);

        } // ShowImage

  

    } // MainForm

  

} // AnimatedGif

Referencias:

Gif (Graphics Interchange Format).

Gif, Png, problemáticas y soluciones.

Png (Portable Network Graphics).

Control marchoso.ocx para VB (no .NET).

Información sobre FrameDimension (System.Drawing.Imaging).

El uso de Contains en LINQ - IN or NOT IN en SQL

Jorge Serrano — Thu, 05 Nov 2009 07:00:00 GMT

Hay veces en las que desarrollando una aplicación Software, nos interesa obtener los elementos de una colección que contienen o que no contienen un conjunto de elementos.

Para ello, en LINQ hacemos uso de la extensión Contains.
De cara a SQL, esto sería similar a la instrucción que ejecutamos con la palabra IN.

SELECT * FROM Tabla WHERE campo NOT IN ('', '', ...)

La mejor forma de entender bien el funcionamiento de Contains, es verlo con un ejemplo.

El siguiente ejemplo es únicamente demostrativo y esta escrito en C#.

Comenzamos por crear una clase muy simple de productos frutales por decir algo:

public class Product
{
public string fruit { get; set; }
}

Y finaliza con el código de ejemplo demostrativo de LINQ y Contains:

string[] fruits = new string[] { "Peras", "Platanos" };
List<Product> productsCollection = new List<Product>();
productsCollection.Add(new Product() { fruit = "Naranjas" });
productsCollection.Add(new Product() { fruit = "Peras" });
productsCollection.Add(new Product() { fruit = "Limones" });
productsCollection.Add(new Product() { fruit = "Platanos" });
var productElements = from element in productsCollection
                      where !(fruits.Contains(element.fruit.ToString()))
                      select element;
productsCollection = productElements.ToList();
foreach (var item in productsCollection)
{
    MessageBox.Show(item.fruit);
}

Como podemos ver en este ejemplo, creamos una colección de frutas y una matriz con el nombre de dos frutas.
Lo que queremos obtener son todas las frutas que no estan contenidas en la matriz.
Es decir, todas las frutas que no son ni Peras ni Platanos.
En SQL estándar serían las frutas NOT IN ('Peras', 'Platanos').

Adicionalmente, también podemos hacer uso de las funciones Lambda, por lo que todo el funcionamiento anterior, se resumiría de la siguiente manera (equivalente de la anterior):

string[] fruits = new string[] { "Peras", "Platanos" };
List<Product> productsCollection = new List<Product> {
                                   new Product { fruit="Naranjas" },
                                   new Product { fruit="Peras" },
                                   new Product { fruit="Limones" },
                                   new Product { fruit="Platanos" }
                                   };
productsCollection = productsCollection.Where((n) => !(fruits.Contains(n.fruit.ToString()))).ToList();
foreach (var item in productsCollection)
{
    MessageBox.Show(item.fruit);
}

Espero que quede clara (para quien lo necesite) la funcionalidad, beneficios y usos de Contains en LINQ.

Cursos y documentación de referencia para eventos

Jorge Serrano — Wed, 07 Oct 2009 20:00:00 GMT

Me llega una información de Lisa Feigenbaum (Program Manager de Microsoft) de un repositorio de cursos, tutoriales, laboratorios, ejemplos en C# y VB.NET y videos sobre diferentes tecnologías de Microsoft, incluyendo Visual Studio y .NET Framework.

Este material puede ser utilizado en eventos, charlas o incluso code-camps, como por ejemplo el futuro Code-Camp de Tarragona 2009 del que espero que te hayas apuntado.

Las casi 40 presentaciones están en inglés y han sido recopiladas por diferentes personas, entre las que está Doug Turnure (del equipo de Marketing).

Espero que la información te resulte muy útil.

Referencias:

Acceso directo a los cursos y materiales.