Se voc\u00ea vem de um background orientado a objetos ou tenta construir todas as suas solu\u00e7\u00f5es para WordPress usando t\u00e9cnicas orientadas a objetos, haver\u00e1 momentos em que pode parecer que voc\u00ea est\u00e1 acertando um prego com uma marreta.<\/p>\n
Por exemplo, digamos que algu\u00e9m venha at\u00e9 voc\u00ea e precise de um plugin personalizado desenvolvido que funcione com um plugin de terceiros, mas ele s\u00f3 precisa fazer uma coisa.<\/p>\n
Vale a pena dedicar um tempo para criar uma interface<\/a><\/strong>, implementar a referida interface em uma classe concreta, configurar assinantes<\/a><\/strong>, escrever testes<\/a><\/strong> de unidade e assim por diante?<\/p>\n Eu posso ver o apelo, mas geralmente digo n\u00e3o. Se a ess\u00eancia do que voc\u00ea precisa fazer deve incluir estilos ou arquivos JavaScript ou ambos, por que n\u00e3o confiar nas APIs nativas do WordPress e na programa\u00e7\u00e3o processual?<\/p>\n Digamos que um cliente em potencial venha at\u00e9 voc\u00ea que:<\/p>\n Supondo que todos os itens acima sejam verdadeiros, ent\u00e3o eu diria que trabalhar com a solu\u00e7\u00e3o parece bastante simples, certo? Precisamos auditar o site para que possamos:<\/p>\n Agora, quando se trata de fazer isso, ainda tento empregar um punhado de pr\u00e1ticas recomendadas. Mesmo tendo tend\u00eancia para a programa\u00e7\u00e3o orientada a objetos, nem sempre a uso nem sempre a recomendo.<\/p>\n Em vez disso, acho que usar uma fun\u00e7\u00e3o simples ou um conjunto de fun\u00e7\u00f5es conectadas \u00e0 API do WordPress de maneira processual funciona bem. No entanto, isso n\u00e3o significa que n\u00e3o devemos ter como objetivo criar uma estrutura s\u00f3lida de organiza\u00e7\u00e3o de arquivos porque voc\u00ea nunca sabe quando pode ter que voltar para manter o projeto.<\/p>\n Para esse fim, aqui est\u00e1 o que eu normalmente fa\u00e7o:<\/p>\n O diret\u00f3rio resultante pode ser algo assim:<\/p>\n A partir da\u00ed, nem me incomodo com um carregador autom\u00e1tico. Em vez disso, incluo os arquivos no diret\u00f3rio de origem. Voc\u00ea pode percorrer esses arquivos versus fazer algo assim<\/a><\/strong> :<\/p>\n Mas isso pode depender de quando e o que voc\u00ea est\u00e1 fazendo.<\/p>\n Pode ser. Aqui est\u00e1 a coisa: sempre que uma pessoa se enra\u00edza no uso de um determinado paradigma de programa\u00e7\u00e3o, essa pessoa tenta aplic\u00e1-lo em todos os lugares e tenta faz\u00ea-lo o tempo todo.<\/p>\n Nem todos, mas muitos. Eu mesmo inclu\u00eddo.<\/p>\n E quando voc\u00ea se encontra arquitetando algo em excesso, por que n\u00e3o dar um passo para tr\u00e1s e tentar tornar sua carga de trabalho um pouco mais simples?<\/p>\n O problema ainda est\u00e1 resolvido, e \u00e9 feito de uma maneira que tem uma sobrecarga significativamente menor.<\/p>\nN\u00e3o exagere na engenharia<\/h2>\n
\n
\n
\n
<?php\n\/**\n * Acme Plugin Example\n *\n * @author Tom McFarlin <tom@pressware.co>\n * @license GPL-3.0+\n * @link https:\/\/pressware.co\n * @since 1.0.0\n * @copyright 2018 Tom McFarlin\n *\n * @wordpress-plugin\n * Plugin Name: Acme Plugin Example\n * Description: Provides consistent styling across the site for certain elements.\n * Version: 1.0.0\n * Author: Tom McFarlin\n * Author URI: https:\/\/tommcfarlin.com\n * License: GPL-3.0+\n * License URI: http:\/\/www.gnu.org\/licenses\/gpl-3.0.txt\n *\/\n\ninclude_once plugin_dir_path(__FILE__).'src\/AddStyles.php';\ninclude_once plugin_dir_path(__FILE__).'src\/AddScripts.php';\n<\/code><\/pre>\nIsso \u00e9 muito simples<\/h2>\n