Busca monografías, tesis y trabajos de investigación

Buscar en Internet 

       Revistas   Cursos   Biografías

rss feeds RSS / /

Colecciones y el patrón de diseño Observador en C#

Resumen: Para tener una visión actualizada de los datos las aplicaciones de gestión, la gran mayoría de las veces, implementan esperas activas, lo cual puede bajar el rendimiento del sistema. Una solución mejor es implementar el patrón de diseño Observer sobre las colecciones de datos. A través del uso de tipos delegados en C# puede ser resuelto el problema en memoria RAM.

Publicación enviada por Maykell Sánchez Romero




 



RESUMEN
Para tener una visión actualizada de los datos las aplicaciones de gestión, la gran mayoría de las veces, implementan esperas activas, lo cual puede bajar el rendimiento del sistema. Una solución mejor es implementar el patrón de diseño Observer sobre las colecciones de datos. A través del uso de tipos delegados en C# puede ser resuelto el problema en memoria RAM. 

Palabras claves: colecciones, observador, patrón de diseño


Collections and Observer design pattern in C#

ABSTRACT
Software implement active delays a lot of times trying to get updated vision of the information, and those active delays can slow down the software’s yield. A better solution is implementing the Observer design pattern over collections of data. This problem has a solution for RAM collections using delegates in C#.

Keywords: collections, observer, design pattern

INTRODUCCIÓN
Normalmente las aplicaciones de gestión tratan un conjunto considerable de datos. Tener una visión actualizada en todo momento de los mismos es una característica importante, que cobra mayor relevancia cuando desde diferentes instancias o módulos de una misma aplicación los datos pueden ser modificados.
El esquema tradicional de solución a este problema es hacer que la aplicación periódicamente se actualice realizando pedidos a la fuente de datos, que puede ser una colección en memoria RAM o en disco duro. Estos pedidos periódicos, o esperas activas como también se les conoce, pueden bajar el rendimiento del sistema sobre todo cuando no son necesarios debido a que no se han realizado cambios en la fuente de datos. 

Una solución es establecer políticas de actualización que tengan en cuenta las exigencias propias de la aplicación. 

Otra, más general, podría obtenerse si se contara con algún mecanismo del lado de la fuente de datos, de manera que más que meros repositorios de datos sean entes activos en la solución informática, avisando a las aplicaciones clientes sobre actualizaciones realizadas. 

Solución utilizando el patrón de diseño Observador
El patrón de diseño Observador ha sido utilizado ampliamente en problemas donde es necesario tener una vista actualizada de los datos. Básicamente el patrón define una relación de dependencia de uno a muchos (figura 1), de forma que cuando el sujeto cambia su estado lo notifica a los objetos observadores dependientes [1][2]. 

Observando la definición de componente propuesta por Bertran Meyer [3]:”un elemento de software reusable, típicamente en bibliotecas de clases, usualmente en forma de código fuente” se puede concluir que el patrón Observador es completamente componentizable [4]. 

Figura 2. Implementación tradicional del patrón Observador.

Tradicionalmente la forma en que se ha componentizado el patrón Observador es proveyendo dos interfaces. La primera, IObservador, define un método que el observador desea ejecutar una vez que se ha hecho algún cambio en el sujeto observado. La segunda, ISujeto, define métodos mediante los cuales inscribe y desinscribe observadores (IObservador). El objeto de tipo sujeto es responsable de realizar un llamado a todos los observadores una vez que se haya hecho un cambio de interés (figura 2).

En el lenguaje de programación C# la componentización se ve enriquecida con los tipos delegados. Un delegado es un tipo que puede almacenar referencias a métodos, brindando más seguridad que sus homólogos punteros a métodos del lenguaje C++ [Seco2001].

Como parte de las bibliotecas de clases del lenguaje C# se incluyen implementaciones genéricas de tipos abstractos de datos clásicos como las listas (List<T>, LinkedList<T>), la pila (Stack<T>) y la cola (Queue<T>). Todas ellas implementan la interfaz ICollection<T>, que provee un conjunto de funcionalidades básicas a implementar sobre una colección de elementos. Haciendo uso de los delegados y eventos podemos implementar una interfaz INotifierCollection<T> para la notificación de cambios en la colección. Esta interfaz hereda de ICollection<T> e incorpora eventos para subscribir la ejecución de una acción al cambiar el estado de la colección. De los métodos de ICollection<T> los que pueden cambiar el estado de la colección son Add(T item), Clear() y Remove(T item). Por cada uno de ellos se puede crear un delegado y declarar un evento en la interfaz (figura 3). Los eventos llevan una implementación explícita en cada clase que herede de la interfaz.

Figura 3. Implementación el patrón Observador utilizando tipos delegados y eventos.

Para evitar la necesaria implementación de los eventos sobre cada clase que herede de la interfaz, se puede proveer una clase abstracta NotifierCollection<T> que herede de INotifierCollection<T> e implemente los eventos. De esta forma podemos establecer nuestras propias colecciones de elementos que notifiquen sobre cambios realizados al ser llamado algún método que modifique la colección. Los observadores de estas colecciones(sujetos) se suscribirían notificando qué método debe ser ejecutado al ocurrir el evento seleccionado. 

Esta solución es fácil de implementar y similar al mecanismo de suscripción a eventos de las diferentes componentes visuales de las aplicaciones de escritorio que implementan las diferentes plataformas (figura 3). 

CONCLUSIONES
El patrón observador, aplicado a colecciones de objetos, mejora el rendimiento de las aplicaciones pues les permite actualizar sus datos cuando son avisadas por la propia fuente de datos, evitando realizar esperas activas, que son innecesarias cuando se realizan cambios sobre la fuente de datos. En C# se puede implementar una solución elegante utilizando delegados y eventos.

El problema se podría extender a colecciones de elementos en disco duro, accedidos a través de un gestor de bases de datos. Una solución al mismo mejoraría mucho el rendimiento de estas aplicaciones, algo deseable sobre todo cuando el gestor es accedido por varias aplicaciones y/o almacena un número considerable de datos.

REFERENCIAS
[1]. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
[2]. James W. Cooper: Introduction to design patterns in C#. IBM T J Watson Research Center, 2002. 
[3]. Bertrand Meyer: Object-Oriented Software Construction, second edition. Prentice Hall, 1997.
[4]. Karine Arnout: From Patterns to Components, Doctoral Thesis ETH No. 1550, SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH, 2006.
[5]. José Antonio González Seco: El lenguaje de programación C#. http://www.josanguapo.com/.

AUTOR:
Lic. Maykell Sánchez Romero(1)
 maykell@uci.cu

(1)Universidad de las Ciencias Informática, Facultad 7, 
Departamento de Ciencias de la Especialidad
Licenciado en Ciencias de la Computación en la Universidad de La Habana, es Profesor Instructor y labora en la Universidad de las Ciencias Informáticas, Cuba. 
Actualmente imparte temas docentes relacionados con la Programación Orientada a Objetos, Estructuras de Datos y Algoritmos, Técnicas de Compilación. Tiene tareas de investigación y producción al frente de equipos desarrollo de Sistemas de Información Hospitalarios.



Valora este artículo 5   4   3   2   1

Comparte  Enviar a facebook Facebook   Enviar a menéame Menéame   Digg   Añadir a del.icio.us Delicious   Enviar a Technorati Technorati   Enviar a Twitter Twitter
Artículos Destacados