Programación Orientada a Objetos: Patrones de diseño.

¡Bienvenidos un día más a un nuevo rootie queridos amigos! Estamos ya en la última semana de publicación de ohmyroot! por este año, ya que a partir de la semana que viene, ¡nos vamos de vacaciones hasta 2017!. Así que para hoy voy a hablar sobre algo para lo que he ido sentando bases, ¡hoy es el día de los Patrones de diseño!

Patrones de diseño.

En el mundo de la programación los patrones de diseño es una solución general y reusable para problemas recurrentes. Esto no quiere decir que sea una solución que se pueda convertir directamente a código, es una descripción o plantilla de como resolver el problema, que podemos utilizar para diferentes problemas y circunstancias.

patrones de diseño narcos
No, no es este patrón del que estamos hablando, aunque resuelve bastantes problemas.

Tipos de patrones.

A lo largo de los años en el mundo del desarrollo del software han ido apareciendo diferentes patrones y esto se han agrupado en función de sus aplicaciones y encontramos cinco grandes categorías:

  1. Patrones de diseño creacionales: Son los que dan solución a como gestionar la creación de objetos (¡qué inesperado!) proporcionando la mejor solución para cada situación. En esta categoría encontramos;  Factory, Object Pool, Singleton (aunque estoy dividido entre considerarlo patrón o antipatrón)
  2. Patrones de diseño estructurales: Son aquellos que facilitan el diseño identificando formas sencillas de relacionar entidades. Algunos ejemplos son, patrón Decorator, Proxy o Wrapper.
  3. Patrones de diseño de comportamiento: Estos son los que identifican patrones comunes de comunicación entre objetos. El más famoso puede que sea el Observer, pero también patrones como Chain of responsibility o Memento
  4. Patrones de concurrencia: Estos son los que ofrecen soluciones para paradigmas de desarrollo multi-hilo. En este ultimo grupo encontramos el patrón Active Object o el Reactor.

Estos son los cuatro grupos clásicos y se que vais a sacar las antorchas y las horcas diciéndome que no veis MVC por ningún sitio, esto es por una razón muy sencilla MVC; no es un patrón de diseño, es un patrón arquitectónico.

Un patrón arquitectónico  es similar a un patrón de software, pero con un ámbito mayor y nos ayudan a definir elementos esenciales para la cohesión de nuestra solución, también ayudan a solucionar problemas como las limitaciones de rendimiento del hardware, alta disponibilidad o reducir del riesgo de negocio.

Ventajas de los patrones de diseño.

El uso de los patrones de diseño tiene muchísimas ventajas y creo que a día de hoy, pocos o muy pocos se opondrán a esta afirmación, ya que las ventajas y beneficios de su uso están más que demostrados.

Nos van a ahorrar tiempo.

Esto es así, siempre. Como desarrolladores debemos ser personas eficientes, y el estar constantemente buscando nuevas soluciones al mismo problema, te hacen perder muchísimo tiempo.

Un patrón de diseño ayudan a solucionar este problema, ya que una vez que conozcas cuales están a tu disposición, podrás implementarlo sin preocuparte de si es la solución correcta (99% de los casos lo es).

Te aseguran la validez de la solución.

Enlazando con el punto anterior, podemos decir que siempre que escribimos una nueva solución de código, podemos cuestionarnos si estamos siguiendo el camino correcto, como ya he mencionado, los patrones son soluciones que se han probado desde hace ya muchos años y por millones de programadores, así que posiblemente si, es lo correcto.

En este punto y en el anterior he sido muy tajante hablando siempre en absolutos de correcto o incorrecto, pero no toméis esto como una invitación o no cuestionarios la decisión, siempre, siempre, siempre has de cuestionarte estas decisiones.

Facilitan la comunicación

El uso de patrones ya definidos, con sus reglas particulares, hará mucho mas sencillo el explicar a otras personas como has solucionado cierto problema a la par que agilizará la toma de decisiones en un equipo en materia de como afrontar el diseño de soluciones.

Eligiendo un patrón

Me he guardado este punto para el final, porque aquí es donde:

la cosa se pone fea

Pero no os asustéis, no es tan malo como parece. El como elegir un patrón es una decisión muy difícil, ya que no hay una «Guía ilustrada para elegir patrones» es una acción que nace de la experiencia.

Hay situaciones conocidas de ante mano donde sabemos que patrón nos va a ayudar más, pero en otras es simplemente una acción de analizar bien el problema y conocer bien los entresijos del patrón a implementar, para poder hacer una decisión lo mas acertada posible.

Más difícil aun…

Y con esto acabamos por hoy con nuestra entrada. El Jueves hablaremos (posiblemente) sobre el patrón de arquitectura que esta más de moda MVC.

Para cualquier duda, pregunta, comentario, soborno o amenaza, podéis usar los comentarios o en nuestras redes sociales Facebook y Twitter.

2 Comments

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *