jueves, 31 de mayo de 2007

EL CRISTO DE SAN JUAN DE LA CRUZ


Posiblemente el cuadro más famoso y difundido de Dalí. Fue hecho en 1951. Curiosamente la posición del Cristo no es idea original del pintor, se basó en un cuadro conservado en el Monasterio de la Encarnación de Avíla realizado por San Juan de la Cruz. Pertenece a su época mística-clásica que comenzó en los años 40 y que ha sido criticada por numerosos entendidos acusándola de comercial. Realmente son pinturas con un domino absoluto del dibujo, muy trabajadas y con composiciones espléndidas. Picasso comentó en esta época de Dalí "...el último pintor renacentista que le queda al mundo..", una opinión que comparto totalmente.


Definitivamente EXCELENTE!!.

El Patrón Singleton con C#

Uno de los patrones de diseño sin lugar a dudas más utilizado y conocido, es el patrón Singleton. De forma resumida, un singleton en una clase que únicamente permite que exista simultáneamente una única instancia de si misma y que ofrece un punto de acceso común a ella.
Este patrón nos puede ayudar en situaciones en las que queramos que haya únicamente una única instancia de una clase, por ejemplo para tener un acceso centralizado a un sistema de log o un sistema de caché, de forma que desde cualquier punto de la aplicación en el que queramos utilizar estos recursos, podamos garantizar que accedamos siempre a la misma instancia.
El código necesario para poder disponer de un singleton es realmente sencillo, son básicamente 2 líneas, que podremos ampliar con el comportamiento específico que queramos darle.


sealed class Singleton
{
private Singleton() {}
public static readonly Singleton Instance = new Singleton();
}


Para utilizar el código, podríamos usar desde cualquier punto Singleton.Instance y accederíamos siempre a la misma instancia.
Entrando un poco más al detalle del código utilizado, merece la pena explicar un par de cosas referentes a cómo se crea la instancia y cómo se evitan posibles problemas que podrían provocarse, sobretodo en entornos multihilo.
Lo primero de todo es destacar como el constructor de la clase está marcado como “private”, lo cual hace imposible crear instancias de la clase y nos obliga a acceder a la única posible instancia a través de la propiedad Instance. Con el mismo fin la clase está marcada como “sealed”, por lo que nos garantizamos de que nadie va a poder heredar de esta clase y crear múltiples instancias de nuestro singleton.
En cuanto a la instancia de la clase, está marcada como “public”, “readonly” y “static”, lo cual hace que se pueda acceder a ella desde cualquier otra parte, que no sea modificable y que se cree la primera vez que se acceda a ella, como veremos más adelante.
Hay un par de cuestiones típicas que suelen afectar a otras implementaciones de este patrón en otros lenguajes, una es la inicialización perezosa y la segunda los posibles problemas con el uso de múltiples hilos. La inicialización perezosa se refiere a la conveniencia por eficiencia, de no crear la instancia hasta el momento en que se acceda por primera vez a la instancia. En otros lenguajes esto se realiza mediante un “if” en un método “getInstance”, que comprueba si la instancia ha sido ya creada o no, de forma que se crea la primera vez que se llama al método. En situaciones multihilo esto puede provocar que varios hilos entre en el “if” a la vez, creando varias instancias. Para solventar este posible problema se suele utilizar una solución basada en un “Double-Check”, en la cual, lo primero que hace el método “getInstance” es comprobar si la instancia ha sido creada y en caso contrario entra en una “sección crítica”, en la cual se vuelve a realizar la comprobación y si sigue sin estar creada, se crea. De esta forma si dos hilos entran en el primer “if”, al llegar a la sección crítica sus accesos se serializarían, produciendo que el primero de ellos crease la instancia y al entrar el segundo, la comprobación de si existe la instancia fuera positiva. A continuación puede verse el código correspondiente a este funcionamiento en C#, aunque no es necesario utilizarlo, ya que el código mostrado anteriormente tiene la misma funcionalidad como veremos a continuación.

class Singleton
{
public static Singleton Instance()
{
if (_instance == null)
{
lock (typeof(Singleton))
{
if (_instance == null)
{
_instance = new Singleton();
}
}
}
return _instance;
}

protected Singleton() {}
private static volatile Singleton _instance = null;
}

miércoles, 30 de mayo de 2007

¿Qué es un puente (bridge) y cómo se debe utilizar?

El puente es el patrón más básico de todos y lo encontrará, en la medida que se familiarice más con los patrones, en general. Notará entonces, que el puente (en alguna forma) se encuentra en la cima de casi todos los otros patrones. Es por esto que se le conoce como la "madre" de los patrones de diseño.
¿Cómo puedo reconocer cuando necesito un puente?
La definición formal de un puente, tomada del Gof es:

"Desacoplar una abstracción de su implementación de tal forma que las dos puedan variar independientemente."

Espectacular, ¿eh? ¿Hacemos esto realmente en nuestro código? La respuesta corta es que probablemente nosotros lo hacemos más de lo que nos damos cuenta.

Vamos a tomar un ejemplo común en Visual Fox Pro.
Supongamos que nuestra aplicación necesita que le ingresen el nombre y apellido y que luego estos valores sean mostrados de alguna forma en otro lado.
Podríamos crear dos TextBox para ingresar estos datos y un EditBox para que estos sean mostrados.





Figura 1. Formulario


En el evento click del botón podríamos escribir el siguiente código:


ThisForm.txtMostrar.Value = ALLTRIM(thisform.txtApellido.Value) + ", " + ALLTRIM(thisform.txtNombre.Value)

Esto produce una salida donde el Apellido se muestra primero que el nombre y separados entre sí por una coma.
Ahora… si queremos reutilizar este código… IMPOSIBLE!.



¿Cuáles son los componentes de un puente?



Un puente tiene dos componentes esenciales, la "abstracción", que es el objeto responsable de inicializar una operación, y la "implementación", que es el objeto que la lleva a cabo. (Figura 2) La abstracción conoce su implementación porque guarda una referencia a la misma, o porque lo posee (por ejemplo, lo contiene). Observe que, a pesar de esta estructura, el diagrama denota que la abstracción crea la implementación, y que no es, en absoluto, un requerimiento del patrón. Un puente también puede hacer uso de una referencia ya existente para una misma implementación de objeto. De hecho, diseñar puentes de esta forma, puede ser muy eficiente porque diferentes objetos abstracción pueden ser utilizados en un mismo objeto implementación.








Figura 2. El patrón de puente básico

Debido a que Visual FoxPro tiene un modelo de contenedores muy bueno, la mayoría de los desarrolladores notarán que lo han utilizado (no intencionalmente) para implementar Puentes con más frecuencia de lo que imaginan. Sin embargo, no confunda el envío de mensajes con el puente. Si un método de un botón de comandos llama a un método en su formulario padre, esto implementa directamente la acción necesaria, que es enviar un mensaje, no un puente. Sin embargo, si el método del formulario va a llamar a otro objeto para que lleve a cabo la acción, entonces tenemos un puente.
Entonces, para implementar un puente necesita identificar qué objeto va a realizar la función de abstracción y cuál la implementación. Una vez que lo haya definido, todo lo que queda por decidir es cómo el puente entre los dos será codificado y esto dependerá enteramente del escenario.
¿Cómo implementar el puente en el caso anterior?

Para implementar el puente debemos separar la implementación de la abstracción. Para ello vamos a crear una clase de tipo Custom llamada puente dentro de alguna biblioteca de clases, para este caso será “ejemplos”. A la clase puente le vamos a anexar un método llamado “procesarNombre”. Este método recibirá como parámetros dos string y devolverá otro string. Quedaría algo como lo siguiente:

LPARAMETERS nombre,apellido
RETURN ALLTRIM(Apellido) + ", " + ALLTRIM(nombre)

Ahora bien, desde el formulario vamos a escribir el siguiente código:

MiPuente = CREATEOBJECT("Ejemplos.puente")
ThisForm.txtMostrar.Value=MiPuente.procesarnombres(thisform.txtNombre.Value,thisform.txtApellido.Value)

Como se puede observar la manera de cómo se procesan los nombres no le importan a mi aplicación. De hecho se puede cambiar la manera de procesar los nombres sin tocar nada de código en el formulario. Lo único que hay que respetar es la interfaz, que en este caso es el método procesarnombres().

Esta estrategia desacopla exitosamente la abstracción de la implementación y, como resultado, nuestro código, es mucho más reutilizable.

¿Qué son los Patrones de Diseño?

Antes de comenzar a bucear en ejemplos específicos de cómo implementar patrones de diseños específicos en Visual FoxPro y C#, debemos comenzar por definir qué entendemos por "Patrones de Diseño". Se han propuesto varias definiciones y quizás la más reconocida es la que aparece en el trabajo "Design Patterns, Elements of Reusable Object-Oriented Software" (Patrones de Diseño, elementos de reutilización de aplicaciones orientadas a objetos) escrito por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (comúnmente conocidos por la pandilla de los cuatro o simplemente como "GoF"). Ellos ofrecen en el primer capítulo de su libro "What is a Design Pattern" (¿Qué es el diseño de patrones?) la siguiente definición:

"Un diseño de patrones nombra, abstrae e identifica los aspectos claves de una estructura de diseño común que lo hace útil para la creación de un diseño orientado a objetos reutilizable. El diseño de patrones identifica la participación de clases e instancias, sus roles y colaboraciones, y la distribución de responsabilidades."

Esta es una buena definición, porque encapsula los cuatro elementos de cualquier diseño de patrones.

Primero, que tiene un nombre. Es vital, porque permite a los desarrolladores superar uno de los problemas fundamentales del diseño de aplicaciones – ¿Cómo comunicar lo que haces a otros?

Segundo, abstrae el problema. Esto es referido por "GoF" como el "objetivo". Nos dice la naturaleza del problema y la solución descrita por el patrón.

Tercero, define un diseño de estructura. Es importante darse cuenta que el diseño de patrones no proporciona soluciones. Describe estructuras que permiten solucionar un problema de manera que resulte más fácil de reutilizar que si se escribe simplemente el código para solucionar el problema en el contexto en el que surge.

Cuarto, que identifica la distribución de responsabilidades. Esto es, por supuesto, la clave a todos los tópicos de diseño y no está limitado al diseño de patrones. Después de todo, una vez conocido lo que tiene que hacer una clase (u objeto), escribir el código para hacerlo es relativamente fácil.

La ventaja del diseño de patrones es que una vez que haya reconocido el problema y lo haga corresponder con un patrón, el patrón nos dirá cómo debemos asignar las responsabilidades y por consiguiente nos ayudará a crear rápidamente una solución.

Podes ver un poco más de este tema en el Artículo de patrones de WikiPedia.

Bienvenidos!!!

¡Hola a todos!

El día de hoy comienza una serie de publicaciones que haré acerca de mis distintas áreas de interés.
Las mismas comprenderán la Informática, La literatura y en alguna medida seguramente las artes plásticas.
Como ya estarán viendo a nivel profesional soy Ing. de Sistemas y es por ello que esta temática no puede faltar en mi blog.
Por otro lado soy, también, escritor aficionado. Estoy en el proceso de escritura de mi segundo libro. El primero, Desensasiones (un neologismo mio), no lo he intentado publicar aún. Seguramente verán partes de él aquí.
Las artes plásticas han sido parte de mi vida durante mi adolescencia. He concurrido a escuelas de arte y el tema siempre me ha gustado. No me considero un artista plástico, todo lo contrario, en realidad no tengo talento. Mi idea es ingresar temáticas de arte al blog para que el mismo no sea una roca sin forma y espíritu. Darle alma al sitio.
Espero que les sea útil y entretenido.