Quando usar as subações do WordPress (e quais são elas?)

Recentemente, passei pelo processo de usar o construtor de uma classe para impedir que um plug-in funcione se uma dependência esperada não for carregada.

Embora eu não considere essa estratégia específica um problema para uma dependência única ou em determinadas situações, existem maneiras de isso pode levar a cheiros de código.

Também nos impede de usar um recurso nativo do Core chamado subações do WordPress:

https://twitter.com/JJJ/status/822265137935646720

Mas antes de olhar para as subações, quero ter certeza de que estou ciente dos problemas que o uso da abordagem condicional (versus subações) pode gerar cheiros de código.

Subações do WordPress

Há muitas maneiras de explicar os cheiros de código, mas minha maneira favorita vem de Martin Fowler :

…os cheiros são certas estruturas no código que indicam violação de princípios fundamentais de design e impactam negativamente a qualidade do design.

Há outra ótima página sobre cheiros de código no Source Making que eu recomendo ler se você tiver uma chance.

E a maneira como as condicionais podem levar a cheiros de código é simples: tem potencial para encher seu código com um conjunto enorme de instruções que incluem muitas verificações de class_exists.

E isso é um problema.

Cada vez que você introduz outra dependência em seu código, você acaba adicionando mais uma verificação condicional para ver se uma classe está presente no aplicativo WordPress.

Eu acredito que não há problema em fazer isso com uma única dependência – talvez até duas dependências – e se você estiver trabalhando "alto o suficiente" em sua arquitetura, mas não é assim que lidar adequadamente com muitas dependências nem em um nível mais baixo em seu plug-in.

É aí que as subações do WordPress entram em cena. Você pode ver uma lista de subações no tweet via John acima.

Há uma definição oficial de sub-ações no bbPress Codex também:

Essas ações internas podem ser consideradas como “subações" e permitem que você adicione ou reordene as ações do WordPress conforme necessário para plugins que dependem do bbPress.

E você pode ver um exemplo disso neste arquivo.

Claro, essa definição é específica do bbPress, mas isso não significa que não seja aplicável ao que fazemos no WordPress.

Caso em questão: se você já usou do_action para definir uma ação personalizada ou se aproveitou de um gancho fornecido por outra pessoa fora do núcleo do WordPress, então você está familiarizado com a estratégia de implementação de uma subação.

Em outras palavras, as subações do WordPress são simplesmente ações que podemos usar para alterar a ordem em que nosso plugin depende de outro plugin.

Como isso é implementado pode variar dentro do contexto do seu trabalho, mas a maneira mais popular e “correta” do WordPress de fazer isso é, sem dúvida, aproveitar o argumento de prioridade para quando seu plugin é carregado.

Ou seja, tome a prioridade da dependência e certifique-se de que ela seja anterior à ativação do seu plug-in.

Existem métodos alternativos que podem ser usados, como alterar o comportamento do plugin sempre que são ativados ou não, mas isso está fora do escopo deste post em particular, e pode alterar negativamente a experiência do usuário (do WordPress em geral, nada menos).

Independentemente disso, o ponto é que, quando se trata de usar subações do WordPress, programação orientada a objetos e gerenciamento de dependências de terceiros, certifique-se de que as decisões que você está tomando não prejudiquem o design do seu código.

Se fizer sentido verificar a existência de uma classe, tudo bem, mas se fizer mais sentido esperar até que um conjunto de classes ou plugins seja carregado antes do seu, então as subações do WordPress provavelmente farão mais sentido.