Sobre los valores inmutables en los complementos de WordPress

Si ha realizado algún trabajo, o incluso alguna lectura, sobre la programación orientada a objetos, es probable que se haya topado con la idea de la inmutabilidad. Esa es la idea de que algo no cambia.

A veces puede tener valores inmutables y, a veces, puede tener objetos inmutables (al menos después de que se instancian).

Lo opuesto a inmutable (pero él era mi tortuga ninja favorita, de todos modos).

La cuestión es que cuanto más trabajo con código orientado a objetos, menos tiendo a trabajar con variables inmutables. Claro, usaré constantes como se definen en un archivo de configuración, pero no es probable que me encuentres almacenando valores dentro de una clase como const.

Eso probablemente implica algo sobre mí y mis habilidades, pero es verdad. Afortunadamente, las revisiones de código son excelentes para ayudarlo a ver oportunidades sobre dónde aprovechar estrategias que normalmente no haría. Y tal es el caso de los valores inmutables en los complementos de WordPress.

Por supuesto, esta es una de esas cosas que un amigo me llamó la atención al revisar mi código.

Cuando trabajamos con WordPress, es probable que muchos de nosotros estemos familiarizados con functions.php y wp-config.php y el papel que desempeñan en la aplicación principal de WordPress.

Sí, hay momentos en los que las cosas pertenecen a wp-config.php, y sí, hay momentos en los que las cosas pertenecen a functions.php, pero a veces creo que se abusa de ese archivo en particular con demasiadas funciones, valores, etc. .

Pero, ¿qué pasa con los complementos? Específicamente, ¿qué pasa con los complementos orientados a objetos? Por ejemplo, supongamos que está trabajando con una API que requiere una clave de API, por lo que no se encuentra con un límite de velocidad particular con una versión gratuita de la aplicación.

Por lo general, es posible que me encuentre almacenando el valor en la clase de complemento principal como una variable de instancia que se puede pasar, o tal vez esté en una clase de contenedor a la que puedo referirme y usar su método de obtención .

Pero, ¿qué pasa con el uso de una  propiedad const en una clase y luego pasarla a través de una inyección de setter?

Por ejemplo, supongamos que hay una clase de complemento que se basa en una clase auxiliar para representar algo en la pantalla. La clave API se puede definir en esta clase y luego pasar al asistente cuando sea necesario :

A continuación, la clase de ayuda puede realizar una llamada a la API arbitraria (lo llamo Canvas ya que hipotéticamente seremos algo) utilizando su URL y pasa la clave API como parte de la cadena de consulta.

De esta manera:

• hay un solo lugar en el que se guarda el valor,
• hay un nombre descriptivo que indica lo que almacena,
• se puede pasar a otras clases con una dependencia mínima,
• las otras clases pueden referirse a ellas como variables locales o como variables de instancia (dependiendo de cómo se transmitan).

Claro, hay otras formas en las que se pueden mantener estos valores (nuevamente con el uso de functions.php o algo similar).

Pero si está trabajando con programación orientada a objetos y desea trabajar con valores inmutables en un complemento de WordPress, ¿no tendría sentido mantenerlo en el contexto de las clases que componen el complemento?