Cuando se trata de crear clases para complementos de WordPress, me han preguntado por qu\u00e9 me molesto en separar la funcionalidad en suscriptores y en otras clases.<\/p>\n
Creo que esta es una buena pregunta porque ayuda a entender dos cosas:<\/p>\n
Entonces pens\u00e9, \u00bfpor qu\u00e9 no responder en forma de una publicaci\u00f3n breve? Documentar\u00e1 el por qu\u00e9 detr\u00e1s del qu\u00e9 [y me dar\u00e1 un lugar para actualizar si las cosas cambian en el futuro].<\/p>\n
Considero las clases que no son objetos de dominio de suscriptores que provienen del enfoque de desarrollo de software del dise\u00f1o dirigido por dominio.<\/p>\n
Eso est\u00e1 fuera del alcance de esta publicaci\u00f3n, pero vale la pena mencionarlo, aunque solo sea por la raz\u00f3n de que brinda algo de contexto a lo que de otro modo se considerar\u00eda una jerga.<\/p>\n
Pero primero, suscriptores.<\/p>\n
Dado que WordPress se basa en un sistema de enlace, un sistema que se basa en el patr\u00f3n de dise\u00f1o basado en eventos, es \u00fatil tener una clase que responda cada vez que se genera un evento.<\/p>\n
Esto puede ser para cualquier enlace de WordPress predefinido o cualquier enlace personalizado. No importa.<\/p>\n
Y no quiero que la clase sea m\u00e1s complicada de lo necesario, as\u00ed que tiendo a pensar en ellos as\u00ed:<\/p>\n
Un suscriptor responde cada vez que ocurre un evento espec\u00edfico.<\/p>\n
Y eso es. Este evento puede ser algo como after_theme_setup<\/a> o the_content<\/a> o incluso init<\/a>. No importa.<\/p>\n Espera a que suceda un evento y luego responde en lo que decidamos mediante el uso de otro c\u00f3digo (que es donde entran en juego los objetos de dominio).<\/p>\n Estos tambi\u00e9n pueden llamarse objetos comerciales o algo similar. La idea detr\u00e1s de ellos es esta:<\/p>\n Todo lo que hacemos en la programaci\u00f3n orientada a objetos est\u00e1 destinado a resolver un problema particular y debe hacerlo a trav\u00e9s de alg\u00fan tipo de objeto que represente un objeto del mundo real o al menos una idea concreta.<\/p>\n Por lo tanto, siempre que est\u00e9 trabajando para proporcionar una soluci\u00f3n a alguien, las clases que est\u00e1 escribiendo, los objetos en los que se convertir\u00e1n cuando se instancian, son los objetos de dominio.<\/p>\n Estas son tambi\u00e9n las clases que hacen el trabajo real. As\u00ed que puedes pensarlo en tres componentes:<\/p>\n Los objetos de dominio son donde vive el c\u00f3digo para hacer algo. Los suscriptores son como la conexi\u00f3n entre WordPress y dicha funcionalidad.<\/p>\n Los suscriptores dicen "Este evento ha sucedido y esta clase es capaz y responsable de manejar los resultados".<\/p>\n Anteriormente en la publicaci\u00f3n, habl\u00e9 sobre c\u00f3mo los objetos de dominio se relacionan con las pruebas unitarias y otras t\u00e9cnicas de programaci\u00f3n relacionadas con el control de calidad.<\/p>\n Aunque esta no es la publicaci\u00f3n para los detalles, vale la pena mencionar que mantener los objetos de dominio y los suscriptores separados entre s\u00ed (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.<\/p>\n Y esto es algo que puede ser inmensamente \u00fatil al construir soluciones m\u00e1s grandes. Pero la esencia de c\u00f3mo hacerlo es contenido para otra publicaci\u00f3n.<\/p>\n2 objetos de dominio<\/h3>\n
\n
\u00bfQu\u00e9 pasa con las pruebas y dem\u00e1s?<\/h2>\n