Buenas prácticas

Patrones de diseño. Introducción

¿Qué es un patrón de software?

En software un patrón de diseño se refiere a una determinada forma de crear software, una forma de fabricarlo, por decirlo de alguna forma para crearlo de forma correcta.

En determinados marcos de trabajo, cuando nos enfrentamos a determinados problemas en el diseño de software hay formas determinadas de enfocalos que permiten adaptar mejor los posibles cambios de dichos problemas y las distintas evoluciones que pueda sufrir el software en un futuro.

Un buen dominio de los patrones más comunes nos puede servir para no tener que reinventar la rueda a cada paso que damos sino que podemos hacer uso de lo que otros pensaron por nosotros (y que descubriremos en multiples situaciones).

Patrones de diseño. Strategy

Introducción

El patrón strategy (estrategia) esta orientado a resolver situaciones en las que nos encontramos con un problema base pero existen diversas estrategias para abordar el problema. En este sentido nuestro problema define un interface que será (o podrá ser) implementado de diversas formas.

Problema

El patrón Strategy aborda problemas que pueden (o se prevee que puedan) ser implementados o afrontados de distintas formas y cuyo interfaz esta bien definido y es común para dichas formas, pudiendo ser cualquiera de ellas valida o más desable en determinadas situaciones y permitiendo el cambio entre las distintas estrategias en tiempo de ejecución.

Estructura

main.php?g2_view=core.DownloadItem&g2_itemId=825&g2_serialNumber=1

Check in early, check in offen

Acabo de leer el artículo Check in Early, Check in offen de Jeff Atwood acerca de la metodología de uso del control de versiones para el desarrollo de proyectos.

Aunque coincido con los artículos de Jeff en muchas ocasiones, esta es una de las situaciones en las que no lo hago.

En primer lugar, como por otro lado suele pasar con este tipo de artículos, las reflexiones que hace son demasiado genéricas y sobre caso demasiado simples como para poder extraer verdaderas conclusiones sobre ellos.

Hacer check in pronto y a menudo. Suena bonito, parece un concepto adecuado pero hay muchas cosas que quedan fuera del análisis, cosas que en un proyecto pequeño con dos o tres desarrolladores no tienen importancia pero que en grandes proyectos pueden dar verdaderos dolores de cabeza.

Uno de los ejemplos que cita es empezar con un código pequeño, que no haga nada y que tenga pocos, por tanto, pocos bug... de esta forma, según razona, podemos probarlo y subirlo al control de versiones. Entonces desarrollamos una nueva funcionalidad, la probamos y la subimos al control de versiones. Todo claro y sencillo...

Test Driven Development (Desarrollo dirigido por las pruebas)

Ultimamente, aquí y allá estoy oyendo hablar del llamado Test Driven Development o Desarrollo guiado por las pruebas como nueva metodología de desarrollo.

Dejadme que os explique un poco como funciona el asunto. La metodología se basa en que el desarrollo de los test guie el desarrollo de la aplicación, de esta forma lo primero que hacemos es planear que necesita hacer la aplicación y en función de ello desarrollamos test para cada una de las funciones, de esta forma disponemos de una prueba para cada función (no os entusiasmeis demasiado con esto ...)

El siguiente paso evidentemente es desarrollar la funcionalidad que consigue pasar ese test, y por tanto, funcionalidad hecha y medianamente probada... perfecto.

La descripción de la metodología tiene más pasos y más guías para el desarrollo y como realizar cada paso. La página de la wikipedia tiene más información para los interesados (que espero que después de leer este artículo sean pocos).

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.

Comentado de código y documentación.

Table of Contents [hide]

Comentando código

Realizar comentarios en el código es algo fundamental para la mantenibilidad de este cuando lo volvamos a coger más adelante.

Muchas veces, sobre todo en los proyectos esos que son "para anteayer" las prisas y la necesidad de tener la versión o el producto listo para una determinada fecha hacen que los comentarios de código sean escasos, malos o inexistentes.

Al contrario de lo que puedan decir por ahí no voy a decir, "comenta siempre aunque tengas que retrasarte"; nada más lejos de la realidad, acaba el proyecto, entregalo y consigue el dine

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.