Usa patrones de diseño

Es difícil clarificar el concepto de "patrón de diseño". Los patrones de diseño son básicamente construcciones de código que solucionan problemas comunes en el trabajo con y entre objetos. Para ello, utilizan generalmente el tipo Interface de los lenguajes de programación. La ventaja es que son aplicables a cualquier lenguaje que soporte las características de dicho tipo.

Los patrones de diseño resuelven aspectos como, entre otros:

• Forzar a que una clase tenga una única instancia global para la aplicación.
• Crear objetos de una clase u otra según el contexto.
• Clonar objetos.
• Adaptar los mensajes de salida de un objeto con los de entrada de otro, sin poder modificar el código de uno de ellos o ambos.
• Comunicar sucesos entre objetos sin conectarlos directamente.
• Iterar por todos los objetos de una clase.
• Permitir deshacer y rehacer acciones de un objeto.
• Delegar responsabilidades a otros objetos.
• Componer objetos en grupos.
• Sustituir dinámicamente el comportamiento de un método invocado.
• Cambiar la interfaz externa de un objeto no modificable.

        La experiencia en el uso de los patrones de diseño es la que nos dice en qué contexto deben ser utilizados: cuanto antes se conozcan y se dominen, mejor.

Un excelente y bien explicado libro de patrones de diseño puede encontrarse en la bibliografía ([FRE04]).

Empieza con lápiz y papel

Por más que hasta los últimos diez años se haya intentado constreñir el proceso de desarrollo de software dentro de patrones ordenados, a veces forzados, la programación es un proceso creativo. Hoy en día parece que se está imponiendo la noción de que los equipos de trabajo competentes no necesitan ceñirse a este tipo de modelos [PAL11]. Como parte de un proceso creativo, plasmar conceptos en un papel siempre será más rápido que el uso de un ordenador. Así, a pesar de tecnologías como e-Readers, procesadores de textos y aplicaciones para organizar la información, el modo más eficiente para desarrollar una idea suele pasar por usar papel y lápiz. Entre otras ventajas, el uso de esta alternativa más rudimentaria consigue clarificar aspectos, promover la adquisición de habilidades, y despertar la curiosidad y el interés por resolver nuevas situaciones [MAR99]. Por otro lado, es más barato y no hay que actualizarlo.

Esta acción es independiente y previa al uso de cualquier metodología de software, y el número de veces que tendremos que rehacer código durante la fase de construcción dependerá en gran medida de la claridad de su resultado. Aunque se espera que la actividad no ocupe mucho tiempo, se aconseja no iniciar el proyecto hasta que no pueda reproducirse mentalmente un primer nivel del diagrama de despliegue que sea realista y cumpla los objetivos, y ser capaz realizar un acercamiento en profundidad de cada componente como si de la pantalla de la película Minority Report se tratara. Apoyarse en técnicas ya conocidas de procesos de desarrollo software puede ayudar.

        Principalmente, es necesario poseer una idea clara de los siguientes elementos:

• Usuarios objetivos.
• Alternativas de tecnologías (lenguaje de programación, base de datos, y características de los equipos informáticos y redes de comunicaciones).
• Información a gestionar.
• Interfaces de usuario.

Además de eso, la filosofía de la empresa y las características del cliente deben tenerse en cuenta.

Con el tiempo se adquiere cierta habilidad para agilizar este proceso, si bien esto no evita que, una vez empezado el proyecto, haya que reestructurar algunos aspectos del planteamiento de "lápiz y papel", pero esta tendencia será cada vez más baja conforme se va alcanzando experiencia en el desarrollo de aplicaciones.

Una última advertencia: no podemos olvidar que el papel lo aguanta todo. Eso significa que las ideas no deben llegar directamente al cliente, so pena de que luego no sean realizables.