Articulos

Patrones de diseño. Template Method

Introducción

El patrón de diseño Template Method se utiliza en situaciones en las cuales existe un determinado esqueleto que conforma pasos comunes dentro de un algoritmo o procedimiento en una clase.

Una analogía podría ser la forma en que resolvemos un problema con distintos expertos, por ejemplo, supongamos el caso del ciclo de vida del software (simplificado), que podemos estructurar en los siguientes pasos:

  • Preparar un documento de concepto
  • Elaborar la especificación de requisitos
  • Elaborar el diseño de la aplicación
  • Codificar la solución
  • Realizar las pruebas unitarias
  • Realizar las pruebas de sistema

Ahora bien, el proceso es el mismo cada vez. El documento de concepto puede realizarlo comercial o marqueting, elaborarlo en Word o en PDF. El formato del documento de requisitos puede cambiar o usar un programa de apoyo como DOORS y el código puede realizarse utilizando Delphi, C# o Java, pero el proceso general permanece el mismo, solo cambian los expertos que se encargan de cada cosa.

Buffer overflow explicado

Sin duda muchos de vosotros habréis oído hablar de una vulnerabilidad basada en un buffer overflow pero no os ha llegado a quedar claro que significa exactamente esto.

En general, cuando aparecen dichas noticias suelen ir asociadas al término "ejecución de código arbitrario" que es, en realidad, el verdadero problema. Vamos a ver un poco más a fondo lo que significa una vulnerabilidad de buffer overflow y lo que implica.

En primer lugar, la palabra overflow procede del inglés y quiere decir desbordamiento (de hecho existe el término desbordamiento de buffer en español, pero como tantas otras cosas, es mucho más habitual escuchar el término inglés). ¿Que significa esto? Pues ni más ni menos que lo que indica su nombre, que tenemos un buffer cuya capacidad se ha visto desbordada.

En la mayoría de los lenguajes de programación un buffer hace referencia a un puntero a memoria reservada que tiene un determinado tamaño, si intentamos meter datos de más tamaño del del buffer, este se desborda.

Podríamos pensar que cuando esto pasa se produce una excepción y listo (y en algunos lenguajes esto es exactamente lo que pasa) sin embargo en la mayoría de los lenguajes no ocurre, con resultados generalmente desastrosos.

Introducción a Bases de Datos

Introducción

En estos tiempos, con las modernas aplicaciones informáticas que existen hoy en día, los programadores en ocasiones olvidamos que tanto los propios ordenadores como los programas que ejecutan sobre ellos no son más que procesadores de datos, procesadores rápidos, pero procesadores a fin de cuentas.

Los programas en realidad recojen datos del usuario, de archivos en el ordenador, de la entrada de los periféricos y los transforman para producir otros datos. Una aplicación como el photoshop por ejemplo recoje los datos almacenados en forma de bytes en un fichero y permite al usuario mediante la introducción de toda una serie de datos modificarlos para crear otra imagen distinta. La tarjeta gráfica transforma una serie de datos en forma de stream de bytes en secuencias de 24 bits que a su vez el monitor transforma en pixels en la pantalla.

Todo en informática está basado en los datos. Mucha gente, cuando oye hablar de base de datos automáticamente piensa en Microsoft Access o en Oracle o en cualquiera de los motores de bases de datos disponibles en el mercado. En realidad una base de datos es, como su nombre indica, cualquier almacen de datos, ni siquiera es en realidad necesario que dicho almacen sea informático, el termino podría valer para cualquier almacen de datos, como por ejemplo una biblioteca. Las bases de datos actuales, con su organización y sus características propias (SQL, indices, etc) responden a una necesidad creciente de acceder a los datos de la forma más rápida y estructurada posible.

Aplicaciones Multihilo en Delphi. Los problemas del multihilo

Introducción

En los dos artículos anteriores hemos visto una pequeña introducción a la programación multihilo en delphi así como a las funciones de sincronización que Delphi proprociona. Estas funciones de sincronización y el mero hecho de programar usando varios hilos tiene aparejados una serie de problemas a los que deberemos hacer frente si queremos que nuestra aplicación funcione correctamente y sin problemas.

Condición de carrera y exclusión mútua

Una condición de carrera es una situación indeseable en programación y que consiste en que el correcto funcionamiento del programa (o de un segmento del código del programa) depende del orden de ejecución de las tareas.

El problema principal de las condiciones de carrera es que son dificiles de identificar y encontrar y, dado que dos ejecuciones de un mismo programa pueden tener dos planificaciones completamente distintas para sus hilos, muy dificiles de reproducir.

Programación multihilo en Delphi. TThread y sincronización básica

Introducción

Si no lo has leido ya, y eres relativamente nuevo al mundo de la programación multihilo es recomendable empezar leyendo la Introducción a la programación multihilo para poder decidir correctamente si realmente es necesario implementar un sistema multihilo o no.

Definiendo nuestro hilo

Delphi facilita mucho la creación de hilos de ejecución proporcionando una clase base que podemos heredar para definir nuestras tareas de ejecución. Esta clase es la clase TThread.

Un ejemplo de una aplicación que usa una tarea para comprimir un archivo.

Introducción a la programación multihilo

Antes de empezar

En este articulo no hay ni una sola linea de código y no esta orientado a enseñar los entresijos especificos de la programación multihilo en este o aquel lenguaje sino a dar una pequeña introducción, centrandose fundamentalmente en el como y el sobre todo en el por qué y en el cuando.

¿Que es la programación multihilo?

En estos tiempos todos los sistemas operativos (excepto quizá los educacionales) son sistemas operativos multitarea, esto quiere decir que pueden ejecutar varias tareas o procesos simulataneamente. Esto no siempre fue así, el ms-dos era un sistema monotarea lo que quiere decir que tan solo una tarea podía ejecutarse en el sistema simultaneamente.

Antes de lanzarnos a explicar la programación multihilo es conveniente hacer un repaso a ciertas caraterísticas de los sitemas operativos.

Patrones de diseño. Memento Pattern.

Introducción

En muchas ocasiones deseamos guardar el estado de un objeto de forma que podamos recuperar dicho estado en cualquier momento. Un ejemplo muy simple es que vayamos a modificar una serie de parametros del objeto y hacer alguna operación pero deseemos almacenar en que estado estaba ese objeto para poder volver a él en caso de que se produzca una excepción.

En la mayoría de los objetos existe una parte de su estado que queda recogida en variables privadas. Al contrario de lo que se suela pensar una campo es privado no para evitar que alguien pueda modificarlo (que tangencialmente también) sino para indicar al programador que usa la clase que dicho campo no le interesa y no debe tenerlo en cuenta, utilizarlo ni depender en ningún sentido. Si cambiamos dichas variables de privadas a publicas, conseguimos que quien quiere guardar el estado pueda hacerlo leyendo y almacenando los campos pero violamos el concepto anterior.

El patrón memento enfrenta este problema encapsulando la información interna del objeto en una objeto, preferiblemente opaco al exterior.

Patrones de diseño. Facade Pattern

Introducción

El patrón Façade es un patrón de software cuyo objetivo se basa en simplificar o hacer más amigable la complejidad asociada a una librería software.

En ocasiones una librería o serie de librerias contienen una serie de funcionalidades para realizar diversas acciones. Si se analiza, en la gran mayoría de los proyectos de software, se observará que la mayor parte de las llamadas que recibe la librería es a las mismas funciones o a una combinación de ellas. Es decir, existe una gran cantidad de peticiones comunes que suelen ocurrir en el 90% de los casos y que satisfacen las necesidades del cliente de la librería. En estos casos, es convieniente crear un objeto que simplifica el API de la librería, unificando y simplicando ciertos procesos del API. Por supuesto algunos programas todavía querran (y podrán) acceder al viejo API de la librería para utilizar algunas funciones especializadas pero se habrá conseguido simplificar la funcionalidad más comunmente usada de la librería.

Patrones de diseño. Command Pattern

Introducción

El patrón Command (command pattern) es un patrón de diseño en el que los objetos representan acciones que serán consumidas por algún consumidor.

Problema

El patrón Command se utiliza para resolver diversos tipos de problemas en desarrollo de software:

  • Usado como simplificación de llamadas. En ocasiones el número de parámetros de una función crece hasta hacerse inmanejable. El uso del patrón command permite agrupar los parámetros en un solo objeto que se pasará a la función.
  • Usado como cola de comandos. Encapsular cada comando en un objeto permite su procesamiento de forma secuencial en forma de cola, de forma que un proceso trabajador pueda ir sacando los trabajos de dicha cola.
  • Operaciones con histórico. Usando objetos como comando y manteniendo esos comandos podemos mantener un histórico de los comandos utilizados y, en caso necesario, revertirlos.
  • Generalización de comandos. En ocasiones el uso de comandos permite la abstracción de dicho comando de forma que el comando constituye una clase abstracta de la que heredan los comandos específicos y que permite que un determinado objeto procese comandos ajustados a un determinado esquema independientemente de lo que haga dicho parámetro.

Patrones de diseño. Abstract Factory Pattern

Introducción

La idea detrás del patron Abstract Factory (que en español se traduciría como fabrica abstracta) consiste en la noción de que nuestro programa (o el cliente de una clase que nosotros proporcionamos) trabaja con una serie de productos (como los de una fábrica) que tienen unas determinadas características (por ejemplo tenemos productos embotellados y productos en tetrabrick). Nuestro programa va a utilizar dichos productos realizando una serie de acciones sobre ellos (como meter las botellas en unos camiones y los tetrabricks en otros) sin importarle quien le está suministrando los productos.

Así mismo existen una serie de fábricas que producen esos productos que vamos a tratar, una fábrica fabrica cocacola y otra pepsi pero ambas en botellas de las que nuestro programa trata. Al final, el concepto básico consiste en que a nuestro programa (o cliente) no le importa lo que haya dentro de la botella ni quien lo haya producido mientras sea una botella.

El punto de vista software

Desde el punto de vista software el ejemplo anterior se traduce en una situación en la que nuestro programa maneja un tipo de objetos con unas características comunes y algunas caracterísiticas propias. Esto en general en software se resuelve mediante el uso de dos características de los lenguajes de programación orientados a objetos, las clases+abstractas+y+los+interfaces.