Advertisement
  1. Code
  2. Creative Coding

Patrones de diseño en WordPress: Una introducción

Scroll to top
Read Time: 9 min
This post is part of a series called Design Patterns in WordPress.
Design Patterns in WordPress: The Singleton Pattern

Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)

Para aquellos que tengan una amplia experiencia en ingeniería de software, los patrones de diseño deberían ser territorio familiar; sin embargo, hay todo un grupo de desarrolladores, especialmente en la comunidad de desarrollo web, que no están necesariamente familiarizados con los patrones de diseño (¡aunque probablemente los hayan usado!).

En esta serie, vamos a echar un vistazo a los patrones de diseño, específicamente en el contexto de WordPress, cuál es su utilidad, y algunos ejemplos prácticos que podemos usar en nuestros temas y plugins.

El objetivo final de la serie es proporcionar una sólida definición sobre qué son los patrones de diseño, por qué son útiles, cómo se utilizan en el núcleo de WordPress, y luego revisar dos populares ejemplos que podemos emplear fácilmente en nuestro propio trabajo.

Antes de llegar a echar un vistazo a algunos ejemplos prácticos, vamos a definir los patrones de diseño, y a ver un ejemplo de cómo se utilizan en el núcleo de WordPress.


Patrones de diseño definidos

Para aquellos de vosotros que nunca hayáis oído hablar de los patrones de diseño o que nunca los hayáis utilizado, es importante entender qué son antes de que comencemos realmente a usarlos en nuestro trabajo.

Wikipedia proporciona la siguiente definición:

Un patrón de diseño en arquitectura e informática es una manera formal de documentar una solución a un problema de diseño en un campo de especialización concreto. A una colección organizada de patrones de diseño relacionados con un campo determinado se la denomina un lenguaje de patrones.

Tal vez una definición más simplificada sería:

Un patrón es un diseño que se puede aplicar a un problema en una situación concreta.

Si aún no ha quedado claro, concíbelo de esta manera:

  • Cada vez que estés construyendo una pieza de software, es probable que te reconozcas resolviendo un problema que ya habías resuelto con anterioridad. Por tanto, ya sabes cómo resolverlo.
  • Naturalmente, la solución al problema vendrá en una forma un poco más generalizado que es aplicable a cómo lo hayas aplicado previamente.
  • Esta forma generalizada de la solución se puede considerar el patrón de diseño.

La implementación general y la arquitectura tendrán exactamente el mismo aspecto; sin embargo, naturalmente, los detalles de la implementación variarán de un proyecto a otro, pero esa es sencillamente la naturaleza de la bestia.

En las próximas secciones y artículos, echaremos un vistazo a esto con un poco más de detalle.


Patrones de diseño en WordPress

Si has hecho cualquier tipo de desarrollo de WordPress que involucre el sistema de ganchos, es decir, has escrito plugins completos, temas, o incluso una sencilla función y has aprovechado las funciones add_action o add_filter, has usado patrones de diseño.

WordPress utiliza lo que se llama un patrón de diseño basado en eventos. Existen varias variaciones de patrones de diseño basadas en eventos, una de las cuales revisaremos momentáneamente, pero la esencia de los patrones es la misma:

  • Parte del patrón implementa lo que se conoce como un editor
  • Parte del patrón implementa lo que se conoce como suscriptor

En términos generales, el editor difunde un mensaje de que algo le ha sucedido a todos los objetos que están suscritos a ese editor en particular.

Otra forma de ver esto es que, en el software, cada vez que sucede algo decimos que se plantea un evento. Tal vez el lugar más habitual en el que observamos esto en el desarrollo web es en JavaScript, con cosas como el ratón con el que se hace clic, una tecla del teclado que es presionada, o algo similar.

A continuación, escribimos funciones que controlan esas funciones y estas funciones se conocen correctamente como controladores de eventos porque son responsables de gestionar la situación cuando se produce un evento.

No es muy complicado, ¿verdad? Honestamente, a veces pienso que la terminología puede ser más confusa que la implementación real en sí.

Así que de todos modos, en el contexto de WordPress, o cualquier aplicación web, para el caso, los eventos no se limitan a pulsaciones de teclas o clics del ratón. En su lugar, pueden tener lugar durante varias partes del ciclo de vida de carga de la página, cuando los datos se escriben en la base de datos, cuando los datos son leídos en la base de datos, etc.

En última instancia, puedes implementar el patrón como desees para proporcionar ganchos en los que los desarrolladores puedan registrar funciones que se activen tan pronto como se produzca el evento.

Esto nos trae el círculo completo de vuelta a la arquitectura de WordPress: Los ganchos se colocan en todo el código de tal manera que seamos capaces de registrar una función que se dispare cada vez que ocurra algo (es decir, cada vez que ocurra un evento).


Un vistazo a una arquitectura impulsada por eventos: el patrón del observador

Hay una serie de patrones de diseño controlados por eventos, uno de los cuales se conoce como el patrón de observador. Este patrón en particular también se conoce como el patrón de publicador-suscriptor o, de forma más concisa, Pub-Sub.

En la implementación más simple de este patrón, hay un solo editor que es el responsable de transmitir mensajes a uno o a muchos suscriptores. Los suscriptores son responsables de registrarse con el editor, y luego el editor es responsable de enviar un mensaje o tomar medidas sobre todos los suscriptores.

Un diagrama de alto nivel sería algo similar a esto:

WordPress Design PatternsWordPress Design PatternsWordPress Design Patterns

Desde la perspectiva del código, el editor necesita tres cosas:

  1. Un medio de mantener una lista de los suscriptores
  2. Un medio para que los suscriptores puedan registrarse
  3. Un medio para transmitir un mensaje a todos los suscriptores

Del mismo modo, el suscriptor necesita poder hacer dos cosas:

  1. Registrarse en el Editor
  2. Opcionalmente, toma medidas cuando el editor le envíe un mensaje

Existen varias maneras en las que esto se puede implementar, pero para todos los propósitos y para mantener el ejemplo relativamente simple, supongamos que los suscriptores se registrarán al editor con el método register del observador y la función acepta una referencia al suscriptor y cada suscriptor tiene un método update que el editor invoca al transmitir el mensaje.

Código del editor

El código anterior es tan simple como podamos hacerlo:

Para aquellos que tengan más experiencia con técnicas orientadas a objetos, es probable que veas la necesidad de crear una interfaz de clase para el editor, pero que está fuera del ámbito de este tutorial concreto.

Recuerda, el propósito consiste simplemente en proporcionar un ejemplo de cómo puede ser un simple observador.

Código de suscripción

La creación de un editor es realmente solo la mitad de la implementación. Recuerda, tenemos que tener algo que realmente, ya sabes, se suscriba al editor para tomar medidas cada vez que algo suceda.

Aquí es donde entra en juego el adecuado nombre de Suscriptor.

En resumen, esto es todo. Ten en cuenta que en esta implementación de arriba la función update no está realmente definida. Esto se debe a que nos da la capacidad de proporcionar un comportamiento único a esta instancia específica.

Pero recuerda, hay una gran cantidad de código en el núcleo de WordPress que no está orientado a objetos. En cambio, es procedimental. Por tanto, la implementación de un patrón como este varía un poco.

Por ejemplo, una analogía en WordPress sería algo como esto:

Observa que la sintaxis es un poco diferente, pero esencialmente estamos haciendo algo muy similar:

  • Tenemos una función de suscripción, my_custom_subscriber, y está registrada con el evento the_content
  • Cuando se active la función the_content, se activará nuestra función personalizada.

Nada demasiado complicado, espero.

Uno de los objetivos de esta serie no es solo proporcionar algunos ejemplos de patrones de diseño y cómo implementarlos, sino que ya están en su lugar en los sistemas existentes.


Los patrones que examinaremos

Además del patrón basado en eventos que hemos examinado anteriormente, también vamos a echar un vistazo a dos patrones que son comunes, prácticos y muy útiles en nuestro trabajo diario.

Específicamente, vamos a echar un vistazo a los siguientes patrones:

  1. Patrón Singleton. En el diseño orientado a objetos, el patrón Single garantiza que solo se crea una única instancia de una clase. Esto es útil para que no creemos accidentalmente varias instancias manteniendo sus propios conjuntos de datos, lo que en última instancia proporcionaría resultados en conflicto durante el ciclo de vida de un proyecto.
  2. Patrón de fábrica simple. Si tienes una colección de clases cada una de las cuales está diseñada para controlar un tipo concreto de datos (en lugar de tener una clase amplia, el patrón de fábrica simple es útil para echar un vistazo a los datos entrantes y, a continuación, devolver una instancia de la clase adecuada para procesar los datos.

Obviamente, hablar de software no va muy lejos si no hablamos de diagramas y/o código, por lo que echaremos un vistazo a ambos en los próximos conjuntos de artículos.


Conclusión

Como puedes ver, el concepto de patrones de diseño no es nada terriblemente complicado y ganamos mucho utilizándolos en nuestro trabajo. Tal vez el mayor desafío al que se enfrentan los desarrolladores es al uso de patrones de diseño sin motivo.

En lugar de eso, es importante reconocer que hay ciertas situaciones en las que los patrones de diseño son aplicables. Es decir, hay ciertos problemas para los que los patrones de diseño son la solución perfecta. La experiencia es sin duda el mejor maestro para saber cuándo usar un patrón de diseño y cuándo no hacerlo.

En los siguientes artículos, esperamos poder cubrir suficiente territorio para proporcionar dos sólidos ejemplos de patrones de diseño, cuándo son aplicables, cómo usarlos y cómo pueden ayudarnos en nuestro trabajo futuro.

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.