Varios

Patrones de Comportamiento (II): Patrón Command


Objetivo:

“Encapsular una petición como un objeto, de modo que puedan parametrizarse otros objetos con distintas peticiones o colas de peticiones y proporcionar soporte para realizar operaciones que puedan deshacerse”.

Design Patterns: Elements of Reusable Object-Oriented Software

Cuando decimos que un patrón es “estructural” es sencillo imaginar que su cometido será modelar las clases de tal forma que cumplan un cometido concreto. Sin embargo, el concepto de diseñar clases orientando su funcionalidad hacia el comportamiento es algo más complicado. El patrón command u orden (como decía mi profesor de programación en primero de carrera, command se debería traducir por órden, no por comando, ya que un comando es un señor militar que pega tiros en la selva) tiene como objetivo encapsular la invocación de un método. Dicho así sin más, suena sencillo de entender pero… ¿cómo lo implementamos? La definición, a diferencia del patrón anterior, es un conglomerado de términos incomprensibles, ¿verdad? Encapsular una petición como un objeto. Vale, lo pillo. Pero ¿parametrizarse? ¿Soporte para realizar peticiones que puedan deshacerse?

(más…)

Anuncios

Patrones de Comportamiento (I): Patrón Iterator


Objetivo:

“Proporcionar una forma de acceder a los elementos de un objeto agregado de forma secuencial sin exponer sus detalles”.

Design Patterns: Elements of Reusable Object-Oriented Software

Pese a que no seamos conscientes de ello, cuando programamos utilizamos el patrón Iterator a diario. Casi todas las estructuras de datos que representan colecciones utilizan de algún modo este patrón para proporcionar acceso secuencial a los elementos que las conforman, y tanto Java como .NET ofrecen interfaces que nos invitan a implementar este patrón codificando su comportamiento.

Ojo al detalle: hemos dicho recorrer secuencialmente, esto es, hacer uso de un proceso que sea capaz de situarse en el primer elemento de una colección y obtener la información de ese contenido. Tras esto, dado que hemos dicho que se trata de una operación secuencial, deberemos ser capaces de pasar del elemento actual al elemento al siguiente, obteniendo también su contenido. Por último, será necesario implementar algún mecanismo que nos informe si hemos alcanzado el final de la colección para detener el proceso de iteración.

Por lo tanto, el patrón Iterator debe proporcionar la siguiente funcionalidad:

  • Obtener una referencia al elemento actual de la colección.
  • Obtener una referencia al siguiente elemento de la colección (el situado a continuación del elemento actual).
  • Obtener información sobre si existen más elementos después del actual.
  • Reiniciar la colección para que el iterador apunte nuevamente al primer elemento de la colección.

Seguramente podremos pensar que no tiene mucho sentido implementar nuestro propio patrón Iterator, ya que prácticamente todas las colecciones implementan todas estas operaciones (e incluso alguna más). Sin embargo, existirán muchos supuestos en los que nos será útil.

(más…)

Patrones Estructurales (VII): Patrón Proxy


Objetivo:

“Proporcionar un sustituto o intermediario para otro objeto de modo que pueda controlarse el acceso que se tiene hacia él”.

Design Patterns: Elements of Reusable Object-Oriented Software

Supongo que todos conocemos el concepto de proxy, al menos en su acepción aplicada a la navegación web. Se trata de una máquina que actúa de intermediaria a la hora de servir páginas web (u otros servicios). En la configuración de área local podemos indicar la IP de esta máquina y será esta máquina la que se conecte a la URL por nosotros y la envíe a nuestro equipo.

De este modo, un equipo no se conectará directamente a la URL, sino que lo hará a través de este intermediario. ¿Por qué hacer esto? Por múltiples motivos: podemos, por ejemplo, restringir las URLs que nuestros clientes (ordenadores de la red local) pueden visitar. O cachear las páginas que se visitan con más frecuencia, haciendo innecesario el acceso a la web “real” en los casos en los que el acceso se repita, proporcionando un ahorro en ancho de banda. En resumen, un proxy será una entidad en la que delegaremos la ejecución de ciertas tareas y que decidirá, en última instancia, qué acciones realizar antes y después de éstas. Los proxies, por tanto, podrían dedicarse perfectamente a la política 🙂

(más…)

Patrones Estructurales (VI): Patrón Composite


Objetivo:

“Componer objetos en árboles para representar jerarquías todo-parte. Composite permite a los clientes tratar objetos individuales y objetos compuestos de una manera uniforme”.

Design Patterns: Elements of Reusable Object-Oriented Software

El patrón Composite se aleja un poco de la línea tradicional de los patrones vistos hasta ahora, ya que rompe uno de los principios de la programación orientada a objetos: una clase, una responsabilidad. En realidad, los más puristas pueden decidir no hacerlo, pero el precio a pagar es demasiado alto para los ingenieros mortales: la simplicidad del modelo.

Cuando diseñamos debemos tener claro que la idea principal es alcanzar un equilibrio entre muchos factores como por ejemplo presupuesto, usabilidad y facilidad para que nuestro código sea reutilizable y pueda ser fácilmente mantenible en un futuro. Si el objetivo del anterior patrón, Flyweight, era el rendimiento, el sine qua non de este patrón es la facilidad de uso.

(más…)

Simular teclado y ratón en aplicaciones de terceros


English version here.

La simulación de una pulsación de una combinación de teclas o de una pulsación del ratón en una aplicación propia es relativamente sencillo: basta con hacer uso del método SendKeys para que nuestra aplicación reciba datos desde teclado y la invocación explícita del método adecuado que esté asociado al evento del ratón para simular un click del ratón.

Sin embargo, si deseamos crear un programa cuya misión consista en realizar estas operaciones en un programa de terceros, deberemos hacer uso de código no administrado.

Código administrado y no administrado.

El código administrado es aquel que se ejecuta bajo el control del CLR (Common Language Runtime), es decir, aquel código escrito en .NET que es compilado a un código intermedio MSIL o CIL (dependiendo de la versión del Framework) y que en tiempo de ejecución es transformado en código nativo. Este es el proceso natural de la programación .NET, con el que supongo que todos o casi todos estamos familiarizados.

El código no administrado, en cambio, es aquel código ajeno a este ciclo de vida, tal como el incluido en componentes COM/COM+, C++, ActiveX o la propia API de Windows (que es donde centraremos el objetivo de este artículo).

Windows expone su API a través de un conjunto de bibliotecas de enlace dinámico (dll) tales como user32.dll (permite manejar ventanas y sus eventos), shell32.dll (procesos), winspool.drv (impresión)… Para hacer uso del teclado y el ratón en aplicaciones de terceros nos centraremos en la biblioteca user32.dll, que como podemos imaginar, se tratará como código no administrado.

(más…)

Bases de datos portables (II): Combinando Entity Framework con SQLite


English version here.

En el artículo anterior vimos que es posible hacer uso de ADO.NET para crear una aplicación que utilice SQLite como base de datos. De este modo, con una base de datos local y ampliamente utilizada es posible aumentar radicalmente la portabilidad de nuestra aplicación si ésta no requiere la potencia de una base de datos “tradicional”. Sin embargo, la utilización de ADO.NET de forma directa implica dejar de lado todos los avances que Microsoft ha implementado a lo largo de estos últimos años en materia de mapeo objeto-relacional.

Ya que hemos aprendido a utilizar Entity Framework, ¿por qué no hacer uso de él con SQLite y dejarnos de “picar” código SQL de forma manual? A continuación veremos cómo podemos lograrlo.

(más…)

Entity Framework (VI): Webservices


Hasta ahora hemos visto el funcionamiento de LINQ y Entity Framework. La siguiente serie de artículos estarán orientados hacia los servicios web, por lo que haremos una pequeña introducción aplicando los conocimientos que hemos obtenido hasta el momento.

Lo primero que deberemos aclarar es el propio concepto de servicio web. Ya vimos en artículos anteriores de qué se tratan, cómo se crean y cómo se consumen estas pequeñas aplicaciones cuyo objetivo es el intercambio de información entre distintas plataformas y lenguajes de modo estándar.

Para crear un nuevo servicio web, crearemos un nuevo proyecto web de tipo ASP.NET Empty Web Application y le asociaremos un nuevo nombre. Los servicios web reciben ese nombre porque operan sobre el protocolo HTTP, así que este será nuestro punto de partida.

(más…)