Programação WordPress: Separando Preocupações
Quando se trata de criar classes para plugins do WordPress, me perguntaram por que me incomodo em separar a funcionalidade em assinantes e em outras classes.
Acho que essa é uma boa pergunta porque ajuda a entender duas coisas:
- o papel de um assinante no que se refere à arquitetura do WordPress,
- o papel das outras classes no que se refere ao que você está construindo (e como isso pode ajudar com outras coisas, como testes de unidade e assim por diante).
Então pensei por que não responder na forma de um post curto? Ele documentará o porquê por trás do quê [e me dará um lugar para atualizar se as coisas mudarem no futuro].
Programação WordPress: Assinantes e Objetos de Domínio
Considero as classes que não são objetos de domínio de assinantes que vêm da abordagem de desenvolvimento de software de design orientado a domínio.
Isso está fora do escopo deste post, mas vale a pena mencionar se, por nenhuma outra razão, fornecer algum contexto ao que de outra forma seria considerado jargão.
1 assinantes
Mas primeiro, assinantes.
Como o WordPress é baseado em um sistema de gancho – um sistema baseado no padrão de design orientado a eventos – é útil ter uma classe que responda sempre que um evento é gerado.
Isso pode ser para qualquer gancho predefinido do WordPress ou qualquer gancho personalizado. Isso não importa.
E eu não quero tornar a aula mais complicada do que o necessário, então eu costumo pensar assim:
Um assinante responde sempre que um evento específico acontece.
E é isso. Este evento pode ser algo como after_theme_setup ou the_content ou até mesmo init. Não importa.
Ele espera que um evento aconteça e então responde o que decidirmos através do uso de outro código (que é onde os objetos de domínio entram em jogo).
2 Objetos de Domínio
Eles também podem ser chamados de objetos de negócios ou algo semelhante. A ideia por trás deles é a seguinte:
Tudo o que fazemos na programação orientada a objetos tem como objetivo resolver um problema específico e é feito através de algum tipo de objeto que representa um objeto do mundo real ou pelo menos uma ideia concreta.
Então, sempre que você está trabalhando para fornecer uma solução para alguém, as classes que você está escrevendo – os objetos que eles se tornarão quando instanciados – são os objetos de domínio.
Essas também são as classes que fazem o trabalho real. Então você pode pensar nisso em três componentes:
- WordPress. O aplicativo principal, é claro, que gera o evento ao qual os assinantes respondem.
- Assinantes. O conjunto de classes responsável por escutar um evento específico e então instanciar o objeto apropriado para manipular o código.
- Objetos de Domínio. O código que realmente faz o trabalho de pegar um conjunto de dados, operar nele e potencialmente retornar um valor.
Os objetos de domínio são onde reside o código para realmente fazer algo. Os assinantes são como a conexão entre o WordPress e a referida funcionalidade.
Os assinantes dizem “Este evento aconteceu e esta classe é capaz e responsável por lidar com os resultados dele".
E quanto ao teste e assim por diante?
Anteriormente no post, falei sobre como os objetos de domínio estão relacionados ao teste de unidade e outras técnicas de programação relacionadas ao controle de qualidade.
Embora este não seja o post para os detalhes, vale a pena mencionar que manter objetos de domínio e assinantes desacoplados um do outro (e, por sua vez, do WordPress) nos permite instanciar, testar e trabalhar com objetos que são invocados por assinantes sem precisar trazer o WordPress para o nosso trabalho.
E isso é algo que pode ser imensamente útil ao construir soluções maiores. Mas a essência de como fazer isso é conteúdo para outro post.