Los constructores de complementos de WordPress no deberían definir ganchos
Los constructores de complementos de WordPress parecen ser cada vez más un tema de debate cuando se trata de lo que deben definir. Ya he hablado de eso antes, pero está bien volver a tratar un tema como este de vez en cuando, ¿verdad?
Después de todo, hay cosas que aprendemos y cosas que cambiamos a medida que ganamos más experiencia.
No es nada raro ver complementos que definan ganchos y otros comportamientos, pero no soy un fanático de este enfoque. En cambio, creo que el manejo del registro de ganchos debe hacerse en su propia función o, incluso más drásticamente, debe ser manejado por un conjunto de clases.
Pero antes de entrar en eso, quiero explicar qué debe ir en un constructor de complementos de WordPress, por qué debe ir en un constructor y cómo se puede manejar esto cuando se trabaja en sus complementos.
Constructores de complementos de WordPress
Desde el principio, creo que los constructores deberían usarse para una cosa:
- Inicializar el estado de un objeto.
Lo que define el estado inicial de un objeto puede depender de si se crea "desde cero" o si se carga con información de un conjunto anterior (como una sesión que se serializa). La forma en que lo veo:
- los atributos son sustantivos que describen un objeto,
- Las funciones son verbos que describen lo que el objeto puede hacer.
Las funciones, por supuesto, hacen el trabajo que el objeto es capaz de hacer. Pueden modificar el estado del objeto cuando se les llama, o pueden trabajar con los argumentos pasados a las funciones.
¿Qué debe ir en un constructor?
Cuando se construye un objeto, simplemente debe configurarse de tal manera que sus atributos estén configurados y sus funciones estén listas para funcionar.
Si hay algo en el constructor que no afecta el estado inicial de un objeto, no debería estar allí.
¿Por qué los atributos deben estar en un constructor?
Quizás una mejor manera de hacer esta pregunta es:
¿Por qué no deberían definirse los ganchos en el constructor?
El sistema de ganchos de WordPress es parte del patrón de diseño basado en eventos (del cual soy fanático), pero registrar ganchos no describe el estado del objeto. En cambio, en el nivel más fundamental, es algo que crea una relación con el objeto y WordPress.
No es necesario que el estado inicial del objeto conozca WordPress, que ninguna de sus funciones esté configurada para combinarse con WordPress o que necesite realizar algún procesamiento con WordPress.
Recuerde, los atributos se inicializan en un constructor. WordPress no es un atributo. es una dependencia Crear una dependencia es realizar una acción que es la definición de un verbo.
Por lo tanto, todos los registros de ganchos deben realizarse en una función.
¿Cómo podemos manejar el registro de anzuelos?
Este es uno de esos temas que pueden ser una publicación o una serie de publicaciones propias.
- Es posible crear una clase que mantenga un registro de objetos y los ganchos con WordPress.
- También es posible definir el registro de ganchos dentro de una función en la clase.
- También podemos hacer varias cosas con la inversión de dependencia.
Todo lo anterior son cosas que están más allá del alcance de esta publicación, pero en aras de la simplicidad, mostraré un ejemplo de cómo una clase puede registrar sus funciones con WordPress en una función de inicio :
<?php
namespace AcmeAdmin;
use AcmeAdminInterfaces;
class JavaScript_Assets implements InterfacesAsset {
private $assets_dir;
private $js_dir;
public function __construct() {
$this->assets_dir = trailingslashit(
plugin_dir_url( __FILE__ ). 'assets'
);
$this->js_dir = trailingslashit( $this->assets_dir. 'js' );
}
public function init() {
add_action(
'admin_enqueue_scripts',
array( $this, 'enqueue') );
}
public function enqueue() {
wp_enqueue_script(
'toggle-admin-notices',
$this->js_dir. 'admin.js',
array( 'jquery' ),
false
);
}
}
De esta manera, podemos instanciar el objeto, probarlo, usarlo, etc., pero no tenemos que lidiar con nada relacionado con WordPress sin llamar explícitamente a la función init.
Una vez que se llama, se crea la dependencia, se necesita WordPress y las cosas se complican más.
Ah, y esa cosa de prueba
Quiero mencionar un punto más que está un poco más allá del alcance y el objetivo de esta publicación, pero que sigue siendo relevante: cuando se trata de probar una clase, deberíamos poder:
- crear una instancia de la clase,
- probando su lógica llamando a funciones,
- pasándole parámetros y evaluando sus valores de retorno.
Y deberíamos poder hacer tanto de esto como sea posible de forma aislada. Si se definen ganchos en el constructor, se crea una dependencia inmediata de WordPress que no debería ser necesaria.
WordPress no describe el estado de un objeto. Es una dependencia del objeto.
De todos modos, el punto que estoy tratando de hacer es que los constructores de complementos de WordPress no deben manejar el registro de ganchos porque los ganchos no describen su estado. Están relacionados con algo que hace la clase y nos impiden poder probar un objeto de forma aislada.
Entonces tienen su lugar, pero no está en el constructor.