Patrones de diseño (I)

Un patrón de diseño propone una solución a un problema recurrente de diseño de software. La solución es reutilizable y vale para resolver problemas similares.

En esta serie de artículos vamos a centrarnos en los patrones de diseño enfocados a la programación de vídeo juegos.

Algo de historia.

Como siempre es mejor empezar por el principio. Los patrones de diseño surgen del mundo de la arquitectura cuando en 1979 el arquitecto y matemático, Christopher Alexander publica el libro ‘The Timeless Way of Building‘. En palabras del autor:

 

Cada patrón describe un problema que ocurre infinidad de veces en nuestro entorno, así como la solución al mismo, de tal modo que podemos utilizar esta solución un millón de veces más adelante sin tener que volver a pensarla otra vez.

 

 

Inspirado en las antiguas ciudades medievales publica junto a otros colegas su siguiente libro ‘A Pattern Language‘, donde formaliza la idea de patrón de diseño como una solución a un problema dentro de un contexto dado.

En él se describen métodos para crear diseños prácticos, seguros y atractivos sin importar la escala a la que se trabaje.

Todavía en muchas ciudades se siguen usando sus principios como código de construcción.

 

El salto al mundo de la programación ocurrió en 1987 cuando Ward Cunningham y Kent Beck encontraron paralelismos en la obra de Alexander y lo que debería ser una buena arquitectura basada en orientación a objectos. Desarrollaron cinco patrones y publicaron un artículo en la conferencia OOPSLA en ese mismo año bajo el nombre ‘Using Pattern Languages for OO Programs‘.

Pero no fue hasta 1994 con la publicación del famoso ‘Design Patterns: Elements of Reusable Object-Oriented Software‘ por parte del grupo denominado ‘Gang of Four‘ (o simplemente ‘GoF‘) cuando se popularizó el termino y su uso. Se vendieron más de 500000 copias en ingles y se tradujo a otros 13 idiomas.

En el libro los autores sientan las bases de lo que hoy en día entendemos como un patrón de diseño y recopilan los 23 primeros patrones. Desde entonces su número no ha dejado de crecer.

 

¿Por qué usarlos?

Porque nos pueden ayudar a crear software robusto, fácil de entender y de manipular. Además puede facilitarte un vocabulario común para planificar o resolver problemas con otros programadores.

Imaginemos que quieres hacer juguetes con piezas de plástico. Podrías hacer un molde para cada juguete nuevo que necesites, pero estos juguetes no se podrían modificar fácilmente y no aprovecharías nada de los antiguos moldes.

En vez de construir moldes de juguetes completos, podríamos hacer moldes de piezas más pequeñas y construir los juguetes con estos bloques. Además de poder reutilizarlos para otros juguetes, los propietarios podrían modificaros y utilizar bloques de otros juguetes para construirse los suyos propios.

Pese a que muchos bloques serían los mismos (como los de arriba), juguetes construidos solo con bloques básicos se verían muy toscos y poco originales. Lo mismo ocurre con el software, no todo lo puedes hacer a base de patrones, pero si los puedes usar como una base sólida y confiable.

A partir de ellos podrás añadirle los bloques que necesites para hacer de tu juego una verdadera obra de arte de la arquitectura de software ;).

Tipos de patrones.

En esta serie de artículos vamos a analizar algunos patrones de diseño especialmente útiles para el desarrollo de juegos, en concreto usaremos C# como lenguaje y Unity como motor 3D. Todo el código y ejemplos estará disponible en nuestro Github.

Los patrones que veremos los podemos clasificar según su propósito o nivel de abstracción en tres grupos:

  • Constructores, patrones que crean instancias.
    • Singleton (próximamente): Garantiza que solo existe una única instancia de la clase y proporciona un acceso global a dicha instancia.
  • Estructurales, composición de clases y objectos.
    • Decorator (próximamente): Añade funcionalidad dinámicamente.
  • Comportamiento, definen interacciones y responsabilidades entre clases y objetos.
    • Visitor (próximamente): Define nuevas operaciones sobre una jerarquía de clases sin modificarlas.

 

¡Hasta el próximo capítulo!

 

You Might Also Like

No Comments

Leave a Reply