Si proviene de un entorno orientado a objetos o intenta construir todas sus soluciones para WordPress utilizando t\u00e9cnicas orientadas a objetos, entonces habr\u00e1 momentos en los que puede sentirse como si estuviera golpeando un clavo con un mazo.<\/p>\n
Por ejemplo, supongamos que alguien se acerca a usted y necesita que se desarrolle un complemento personalizado que funcione con un complemento de terceros, pero solo necesita hacer una cosa.<\/p>\n
\u00bfVale la pena tomarse el tiempo para crear una interfaz<\/a><\/strong>, implementar dicha interfaz en una clase concreta, configurar suscriptores<\/a><\/strong>, escribir pruebas unitarias<\/a><\/strong>, etc.?<\/p>\n Puedo ver el atractivo, pero generalmente digo que no. Si la esencia de lo que debe hacer tiene que incluir estilos o archivos JavaScript o ambos, \u00bfpor qu\u00e9 no confiar en las API nativas de WordPress y la programaci\u00f3n de procedimientos?<\/p>\n Digamos que un cliente potencial viene a ti que:<\/p>\n Suponiendo que todo lo anterior sea cierto, entonces dir\u00eda que trabajar en la soluci\u00f3n parece bastante simple, \u00bfverdad? Necesitamos auditar el sitio para que podamos:<\/p>\n Ahora, cuando se trata de hacer esto, todav\u00eda trato de emplear un pu\u00f1ado de mejores pr\u00e1cticas. Aunque tiendo a la programaci\u00f3n orientada a objetos, no siempre la uso ni siempre la recomiendo.<\/p>\n En cambio, creo que usar una funci\u00f3n simple o un conjunto de funciones conectadas a la API de WordPress de manera procesal funciona bien. Sin embargo, eso no significa que no debamos intentar crear una estructura de organizaci\u00f3n de archivos s\u00f3lida porque nunca se sabe cu\u00e1ndo tendr\u00e1 que volver para mantener el proyecto.<\/p>\n Con ese fin, esto es lo que normalmente hago:<\/p>\n El directorio resultante puede verse as\u00ed:<\/p>\n A partir de ah\u00ed, ni siquiera me molesto con un cargador autom\u00e1tico. En su lugar, incluyo los archivos en el directorio de origen. Podr\u00eda iterar a trav\u00e9s de esos archivos en lugar de hacer algo como esto<\/a><\/strong> :<\/p>\n Pero eso podr\u00eda depender de cu\u00e1ndo y qu\u00e9 est\u00e9s haciendo.<\/p>\n Quiz\u00e1s. Aqu\u00ed est\u00e1 la cosa: cada vez que una persona se atrinchera en el uso de un determinado paradigma de programaci\u00f3n, dicha persona trata de aplicarlo en todas partes y trata de hacerlo todo el tiempo.<\/p>\n No todos, pero muchos. Yo mismo incluido.<\/p>\n Y cuando te encuentres sobredise\u00f1ando algo, \u00bfpor qu\u00e9 no dar un paso atr\u00e1s y tratar de simplificar un poco tu carga de trabajo?<\/p>\n El problema a\u00fan est\u00e1 resuelto, y se hace de una manera que tiene una sobrecarga significativamente menor.<\/p>\nNo sobredise\u00f1e<\/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>\nesto es demasiado simple<\/h2>\n