Programación de WordPress: preocupaciones separadas
Cuando se trata de crear clases para complementos de WordPress, me han preguntado por qué me molesto en separar la funcionalidad en suscriptores y en otras clases.
Creo que esta es una buena pregunta porque ayuda a entender dos cosas:
- el papel de un suscriptor en relación con la arquitectura de WordPress,
- el papel de las otras clases en lo que se refiere a lo que está construyendo (y cómo esto puede ayudar con otras cosas como pruebas unitarias, etc.).
Entonces pensé, ¿por qué no responder en forma de una publicación breve? Documentará el por qué detrás del qué [y me dará un lugar para actualizar si las cosas cambian en el futuro].
Programación WordPress: Suscriptores y Objetos de Dominio
Considero las clases que no son objetos de dominio de suscriptores que provienen del enfoque de desarrollo de software del diseño dirigido por dominio.
Eso está fuera del alcance de esta publicación, pero vale la pena mencionarlo, aunque solo sea por la razón de que brinda algo de contexto a lo que de otro modo se consideraría una jerga.
1 Suscriptores
Pero primero, suscriptores.
Dado que WordPress se basa en un sistema de enlace, un sistema que se basa en el patrón de diseño basado en eventos, es útil tener una clase que responda cada vez que se genera un evento.
Esto puede ser para cualquier enlace de WordPress predefinido o cualquier enlace personalizado. No importa.
Y no quiero que la clase sea más complicada de lo necesario, así que tiendo a pensar en ellos así:
Un suscriptor responde cada vez que ocurre un evento específico.
Y eso es. Este evento puede ser algo como after_theme_setup o the_content o incluso init. No importa.
Espera a que suceda un evento y luego responde en lo que decidamos mediante el uso de otro código (que es donde entran en juego los objetos de dominio).
2 objetos de dominio
Estos también pueden llamarse objetos comerciales o algo similar. La idea detrás de ellos es esta:
Todo lo que hacemos en la programación orientada a objetos está destinado a resolver un problema particular y debe hacerlo a través de algún tipo de objeto que represente un objeto del mundo real o al menos una idea concreta.
Por lo tanto, siempre que esté trabajando para proporcionar una solución a alguien, las clases que está escribiendo, los objetos en los que se convertirán cuando se instancian, son los objetos de dominio.
Estas son también las clases que hacen el trabajo real. Así que puedes pensarlo en tres componentes:
- WordPress _ La aplicación principal, por supuesto, que plantea el evento al que responden los suscriptores.
- Suscriptores _ El conjunto de clases responsables de escuchar un evento específico y luego instanciar el objeto adecuado para manejar el código.
- Objetos de dominio. El código que realmente hace el trabajo de tomar un conjunto de datos, operar con ellos y luego potencialmente devolver un valor.
Los objetos de dominio son donde vive el código para hacer algo. Los suscriptores son como la conexión entre WordPress y dicha funcionalidad.
Los suscriptores dicen "Este evento ha sucedido y esta clase es capaz y responsable de manejar los resultados".
¿Qué pasa con las pruebas y demás?
Anteriormente en la publicación, hablé sobre cómo los objetos de dominio se relacionan con las pruebas unitarias y otras técnicas de programación relacionadas con el control de calidad.
Aunque esta no es la publicación para los detalles, vale la pena mencionar que mantener los objetos de dominio y los suscriptores separados entre sí (y, a su vez, de WordPress) nos permite instanciar, probar y trabajar con objetos que son invocados por suscriptores sin necesidad de traer WordPress a nuestro trabajo.
Y esto es algo que puede ser inmensamente útil al construir soluciones más grandes. Pero la esencia de cómo hacerlo es contenido para otra publicación.