Miguel Matas Blog

Ingeniería y Arquitectura de Software, Proyectos IT, Programación, Personas, Problemas, Mejora Continua, la vida.

Archive for the 'Patrones' Category

Clases estáticas o singleton

Hola,

Recupero un artí­culo ya de hace unos años, pero que da respuesta aíºn a dí­a de hoy estupendamente al respecto de qué aporta el uso del patrón singleton respecto al uso de clases estáticas.

http://geeks.ms/blogs/gelexgaray/archiven/2007/02/01/clase-singleton-vs-est_E100_tica.aspx

Un saludo.

Miguel.

No comments

Patrones de Ajax: El Refresco Periódico

En la sección de patrones de diseño inauguramos los patrones de Ajax, con la descripción del patrón: Refresco Periódico.

El patrón viene a describir la solución a un problema comíºn y que parte de una de las principales limitaciones de la soluciones web, la uni-direccionalidad de la relación cliente-servidor. La parte cliente es la que siempre toma la iniciativa ante cualquier transacción, por lo que si en las situaciones en las que queremos mostrar un aviso de cuándo un proceso de cálculo complejo que se ha lanzado de forma así­ncrona ha terminado, o cuando por ejemplo a los usuarios autenticados en nuestra aplicación queremos mostrarles un aviso de que se ha recibido stock de un determinado producto, no tenemos más remedio que utilizar diferente estrategias, siempre por parte del cliente, para “engañar al usuario”.

Una de las soluciones a este tí­pico problema es el uso del Patrón del Refresco Periódico, que a grandes rasgos consiste en realizar llamadas periódicas a través de ajax al servidor, para ir solicitando el refresco del estado de la información que necesitamos consultar. Como al utilizar ajax la página no se refresca de forma completa, la experiencia de usuario da como resultado algo bastante similar a lo que puede aportar una aplicación de escritorio.

Más información en http://ajaxpatterns.org/Periodic_Refresh

Saludos.

Miguel.

No comments

El Patrón de Diseño del Botón Derecho

Este patrón de diseño sobrepasa lo técnico, incluso lo funcional, quedándose en el ámbito representado por una persona con conocimiento funcional, que en su dí­a tuvo algíºn conocimiento técnico y que ahora mismo se dedica a la acción comercial.

También lo aplican otros perfiles, muchos veces en el ámbito de la consultorí­a, que para preparar sus documentos funcionales y las estimaciones no tienen en cuenta u obvian los conocimientos técnicos necesarios para hacer valoraciones realistas.

Es muy sencillo de aplicar, ante cualquier problema, el sujeto aplicará el patrón de formas similares a esta:

Requerimiento funcional 1

Una vez la información asociada al cálculo infinitesimal necesario para calcular una parábola alrededor del universo conocido haya sido introducida en el modelo de datos de la aplicación actual, podrá ser exportada en el formato xml definido por la corporación e integrado en el módulo de sap activo.

Aplicación del Patrón

No hay problema, será tan sencillo como seleccionar el cálculo, botón derecho, y hacer click en “migrar”, estará listo en dos jornadas.

Requerimiento Funcional 2

El diagrama almacenado en un archivo de imagen jpg, y que muestra la información de un gráfico de barras que representa los beneficios de los anteriores 10 años de actividad de la empresa, será transformado y la información mostrada en imagen pasará a formar parte del modelo de datos de la nueva aplicación de la empresa.

Aplicación del Patrón

No hay problema, seguro que extraer la información del jpg es muy sencillo, será tan sencillo como seleccionar el fichero de la imagen, pulsar botón derecho y hacer click en “transformar imagen”.

ínimo a todos los que disfrutais construyendo cosas!

Saludos.

2 comments

Singletonitis

“Dí­cese del abuso del Patrón de Diseño Singleton en una aplicación”.

Catalogado como Antipatrón de diseño en Wikipedia.org

Lo que no veo explicado por ningíºn lado cuándo se puede considerar que se está abusando…

Saludos.

Miguel.

2 comments

Patrón de Diseño: Memento

Me hace mucha gracia el nombre de este Patrón de Diseño, “Memento”, inavitablemente me recuerda siempre a la pelí­cula.

Memento nos ayuda por ejemplo a resolver la tí­pica problemática de máquina de estados, donde necesitamos almacenar cuáles han sido los diferentes estados que ha tenido un objeto a lo largo de un tiempo determinado.

Un ejemplo muy cercano a todos nosotros es el uso del “Undo / Deshacer” (CTRL+Z) del que disponen la mayorí­a de procesadores de texto, entornos de desarrollo… y que nos permite en un momento dado poder deshacer todos los íºltimos pasos que hemos llevado a cabo. Para hacer esto alguien se habrá tenido que acordar de lo que habí­amos hecho antes, y ese alguien es el Patrón Memento.

Os dejo link a la wikipedia

http://es.wikipedia.org/wiki/Memento_(patr%C3%B3n_de_dise%C3%B1o)

Y un link a un PDF donde tenéis una descripción más ampliada, además de un ejemplo de codificación en Java.

http://www.freewebz.com/amanecer/personal/papers/paper.memento.pdf

Un saludo.

Miguel.

No comments

FilterDTO, minimizando los métodos de nuestros DAO

Uno de los problemas que nos podemos encontrar a la hora de ir añadiendo métodos a nuestros DAO es que el níºmero de métodos que realizan consultas se dispare.

Por ejemplo, podemos tener un CocheDAO que permita operaciones de inserción, actualización y borrado, y además una serie de métodos que nos permitan hacer consultas sobre el mismo. Los métodos serí­an algo del estilo de:

GetCochesByMarca
GetCocheByMatricula
GetCochesByMarcaAndKilometraje
GetCochesByPais

La lista, interminable, íºnicamente limitada por la capacidad del cliente de pedir información.

Esto al final se vuelve un poco locura, el níºmero de métodos y el trabajo que lleva realizar cada uno de ellos se puede elevar hasta el infinito. ¿Existe solución?

Parece que sí­, si no, no estarí­amos aquí­ 🙂

Una solución al respecto es la de disponer de un íºnico método que sea capaz de devolver resultados para cualquier consulta planteada, pero, ¿cómo conseguirlo?

Ejemplo:

public CocheFilterDTO GetCochesByFilter(CocheFilterDTO filtro)
{
}

Este va a ser el método mágico que devolverá cualquier tipo de petición. El truco está en el parámetro que recibe, que en lugar de ser un DTO comíºn es un FilterDTO. La propiedad principal que definimos en un FilterDTO es la de que todas las propiedades que la componen son propiedades nullables (hemos hablado ya de nullables en otro post anterior). Es decir, podemos establecer con el valor null cualquiera de las propiedades definidas en el mismo.

La idea feliz se basa en que sólo vamos a filtrar por los valores del FilterDTO que no vengan a null. Por lo que si tengo en el FilterDTO una propiedad por cada uno de los elementos de filtro, voy a poder filtrar por todas y cada una de las combinaciones posibles. Sólo tengo que dar un valor a la propiedad y el método se encargará de filtrar. Si el valor está a null el método obviará el filtro por esa propiedad.

¿Cómo hacer esto? Muy sencillo, la condición SELECT que se llevará a cabo trabajará de la siguiente manera:

SELECT COCHE_CODIGO, COCHE_MATRICULA, MARCA_CODIGO, COCHE_KILOMETROS
FROM COCHE
WHERE (COCHE_CODIGO  = @CodigoCoche OR @CodigoCoche IS NULL) AND
                (COCHE_MATRICULA = @Matricula OR @Matricula IS NULL) AND
                (MARCA_CODIGO = @Marca OR @Marca IS NULL) …

Teniendo en cuenta que todo lo que empiezan por @ son los valores que vienen en el FilterDTO… ya tenemos la solución al problema. Si el valor viene en el parámetro se filtrará por él, si no viene se compará con NULL y dará true, por lo que será como si no se haya filtrado por esa caracterí­stica.

Entonces el chiste se resume en proveer al FilterDTO de todos los elementos que pueden venir o no rellenados y de definir la SELECT que trabaje con el mismo.

Idea feliz 🙂

Saludos.

Miguel.

2 comments

Antipatrones de Diseño

Por favor, echadle un ojo a la entrada de Wikipedia al respecto de los antipatrones de diseño, hay una recopilación estupenda de muchos de ellos.

La verdad, es graciosí­simo ver el montón que hemos visto implementar, o que incluso nosotros mismos hemos estado implementando estos íºltimos dí­as 🙂

http://es.wikipedia.org/wiki/Antipatr%C3%B3n_de_dise%C3%B1o

Saludos.

Miguel.

1 comment

ASP.NET MVC Framework. Aplicando un MVC real con Visual Studio 2008.

En el anterior post vimos un artí­culo donde se mostraba cómo trabajar con MVC + ASP.NET en Visual Studio 2005.

Para los que habéis aplicado MVC en J2EE o en Ruby on Rails os parecerá una aplicación pobre del MVC, pero bueno era lo que tení­amos en su momento para ASP.NET, y los que querí­amos acercarnos a ese modelo no nos quedaba más remedio que aproximarnos lo más posible a él con las herramientas con las que contábamos.

Ahora, con Visual Studio 2008 la cosa ha cambiado, y tenemos un tipo de proyecto que explota explí­citamente el patrón MVC en ASP.NET.

He encontrado un artí­culo estupendo que habla de ello del cual os dejo el link más abajo, y que además da la puntilla dando unos toques de LINQ.

Por cierto, atención con el modelo de convenciones que utiliza el nuevo MVC para ASP.NET, para los que conozcáis Ruby on Rails os va a resultar ciertamente familiar. Es curioso como las buenas ideas se extienden como la pólvora por las diferentes herramientas de desarrollo.

Os dejo el link:

http://thinkingindotnet.wordpress.com/2007/11/18/aspnet-mvc-framework-primera-parte/

Un saludo.

Miguel.

No comments

MVC y Aplicaciones N-Capas con ASP.NET y Visual Studio 2005

Para los defensores de que el patrón MVC es algo que viene de Java y que ASP.NET no está preparado para llevarlo a cabo, por favor, consulten el siguiente enlace en el que se muestra un ejemplo muy muy sencillo de implementación del patrón

http://msdn2.microsoft.com/en-us/library/ms998540.aspx

Para los interesados en ver un ejemplo magistral de implementación de una aplicación ASP.NET en N-CAPAS, os recomiendo consultar el siguiente enlace

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416

Un saludo a todos y feliz año.

Miguel.

1 comment

Acercándonos al patrón Faí§ade, veamos el patrón Factory

Unos post más atrás (si no recuerdo mal hablando de .NET Remoting) surgió en la conversación el patrón Faí§ade. Es más,incluso se adjuntó un diagrama de arquitectura donde veí­amos implementado el patrón dando vida a la convivencia de servicios web y servicios de remoting en la misma arquitectura.

En su dí­a prometí­ dedicar un post al patrón Faí§ade, pero como este implementa otro patrón llamado Factory, creo que mejor antes vamos a por el Factory para luego atacar Faí§ade con un poco más de base.

El patrón Factory entra en el grupo de patrones de creación (donde también podemos encontrar Singleton del cual ya hemos hablado también en otros post). Los patrones de creación, tal como su nombre indica, se dedica a crear objetos y a encapsular dicha creación para abstraernos de la misma (lo de siempre quitar trabajo, elevar la productividad y la mantenibilidad).

Os dejo aquí­ un PDF interesante al respecto de los patrones de creación por si os interesa el tema a fondo, vienen bastantes ejemplos.

http://www.dei.inf.uc3m.es/docencia/p_s_ciclo/tdp/curso0203/apuntes/factory.pdf

De todas maneras, lo de siempre, yo os voy a dejar una muestra muy pequeña que os sirva de punto de partida y ya luego si os interesa a fondo os metéis a saco teniendo la base ya firme.

Antes de empezar, contaros que hay tres tipos de patrones Factory: Simple Factory, Factory Method y Abstract Factory y aquí­ en principio sólo vamos a hablar de Simple Factory ya que es el patrón que usa Faí§ade, que es a lo que queremos llegar.

Aprovecho y hago un inciso, es importante en esta profesión centrarse en el problema y no irse por las ramas, si sabéis que algo soluciona vuestro problema, a por ello, no os pongáis a mirar y mirar y mirar, porque el tiempo se os va a ir y la fecha de entrega de un proyecto suele ser fija 🙂 Fin del inciso.

Factorí­a Simple + Strategy (mira tíº por donde nos aparece otro patrón)

Allí­ va un ejemplo, a ver si quedan las cosas claras.

Primero una interfaz Vehí­culo (código C#):

public interface Vehiculo
{
 public void Arrancar();
 public void Frenar();
 public void GirarIzquierda();
 public void GirarDerecha();
}

Como véis la interfaz vehí­culo lo que hace es definir una serie de comportamientos comunes a cualquier vehí­culo.

Ahora implementemos dos vehí­culos.

public class Coche : Vehiculo
{
 public void Arrancar()
 {
  // Código necesario para arrancar el coche.
 }

 … Resto de métodos de Vehí­culo …
}

public class Moto : Vehiculo
{
 public void Arrancar()
 {
  // Código necesario para arrancar la moto
  // que no es igual al del coche claro
 }

 … Resto de métodos de Vehí­culo …
}

Como véis lo íºnico que hemos hecho aquí­ es implementar los métodos de un vehí­culo para un coche y una moto. Hemos definido cómo actíºan cada uno por separado. Hemos encapsulado dicho comportamiento en las clases que heredan de vehí­culo.

Y ahora ya “la magia”, la factorí­a que genera vehí­culos:

public class FactoriaVehiculo
{
 public static Vehiculo GetVehiculo (TipoEnumeradoVehiculo vehiculo)
 {
  switch (TipoEnumeradoVehiculo)
  {
   case vehiculo.Coche:
    return new Coche();
    break;
   case vehiculo.Moto:
    return new Moto();
    break;
   default:
    return null;
    break;
  }
 }
}

Hemos utilizado un Tipo Enumerado auxiliar para hacer esto más legible y sobre todo más encapsulado. Otra opción era pasarle a GetVehí­culo un String… pero claro, estamos en lo de siempre, si le pasamos un string estamos dando por hecho que sabemos que hace por dentro la factorí­a, cuando no tiene por qué ser así­.

Bien, por íºltimo, vamos a crear un procedimiento que utilice la factorí­a, para así­ acabar de darle forma al asunto:

public void EjemploFactoria()
{
 // lista genérica, SIEMPRE QUE SEA POSIBLE
 List<Vehiculo> listaVehiculos = new List<Vehiculo>;
 
 // añadimos vehí­culos a la lista genérica
 listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.Coche));
 listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.Moto));
 listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.MotoConSidecar));
 listaVehiculos.add(FactoriaVehiculo.GetVehiculo((TipoEnumeradoVehiculo.TodoTerreno));

 // recorremos la lista de vehí­culos
 foreach (Vehiculo unVehiculo in listaVehiculos)
 {
  unVehiculo.Arrancar();
 }

}

¿Queda claro? La factorí­a ha ocultado cómo se crean las clases y las ha devuelto ya generadas. Por cierto, hemos hablado antes del patrón Strategy… ¿pero dónde aparece? Pues lo vemos en funcionamiento en la lí­nea unVehiculo.Arrancar(). Cada vehí­culo arrancará como tenga definido, esa es su estrategia. Strategy es un patrón muy simple y que seguramente habréis implementado muchas veces pero sin haberlo llamado nunca así­ 🙂 Os dejo el link de la wikipedia al respecto aquí­ para que le echéis un ojo.

Por cierto, menudo ejemplo de polimorfismo nos ha salido también, ¿no? Ahora que caigo, ¿podrí­amos definir el polimorfismo como sinónimo de patrón strategy? Tengo que investigarlo.

Más cosas también para terminar, en otros posts también se habló de crear factorí­as de DAO’s, ¿se ve ahora un poco mejor el tema?

¡Saludos a todos y feliz navidad!

Miguel.

9 comments

Next Page »