Usando um Registro, Assinantes e Serviços no WordPress

TL; DR: Acho o uso de um registro, assinantes e serviços muito útil ao criar plugins e utilitários centrados em back-end para WordPress. Este post mostra como fazer isso.

Depois de trabalhar com padrões de design, programação orientada a objetos e WordPress por anos, maneiras comuns de resolver problemas devem surgir.

Foi assim que conseguimos padrões de design orientados a objetos para começar, então talvez essa seja uma variação centrada no WordPress disso.

Embora eu tenha escrito sobre coisas como registros em artigos anteriores (e até mesmo aqueles que não são tão antigos ), nunca é uma má ideia revisitar o mesmo tópico, especialmente quando há algo a acrescentar ao take anterior.

Um Registro, Assinantes e Serviços

Tudo descrito abaixo deve ser entendido dentro do contexto do plugin WordPress. Ou seja, isso não deve ser lido como uma maneira de trabalhar com outras estruturas, linguagens, aplicativos ou ao usá-lo com outros padrões.

Lembre-se disso ao ler isso.

De qualquer forma, a ideia geral por trás da combinação desses tipos de objetos é a seguinte:

1. O registro lida com todos os assinantes,
2. Os assinantes escutam ganchos dentro do WordPress (os que existem ou até mesmo ganchos personalizados),
3. Os serviços fazem o trabalho real sempre que o assinante os despacha.

O objetivo é que haja um único local para registrar as classes responsáveis ​​pelo despacho do trabalho. É isso.

Além disso, isso também facilita manter as coisas separadas para que, se você quiser testar seus serviços isoladamente, seja muito mais fácil porque eles não estão necessariamente acoplados ao WordPress. E se forem, você pode simular os dados que precisam ser passados ​​para uma determinada função e avaliar o resultado.

Este não é um artigo sobre testes, portanto, voltemos às classes reais.

Registro

Por definição, o objetivo de um registro é acompanhar as coisas. Quando se trata de implementar esse padrão no WordPress, a ideia é que o registro possa acompanhar os assinantes (que definirei mais adiante neste artigo).

Foto de Denny Müller no Unsplash

Além disso, a ideia é que, quando chegar a hora, o que provavelmente será diferente, independentemente da estrutura do seu plug-in, todos os assinantes serão instanciados. Até esse ponto, porém, você provavelmente vai querer fazer isso no início do ciclo de vida do WordPress.

Dito isto, aqui está um exemplo de como o código para registrar os assinantes:

private $subscribers = [
    AssetSubscriber::class,
    // ...
    DeletedUserSubscriber::class,
];

Em seguida, aqui está uma função para instanciar os assinantes.

Esses blocos podem fazer parte da mesma função ou podem ser separados dependendo de suas necessidades.

Assinantes

Como mencionado, os assinantes são o caminho para:

1. Ouça um certo gancho no WordPress
2. Despache um serviço para fazer qualquer trabalho destinado ao gancho fornecido.

Portanto, suponha por um momento que você queira fazer algo sempre que um usuário for excluído. Você deseja instanciar um serviço por meio do assinante sempre que esse gancho acontecer.

Foto de Lee Campbell no Unsplash

Como um exemplo:

Observe que o assinante está ciente do serviço (embora não mantenha dependência dele, pois é simplesmente um intermediário entre o WordPress e o serviço) e especifica o gancho no serviço que está instanciando.

Serviços

Finalmente, os serviços são os objetos que fazem todo o trabalho pesado em um plugin. Isso significa que, se eles precisarem ler ou gravar no banco de dados, no sistema de arquivos, na rede, nos dados do processo etc., tudo acontecerá dentro de seu contexto.

Foto de Erik Mclean no Unsplash

Eles podem estar cientes de outras classes, eles podem não estar. Eles podem implementar uma interface ou uma classe abstrata ou não. Isso está realmente além do escopo deste post. Mas o ponto é que, usando o gancho acima como exemplo, se você quiser fazer algo quando um usuário for excluído, faça isso dentro do serviço.

Por exemplo:

class DeletedUserService
{
    public function add(string $hook)
    {
        add_action($hook, [$this, 'deletedUser'], 99, 1);
    }

    public function deletedUser(int $userId)
    {
        $user = get_userdata($userId);
        if (false === $user) {
            return;
        }

        // Do work with the user that's being deleted.   
    }
}

E esse é o fim. Assim que o serviço for executado, o controle será devolvido ao WordPress e o aplicativo continuará a execução normalmente.

Todos juntos agora

Supondo que você tenha um arquivo bootstrap para seu plugin, o que a maioria faz, pois é onde o plugin necessário é definido, um autoloader é necessário e a instanciação do próprio plugin ocorre.