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.<\/p>\n
Acho que essa \u00e9 uma boa pergunta porque ajuda a entender duas coisas:<\/p>\n
Ent\u00e3o pensei por que n\u00e3o responder na forma de um post curto? Ele documentar\u00e1 o porqu\u00ea por tr\u00e1s do qu\u00ea [e me dar\u00e1 um lugar para atualizar se as coisas mudarem no futuro].<\/p>\n
Considero as classes que n\u00e3o s\u00e3o objetos de dom\u00ednio de assinantes que v\u00eam da abordagem de desenvolvimento de software de design orientado a dom\u00ednio.<\/p>\n
Isso est\u00e1 fora do escopo deste post, mas vale a pena mencionar se, por nenhuma outra raz\u00e3o, fornecer algum contexto ao que de outra forma seria considerado jarg\u00e3o.<\/p>\n
Mas primeiro, assinantes.<\/p>\n
Como o WordPress \u00e9 baseado em um sistema de gancho \u2013 um sistema baseado no padr\u00e3o de design orientado a eventos \u2013 \u00e9 \u00fatil ter uma classe que responda sempre que um evento \u00e9 gerado.<\/p>\n
Isso pode ser para qualquer gancho predefinido do WordPress ou qualquer gancho personalizado. Isso n\u00e3o importa.<\/p>\n
E eu n\u00e3o quero tornar a aula mais complicada do que o necess\u00e1rio, ent\u00e3o eu costumo pensar assim:<\/p>\n
Um assinante responde sempre que um evento espec\u00edfico acontece.<\/p>\n
E \u00e9 isso. Este evento pode ser algo como after_theme_setup<\/a> ou the_content<\/a> ou at\u00e9 mesmo init<\/a>. N\u00e3o importa.<\/p>\n Ele espera que um evento aconte\u00e7a e ent\u00e3o responde o que decidirmos atrav\u00e9s do uso de outro c\u00f3digo (que \u00e9 onde os objetos de dom\u00ednio entram em jogo).<\/p>\n Eles tamb\u00e9m podem ser chamados de objetos de neg\u00f3cios ou algo semelhante. A ideia por tr\u00e1s deles \u00e9 a seguinte:<\/p>\n Tudo o que fazemos na programa\u00e7\u00e3o orientada a objetos tem como objetivo resolver um problema espec\u00edfico e \u00e9 feito atrav\u00e9s de algum tipo de objeto que representa um objeto do mundo real ou pelo menos uma ideia concreta.<\/p>\n Ent\u00e3o, sempre que voc\u00ea est\u00e1 trabalhando para fornecer uma solu\u00e7\u00e3o para algu\u00e9m, as classes que voc\u00ea est\u00e1 escrevendo \u2013 os objetos que eles se tornar\u00e3o quando instanciados \u2013 s\u00e3o os objetos de dom\u00ednio.<\/p>\n Essas tamb\u00e9m s\u00e3o as classes que fazem o trabalho real. Ent\u00e3o voc\u00ea pode pensar nisso em tr\u00eas componentes:<\/p>\n Os objetos de dom\u00ednio s\u00e3o onde reside o c\u00f3digo para realmente fazer algo. Os assinantes s\u00e3o como a conex\u00e3o entre o WordPress e a referida funcionalidade.<\/p>\n Os assinantes dizem “Este evento aconteceu e esta classe \u00e9 capaz e respons\u00e1vel por lidar com os resultados dele".<\/p>\n Anteriormente no post, falei sobre como os objetos de dom\u00ednio est\u00e3o relacionados ao teste de unidade e outras t\u00e9cnicas de programa\u00e7\u00e3o relacionadas ao controle de qualidade.<\/p>\n Embora este n\u00e3o seja o post para os detalhes, vale a pena mencionar que manter objetos de dom\u00ednio e assinantes desacoplados um do outro (e, por sua vez, do WordPress) nos permite instanciar, testar e trabalhar com objetos que s\u00e3o invocados por assinantes sem precisar trazer o WordPress para o nosso trabalho.<\/p>\n E isso \u00e9 algo que pode ser imensamente \u00fatil ao construir solu\u00e7\u00f5es maiores. Mas a ess\u00eancia de como fazer isso \u00e9 conte\u00fado para outro post.<\/p>\n2 Objetos de Dom\u00ednio<\/h3>\n
\n
E quanto ao teste e assim por diante?<\/h2>\n