Desacoplamiento de la lógica de dominio en WordPress

Recuerda que WordPress usa el patrón de diseño dirigido por eventos y aunque a menudo nos referimos a acciones y filtros, el concepto se reduce a ganchos. El flujo de control a través del programa es algo así:

1. Ejecutar el programa,
2. Cada vez que el programa se encuentra con un gancho (en WordPress, veremos do_actiono apply_filters), itere a través de todos los ganchos registrados,
3. Regrese el control al programa,
4. Ejecutar hasta el final.

Esto no es completamente diferente del patrón de publicador/suscriptor (o PubSub, para abreviar), pero hay una diferencia clave: el patrón controlado por eventos simplemente indica que algo sucedió y, si hay ganchos, se activarán. El Patrón PubSub le dirá a un suscriptor registrado que haga algo.

De todos modos, volvamos a los ganchos en WordPress. Mantener los dos conceptos de ganchos que tenemos se puede hacer más fácilmente si se piensa en ellos de esta manera:

• Las acciones son para hacer algo,
• Los filtros son para procesar datos.

Si está buscando abordar el desarrollo de WordPress de una manera orientada a objetos, no es una buena idea acoplar estrechamente su código al núcleo de WordPress mediante el registro de sus clases a través de enlaces a la aplicación central.

En otras palabras, no registre su lógica de negocios con WordPress. Manténgalos separados. Aquí hay una prueba de fuego para saber si su trabajo está estrechamente relacionado con WordPress: si no puede ejecutar una prueba unitaria contra su clase sin cargar WordPress, está estrechamente relacionado.

Entonces, ¿cuál es la solución? Delegación.

Lógica de dominio en WordPress

La lógica de dominio y la lógica de negocios son intercambiables en lo que a mí respecta, por lo que si ha leído publicaciones anteriores sobre esto y he hablado de ellas de diferentes maneras, sabe por qué.

Crédito

A continuación, la idea de delegar la lógica de WordPress a una clase para la lógica de dominio en WordPress la realiza una clase intermediaria que es responsable de lo siguiente:

1. Suscribiéndote a un gancho,
2. Delegar el trabajo a una clase.

Sé que se supone que las clases deben hacer "una cosa bien", pero ¿y si esa única cosa es la delegación?

comprometer (poderes, funciones, etc.) a otro como agente

el diccionario

Y para asignar correctamente la funcionalidad a otro agente o, en nuestro caso, a una clase, debe tener la capacidad de saber lo que está delegando. A veces, para hacer una cosa necesitas saber varios datos.

Entonces, ¿cómo se ve esto prácticamente hablando? Imagina que tienes un [AbstractSubscriber](https://github.com/tommcfarlin/remove-empty-shortcodes/blob/master/src/Subscriber/AbstractSubscriber.php)to tomará el nombre de un gancho en su constructor:

Y luego, una vez hecho, la loadfunción enviará el trabajo a una clase responsable de realizar el procesamiento.

Tome, por ejemplo, este código de Eliminar códigos cortos vacíos :

Una clase se suscribe a un evento en particular, como [the_content](https://developer.wordpress.org/reference/functions/the_content/), y luego delega el trabajo a la clase de procesamiento de contenido posterior.

Esto literalmente permite que el archivo de arranque del complemento cree una instancia del delegado. Luego, el delegado se conecta a WordPress y cuando WordPress llega al punto adecuado de ejecución, el delegado envía la responsabilidad a la clase responsable de procesarlo.

Toda esta arquitectura no solo es completamente reutilizable (vea el uso de una clase abstracta arriba), sino que nos permite desacoplar la lógica del dominio de WordPress y probarla de forma aislada.

Más sobre separación de preocupaciones

He escrito algunas otras publicaciones sobre la separación de preocupaciones:

• Separación de preocupaciones con plantillas de WordPress
• Separación de preocupaciones con consultas y funciones auxiliares
• Programación de WordPress: preocupaciones separadas