Singletons no WordPress, revisitados (A Time and a Place?)
Antes de começar um post falando sobre o uso de singletons no WordPress (ou, mais apropriadamente, o Singleton Pattern ), quero ter certeza de que você leu os dois artigos a seguir:
- Clonagem em PHP, ou por que seu singleton pode matar o WordPress por Thomas Scholz
- Singletons e seu uso no WordPress por Carl Alexander
Ambos os artigos fornecem uma perspectiva imensamente valiosa sobre esse padrão e os perigos de usá-lo ao longo de nosso trabalho no WordPress; no entanto, isso significa que devemos evitá-los completamente?
Eu não acho.
Então, novamente, eu também reconheço que os artigos não estão dizendo para evitá-los completamente. Eles estão dando casos fortes de como usá-los e os perigos de usá-los, caso você opte por fazê-lo.
E embora eu definitivamente os tenha usado no passado, geralmente parei. No entanto, recentemente me deparei com um caso de uso para um projeto no qual acho aceitável.
Ainda usando Singletons no WordPress?
Para dar uma razão pela qual considero esse padrão específico, acho que vale a pena primeiro entender o caso de uso. Para simplificar:
- Há uma página de administração que permite ao usuário selecionar como deseja exibir as datas no front-end do site.
- Quando o usuário salvar a opção, ele gravará o formato baseado em PHP para a data em uma tabela no WordPress.
- Ao renderizar uma data, o valor será recuperado do banco de dados e aplicado à data a ser renderizada.
E para aqueles que estão curiosos, há apenas um punhado – digamos, quatro ou cinco – maneiras de permitir que o usuário exiba a data.
Como esse projeto em particular permite que os usuários importem CSVs de dados (que incluem datas) e que permitem renderizar dados dos CSVs, embora em um formato diferente, vale a pena notar que há uma quantidade razoável de formatação de data acontecendo no back-end.
Naturalmente, surge uma pergunta:
Por que não apenas formatar a data em que o usuário importa seu CSV?
E isso porque o usuário pode optar por alterar a forma como a data é renderizada após a importação do CSV.
Com isso dito, há todo esse outro mecanismo no plug-in responsável por validar, sanitizar e gravar a entrada do usuário no banco de dados.
Mas quando chega a hora de pegar valores do banco de dados, especialmente quando vem na forma de ler um valor de uma tabela de banco de dados, e fazê-lo em vários pontos em todo o aplicativo, não faria sentido ter um único ponto de qual o valor pode ser derivado?
Uma visão de alto nível de como isso funciona.
Ou, outra maneira de colocar isso, não faz sentido alterar um local no aplicativo que possa facilmente se espalhar pelo restante do aplicativo, em vez de procurar todos os locais possíveis de:
- lendo a opção
- certificando-se de que está definido,
- definir um padrão se não estiver definido,
- e devolvendo o valor?
E é aqui que vejo um uso válido de um singleton no WordPress entrando em ação: uma maneira de ler dados em vários pontos em todo o aplicativo. Isso traz consigo, no entanto, algumas implicações:
- a classe não precisa ser instanciada mais de uma vez (quer dizer, essa é a ideia do singleton),
- não estará lidando com dados mutáveis,
- não estará escrevendo informações ou manipulando informações.
Em outras palavras, ele é o único responsável por recuperar as informações e devolvê-las. É isso. Nada mais.
Um exemplo de implementação
Então, o que isso pode parecer? Aqui está uma implementação aproximada para fins de conversa:
<?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 você pode ver, ele cumpre todos os pontos acima. Ou seja, ele lê os dados, define um valor padrão e o retorna.
Essa classe não faz nada além de ler e retornar um conjunto de dados muito específico.
Uma advertência sobre o cache
Obviamente, como essa classe está lendo dados do banco de dados, ela pode ser – e possivelmente deve ser – armazenada em cache. O objetivo deste post, no entanto, não é entrar em transitórios, expirações e trabalhar com todas essas nuances.
Em vez disso, trata-se de avaliar se este é ou não um caso de uso válido para implementar um singleton no WordPress.
Espere, não tem que ser assim!
Eu sei eu sei. Psíquico! Acredito que seja a terminologia correta, mas vamos manter esse aspecto profissional.
Até este ponto, todo o post falava sobre por que você pode querer investigar o uso de singletons no WordPress para que você tenha uma maneira de recuperar informações facilmente usando princípios consistentemente orientados a objetos.
Mas ainda não acho que usar um singleton no WordPress seja necessário aqui. No mínimo, acho que uma função estática está bem. E a única razão pela qual eu acho que está tudo bem é porque criar uma instância da classe toda vez que você precisa acessar uma função que recupera dados que não serão alterados dentro da classe é um exagero.
Então, como é isso ?
<?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;
}
}
E isso, acredito, é uma solução melhor do que implementar um padrão de design arbitrário quando não é necessário.
Mas estou aberto a ser convencido do contrário.
Pensamentos de desenvolvedores mais experientes?
Eu ouvi de um amigo e colega que simplesmente usar uma função com namespace pode até ser o caminho a seguir. Claramente, há uma variedade de maneiras de lidar com isso.
E com isso, estou interessado em saber como vocês podem refatorar isso ainda mais. Não estou muito preocupado com a implementação da função get, pois ela é montada principalmente para a demonstração.
Em vez disso, estou interessado em maneiras de lidar com isso fora do que é apresentado aqui. Ou melhor, apenas sua opinião sobre o que você vê.