Singletons en WordPress, revisado (¿un tiempo y un lugar?)
Antes de comenzar una publicación hablando sobre el uso de singletons en WordPress (o, más apropiadamente, el Patrón Singleton ), quiero asegurarme de que lea los siguientes dos artículos:
- Clonación en PHP, o por qué su singleton podría acabar con WordPress por Thomas Scholz
- Singletons y su uso en WordPress por Carl Alexander
Ambos artículos brindan una perspectiva inmensamente valiosa sobre este patrón y los peligros de usarlo cada vez que lo usamos a lo largo de nuestro trabajo en WordPress; sin embargo, ¿eso significa que debemos evitarlos por completo?
No me parece.
Por otra parte, también reconozco que los artículos no dicen que los evite por completo. Están dando casos sólidos sobre cómo usarlos y los peligros de usarlos si opta por hacerlo.
Y aunque definitivamente los he usado en el pasado, por lo general he dejado de hacerlo. Sin embargo, recientemente encontré un caso de uso para un proyecto en el que creo que es aceptable.
¿Sigues usando Singletons en WordPress?
Para dar una razón de por qué incluso considero este patrón en particular, creo que primero vale la pena comprender el caso de uso. Para hacerlo mas simple:
- Hay una página de administración que le permite al usuario seleccionar cómo le gustaría mostrar las fechas en el front-end del sitio.
- Cuando el usuario guarde la opción, escribirá el formato basado en PHP para la fecha en una tabla en WordPress.
- Al representar una fecha, el valor se recuperará de la base de datos y se aplicará a la fecha que se va a representar.
Y para aquellos que tienen curiosidad, solo hay un puñado, digamos cuatro o cinco, formas en que permitimos que el usuario muestre la fecha.
Debido a que este proyecto en particular permite a los usuarios importar CSV de datos (que incluyen fechas) y eso les permite representar datos de los CSV aunque en un formato diferente, vale la pena señalar que hay una buena cantidad de formato de fecha en el back-end.
Naturalmente, surge una pregunta:
¿Por qué no simplemente formatear la fecha cuando el usuario importa su CSV?
Y eso se debe a que el usuario puede optar por cambiar la forma en que se representa la fecha después de que se haya importado el CSV.
Dicho esto, existe todo este otro mecanismo en el complemento responsable de validar, desinfectar y escribir la entrada del usuario en la base de datos.
Pero cuando llega el momento de obtener valores de la base de datos, especialmente cuando se trata de leer un valor de una tabla de base de datos y hacerlo en múltiples puntos a lo largo de la aplicación, ¿no tendría sentido tener un solo punto desde que el valor se puede derivar?
Una mirada de alto nivel a cómo funciona esto.
O, de otra manera, ¿no tiene sentido cambiar un lugar en la aplicación que puede conectarse fácilmente en cascada en el resto de la aplicación en lugar de buscar todos los lugares posibles de:
- leyendo la opción,
- asegurándose de que esté configurado,
- definir un valor predeterminado si no está establecido,
- y devolver el valor?
Y aquí es donde veo que entra en juego un uso válido de un singleton en WordPress: una forma de leer datos en múltiples puntos a lo largo de la aplicación. Sin embargo, esto conlleva algunas implicaciones:
- la clase no necesita ser instanciada más de una vez (quiero decir, esa es toda la idea del singleton),
- no tratará con datos mutables,
- no será escribir información o manipular información.
En otras palabras, es el único responsable de recuperar la información y devolverla. Eso es todo. Nada más.
Una implementación de ejemplo
Entonces, ¿cómo podría ser esto? Aquí hay una implementación aproximada para el propósito de la conversación:
<?php
class Date_Formatter {
private static $instance;
private function __construct() {
}
private static function get_instance() {
if (null === self::$instance) {
self::$instance = new self;
}
return self::$instance;
}
public static function get() {
self::get_instance();
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Como ves, cumple con todos los puntos anteriores. Es decir, lee datos, establece un valor predeterminado y luego lo devuelve.
Esta clase no hace nada más que leer y devolver un conjunto de datos muy específico.
Una advertencia sobre el almacenamiento en caché
Obviamente, dado que esta clase está leyendo datos de la base de datos, puede almacenarse en caché, y posiblemente debería almacenarse en caché. Sin embargo, el objetivo de esta publicación no es entrar en transitorios, vencimientos y trabajar con todos esos matices.
En cambio, se trata de evaluar si este es o no un caso de uso válido para implementar un singleton en WordPress.
¡Espera, no tiene por qué ser así!
Sé que sé. ¡ psicólogo! Creo que es la terminología correcta, pero mantengamos este estilo profesional.
Hasta este punto, toda la publicación hablaba sobre por qué es posible que desee investigar el uso de singletons en WordPress para que tenga una forma de recuperar información fácilmente utilizando principios consistentemente orientados a objetos.
Pero todavía no creo que sea necesario usar un singleton en WordPress aquí. Como mínimo, creo que una función estática está bien. Y la única razón por la que creo que está bien es porque crear una instancia de la clase cada vez que necesita acceder a una función que recupera datos que no cambiarán dentro de la clase es una exageración.
Entonces, ¿cómo es este aspecto?
<?php
class Date_Formatter {
public static function get() {
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Y eso, creo, es una mejor solución que implementar un patrón de diseño arbitrario cuando no se necesita en absoluto.
Pero estoy abierto a que me convenzan de lo contrario.
¿Pensamientos de desarrolladores más experimentados?
Escuché de un amigo y compañero que simplemente usar una función de espacio de nombres podría ser el camino a seguir. Claramente, hay una variedad de formas de abordar esto.
Y con eso, me interesa saber del resto de ustedes cómo pueden refactorizar esto aún más. No estoy muy preocupado por la implementación de la función get, ya que se creó principalmente para la demostración.
En cambio, estoy interesado en formas de manejar esto fuera de lo que se presenta aquí. O, más bien, simplemente tu opinión sobre lo que ves.