Usando el patrón de registro en WordPress

He tenido algunas conversaciones con varios amigos y otras personas en Twitter sobre la noción de variables globales en lenguajes de programación. Para aquellos que son nuevos en la programación o que no están seguros de por qué son malos:

El uso de variables globales hace que el software sea más difícil de leer y comprender. Dado que cualquier código en cualquier parte del programa puede cambiar el valor de la variable en cualquier momento, comprender el uso de la variable puede implicar comprender una gran parte del programa.

Esto no quiere decir que no tengan su uso, pero si está interesado en la programación orientada a objetos (especialmente en una configuración de WordPress donde usará PHP), entonces es importante comprender algunas alternativas mejores. que las variables globales.

Es decir, hay formas de trabajar pasando datos por la aplicación sin necesidad de variables globales. Y una de esas formas es el patrón de registro.

El patrón de registro en WordPress

Primero, tenga en cuenta que los patrones de diseño trascienden cualquier patrón en particular. Siempre que un lenguaje ofrezca los conceptos de objetos (o incluso abstracciones), entonces es posible implementar el patrón.

Pero, ¿por qué molestarse en usar esto?

Foto de Samuel Zeller en Unsplash

En resumen, proporciona una forma orientada a objetos de pasar información alrededor de su aplicación sin necesidad de variables globales. Cosas como los contenedores de inyección de dependencia también son buenos para esto, pero están más allá del alcance de esta publicación. También diría que hay momentos en los que pueden ser excesivos en el contexto de pequeños complementos.

Implementando el Patrón

Dicho esto, ¿cómo podemos implementar el patrón de registro en WordPress y luego aprovecharlo a lo largo de nuestro trabajo? Echemos un vistazo a la estructura básica del patrón, primero:

<?php

/**
 * Serves as a registry for all objects that need to be accessed globally throughout the
 * plugin.
 */
class Registry
{

  /**
   * @var array The array used to the the various objects that will be used in the plugin.
   */
  private $storage;

  /**
   * Initializes the plugin by creating an instance of an empty array.
   */
  public function __construct()
  {
      $this->storage = [];
  }

  /**
   * Adds an instance of a class to the registry's storage array using the given key
   *
   * @param string $id    The ID of the object to be used to retrieve it later in the plugin.
   * @param mixed  $class An instance of the class that will be associated with the specified key.
   */
  public function add($id, $class)
  {
      $this->storage[$id] = $class;
  }

  /**
   * @param string $id    The ID of the object to retrieve from the repository.
   * @return mixed $class An instance of the class associated with the specified key (or null if it doesn't exist).
   */
  public function get($id)
  {
      return array_key_exists($id, $this->storage)? $this->storage[$id]: null;
  }
}

Observe que su implementación es bastante simple:

1. La clase contiene una única matriz como propiedad privada.
2. Los datos se agregan a la matriz con una identificación específica.
3. Los datos se pueden recuperar del patrón con el ID.

Incluso podría llevar este patrón en particular al siguiente nivel si acepta solo una clase de cierto tipo (como un AbstractEvent, por ejemplo) y luego invoca automáticamente una función en la clase cada vez que se pasa (o se recupera) del registro.

Pero eso es entrar en una implementación más compleja que me gustaría para esta publicación.

Configuración del Registro

Debido a la naturaleza del sistema de enlace de WordPress, hay una forma particular en la que el Registro debe configurarse y luego registrarse con WordPress.

Digamos que estás trabajando con un complemento. Dentro del archivo de arranque del complemento, haga algo como esto:

<?php

/**
 * Creates a Registry using the Registry Design Pattern to store objects
 * that can be used throughout the plugin.
 *
 */
$registry = new Registry();
add_filter('acmeRegistry', function() use ($registry) {
  return $registry;
});

Esto crea el registro y luego crea un filtro correspondiente que podemos usar más adelante en el complemento para recuperar el registro y, por lo tanto, otros objetos que mantiene.

Uso del Registro

Para agregar un objeto al registro, llame a la función de agregar y pase una identificación única y una instancia del objeto. Tenga en cuenta que nuestra implementación actual eliminará cualquier instancia anterior de un objeto que tenga la misma clave y la reemplazará con lo que le pasemos.

<?php

/**
 * Get an reference to the repository and add an instance of a 
 * PostManager to it. The PostManager is a class that allows us
 * to manipulate posts.
 */
$this->registry = apply_filters('acmeRegistry', null);
$this->registry->add('postManager', new PostManager());

Desde allí, puede recuperar los objetos que almacenó en el registro:

<?php

/**
 * Get an reference to the repository, get a reference to the PostManager
 * then you can begin working with it.
 */
$this->registry = apply_filters('acmeRegistry', null);
$this->registry->add('postManager', new PostManager());

// An example call that you can make to set the title of the post.
$postManager->updateTitle('This Is the New Title');

Y puedes usarlos como lo haría oyu de cualquier otra manera. Pero esto evita la necesidad de usar singletons, variables globales u otras cosas peligrosas.

Una palabra sobre la capacidad de prueba

Otra ventaja que encuentro con la implementación de este patrón es que no solo te permite escribir más fácilmente pruebas unitarias contra él, sino que también te da la capacidad de escribir pruebas contra los objetos que puede contener.

Con eso quiero decir que puede escribir sus clases de manera más independiente de WordPress, separando así la lógica del dominio de la aplicación central y haciéndolas más representativas de los datos que se supone que deben mantener.