Construtores de plugins do WordPress não devem definir ganchos

Os construtores de plugins do WordPress parecem ser cada vez mais um tópico de debate quando se trata do que eles devem definir. Já falei sobre isso antes, mas não há problema em revisitar um tópico como esse de vez em quando, certo?

Afinal, há coisas que aprendemos e coisas que mudamos à medida que ganhamos mais experiência.

Não é incomum ver plugins definindo ganchos e outros comportamentos, mas não sou fã dessa abordagem. Em vez disso, acho que o tratamento do registro do gancho deve ser feito em sua própria função ou, ainda mais drasticamente, tratado por um conjunto de classes.

Mas antes de entrar nisso, quero explicar o que deve estar em um construtor de plugins do WordPress, por que ele deve estar em um construtor e como isso pode ser tratado ao trabalhar em seus plugins.

Construtores de plugins do WordPress

Desde o início, acho que os construtores devem ser usados ​​para uma coisa:

• Inicializando o estado de um objeto.

O que define o estado inicial de um objeto pode depender se ele foi criado “do zero" ou se está sendo carregado com informações de um conjunto anterior (como uma sessão sendo serializada).

• atributos são substantivos que descrevem um objeto,
• funções são verbos que descrevem o que o objeto pode fazer.

As funções, é claro, fazem o trabalho que o objeto é capaz de fazer. Eles podem modificar o estado do objeto quando chamados, ou podem trabalhar nos argumentos passados ​​para as funções.

O que deve ir em um construtor?

Quando um objeto é construído, ele deve simplesmente ser configurado de tal forma que seus atributos sejam configurados e suas funções estejam prontas para funcionar.

Se houver algo no construtor que não afete o estado inicial de um objeto, ele não deve estar lá.

Por que os atributos devem estar em um construtor?

Talvez uma maneira melhor de fazer essa pergunta seja:

Por que os ganchos não devem ser definidos no construtor?

O sistema de ganchos do WordPress faz parte do padrão de design orientado a eventos (do qual sou fã), mas registrar ganchos não descreve o estado do objeto. Em vez disso, no nível mais fundamental, é algo que cria um relacionamento com o objeto e o WordPress.

O estado inicial do objeto não precisa conhecer o WordPress, ter alguma de suas funções configuradas para ser acoplada ao WordPress, ou precisar fazer qualquer processamento com o WordPress.

Lembre-se, os atributos são inicializados em um construtor. WordPress não é um atributo. É uma dependência. Criar uma dependência é realizar uma ação que é a definição de um verbo.

Assim, todo registro de gancho deve ser feito em uma função.

Como podemos lidar com o registro de gancho?

Este é um daqueles tópicos que podem ser um post ou uma série de posts próprios.

• É possível criar uma classe que mantenha um registro de objetos e os ganchos com o WordPress.
• Também é possível definir o registro de gancho dentro de uma função na classe.
• Também podemos fazer várias coisas com inversão de dependência.

Todos os itens acima são coisas que estão além do escopo deste post, mas para simplificar, mostrarei um exemplo de como uma classe pode registrar suas funções com o WordPress em uma função init :

<?php

namespace AcmeAdmin;
use AcmeAdminInterfaces;

class JavaScript_Assets implements InterfacesAsset {

    private $assets_dir;

    private $js_dir;

    public function __construct() {

        $this->assets_dir = trailingslashit(
            plugin_dir_url( __FILE__ ). 'assets'
        );

        $this->js_dir = trailingslashit( $this->assets_dir. 'js' );
    }

    public function init() {

        add_action(
            'admin_enqueue_scripts',
            array( $this, 'enqueue') );
    }

    public function enqueue() {

        wp_enqueue_script(
            'toggle-admin-notices',
            $this->js_dir. 'admin.js',
            array( 'jquery' ),
            false
        );
    }
}

Dessa forma, podemos instanciar o objeto, testá-lo, usá-lo etc., mas não precisamos lidar com nada relacionado ao WordPress sem chamar explicitamente a  função init.

Uma vez que isso é chamado, a dependência é criada, o WordPress é necessário e as coisas ficam mais complicadas.

Ah, e essa coisa de teste

Quero mencionar mais um ponto que está um pouco além do escopo e do objetivo deste post, mas ainda é relevante: Quando se trata de testar uma classe, devemos ser capazes de:

1. crie uma instância da classe,
2. testando sua lógica chamando funções,
3. passando-lhe parâmetros e avaliando seus valores de retorno.

E devemos ser capazes de fazer o máximo possível de forma isolada. Se os ganchos forem definidos no construtor, ele cria uma dependência imediata no WordPress que não deve ser necessária.

O WordPress não descreve o estado de um objeto. É uma dependência do objeto.

De qualquer forma, o ponto que estou tentando mostrar é que os construtores de plugins do WordPress não devem lidar com o registro de ganchos porque os ganchos não descrevem seu estado. Eles estão relacionados a algo que a classe faz e nos impedem de testar um objeto isoladamente.

Então eles têm seu lugar, mas não é no construtor.