Patrones de Diseño de Software
Tags: softwaredesign, php, diseñodepatrones, designpatterns
Published: 2019-07-18 10:28:42

---
title: Patrones de Diseño de Software
published: true
tags: software-design,php,diseño-de-patrones,design-patterns
canonical_url: https://medium.com/all-you-need-is-clean-code/patrones-de-dise%C3%B1o-b7a99b8525e
---

![](https://cdn-images-1.medium.com/max/1024/1*o0SR0QrsG8mr8Evrhpvi5Q.png)

#### Introducción

Como programadores seguramente nos habremos dado cuenta de que muchas veces resolvemos un mismo problema de manera diferente. Esto al principio de nuestra carrera puede ser algo positivo: experimentamos diferentes formas de enfocar un problema y podemos comparar los pros y los contras de nuestras anteriores soluciones, pero con el paso del tiempo nos gusta ir directamente al grano, y aplicar la solución más escalable, más testeable y más reutilizable. Por supuesto el no tener que explicar a cada compañero cómo hemos resuelto el caso es también algo deseable, pero esto no lo solucionan los patrones (a menos que nuestro compañero también los conozca).

#### ¿Qué son los patrones de diseño de software?

Pues ni más ni menos son formas “estandarizadas” de resolver problemas comunes de diseño en el desarrollo de software.

Las ventajas del uso de patrones son evidentes:

- Conforman un amplio catálogo de problemas y soluciones
- Estandarizan la resolución de determinados problemas
- Condensan y simplifican el aprendizaje de las buenas prácticas
- Proporcionan un vocabulario común entre desarrolladores
- Evitan “reinventar la rueda”

#### Libros sobre patrones de diseño

Uno de los primeros libros que trató el tema de los patrones fue el famoso [Design Patterns](http://amzn.to/2jLlbJE) del _Gang of Four_: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides. El paso del tiempo ha hecho que algunos de los patrones tratados sean considerados actualmente _antipatrones._

Un libro para aprender sobre patrones de forma más amena es el [Head First Design Patterns](http://amzn.to/2jPwUag) que a mi personalmente me gusta bastante.

Y si lo que queremos es aprender a refactorizar nuestro código para que este saque partido de los patrones de diseño es el [Refactoring to patterns](http://amzn.to/2iGokav) de Joshua Kerievsky, en el que el autor nos proporciona sobre cada patrón:

- Una explicación teórica (con UML incluido)
- Una _receta_ para aplicar el patrón
- Un ejemplo de código refactorizable
- La aplicación de la receta sobre el código anterior.

Estos son mis tres libros de cabecera sobre patrones, pero existe mucha literatura al respecto.

### Tipos de patrones

Según la finalidad del patrón, estos se clasifican en tres tipos:

- Patrones Creacionales
- Patrones Estructurales
- Patrones de comportamiento.

Veamos en detalle cada uno de estos tipos.

#### Patrones Creacionales

Como su nombre indica, estos patrones vienen a solucionar o facilitar las tareas de creación o instanciación de objetos.

Estos patrones hacen hincapié en la encapsulación de la lógica de la instanciación, ocultando los detalles concretos de cada objeto y permitiéndonos trabajar con abstracciones.

Algunos de los patrones creacionales más conocidos son:

- [**Factory**](https://medium.com/all-you-need-is-clean-code/patr%C3%B3n-factory-5b39eef765df): Desacoplar la lógica de creación de la lógica de negocio, evitando al cliente conocer detalles de la instanciación de los objetos de los que depende.
- **Abstract Factory** : Nos provee una interfaz que delega la creación de una serie de objetos relacionados sin necesidad de especificar cuáles son las implementaciones concretas.
- **Factory Method:** Expone un método de creación, delegando en las subclases la implementación de este método.
- **Builder** : Separa la creación de un objeto complejo de su estructura, de tal forma que el mismo proceso de construcción nos puede servir para crear representaciones diferentes.

#### Patrones estructurales

Los patrones estructurales nos ayudan a definir la forma en la que los objetos se componen.

Los patrones estructurales más habituales son:

- **Adapter** : Nos ayuda a definir una clase intermedia que sirve para que dos clases con diferentes interfaces puedan comunicarse. Esta clase actúa como mediador, haciendo que la clase A pueda ejecutar métodos de la clase B sin conocer detalles de su implementación. También se conoce como  **Wrapper.**
- **Decorator** : Permite añadir funcionalidad extra a un objeto (_decora_ el objeto) sin modificar el comportamiento del resto de instancias.
- **Facade** : Una _fachada_ es un objeto que crea una interfaz simplificada para tratar con otra parte del código más compleja.

#### Patrones comportamentales

Los patrones comportamentales nos ayudan a definir la forma en la que los objetos interactúan entre ellos.

Algunos de los más conocidos (por citar unos pocos) son:

- **Command** : Son objetos que encapsulan una acción y los parámetros que necesitan para ejecutarse.
- **Observer** : Los objetos son capaces de suscribirse a una serie de eventos que otro objeto va a emitir, y serán avisados cuando esto ocurra.
- **Strategy** : Permite la selección del algoritmo que ejecuta cierta acción en tiempo de ejecución.
- **Template Method** : Especifica el esqueleto de un algoritmo, permitiendo a las subclases definir cómo implementan el comportamiento real.

### Antipatrones

No todos los patrones iban a ser buenos, existen los llamados **antipatrones** , una especie de gemelos malvados que nos llevan a implementar malas soluciones.

![](https://cdn-images-1.medium.com/max/400/1*_Wrg3MbG-PuiLJk_or_Cwg.jpeg)<figcaption>Siempre hay un gemelo malvado.</figcaption>

Es bueno conocer también antipatrones para detectar a tiempo un futuro quebradero de cabeza.

Antes hablábamos sobre el libro del GoF (Gang of Four) y como algunos patrones se han llegado a considerar antipatrones. Un ejemplo muy claro es el patrón _Singleton_.

El patrón Singleton es un patrón creacional, que nos ayuda a que de una clase solo exista una instancia. Esto es útil en casos como por ejemplo los objetos que manejan la conexión a una base de datos u otros servicios, ya que reduce el uso de memoria restringiendo la creación de más objetos.

Por otra parte, el patrón hace uso de métodos privados y estáticos, reduce el objeto casi a una variable global, dificulta el testing… El uso puntual de singleton no tiene porque ser malo en si mismo, pero el abuso puede resultar fatal a corto plazo, por lo que un buen número de programadores lo considera un antipatrón.

### Próximos artículos

Ahora que hemos introducido el concepto de patrones de diseño y sus distintos tipos, lo próximo será una serie de posts dedicados cada uno a un patrón: teoría e implementación del mismo.

Se aceptan peticiones ;)

* * *