Se provieni da un background orientato agli oggetti o provi a creare tutte le tue soluzioni per WordPress utilizzando tecniche orientate agli oggetti, allora ci saranno momenti in cui potresti sentire come se stessi colpendo un chiodo con una mazza.<\/p>\n
Ad esempio, supponiamo che qualcuno venga da te e abbia bisogno di un plug-in personalizzato sviluppato che funzioni con un plug-in di terze parti ma deve solo fare una cosa.<\/p>\n
Vale la pena dedicare del tempo alla creazione di un’interfaccia<\/a><\/strong>, all’implementazione di detta interfaccia in una classe concreta, alla configurazione degli abbonati<\/a><\/strong>, alla scrittura di unit test<\/a><\/strong> e cos\u00ec via?<\/p>\n Vedo l’appello, ma in genere dico di no. Se l’essenza di ci\u00f2 che devi fare deve includere stili o file JavaScript o entrambi, allora perch\u00e9 non fare affidamento sulle API native di WordPress e sulla programmazione procedurale?<\/p>\n Diciamo che un potenziale cliente viene da te che:<\/p>\n Supponendo che tutto quanto sopra sia vero, direi che elaborare la soluzione sembra abbastanza semplice, giusto? Abbiamo bisogno di controllare il sito in modo da poter:<\/p>\n Ora, quando si tratta di farlo, cerco ancora di utilizzare una manciata di migliori pratiche. Anche se tendo alla programmazione orientata agli oggetti, non la uso sempre n\u00e9 la consiglio sempre.<\/p>\n Invece, penso che l’utilizzo di una semplice funzione o di un insieme di funzioni agganciate all’API di WordPress in modo procedurale funzioni perfettamente. Tuttavia, ci\u00f2 non significa che non dovremmo mirare a creare una solida struttura organizzativa dei file perch\u00e9 non si sa mai quando potrebbe essere necessario tornare per mantenere il progetto.<\/p>\n A tal fine, ecco cosa faccio normalmente:<\/p>\n La directory risultante potrebbe assomigliare a questa:<\/p>\n Da l\u00ec, non mi preoccupo nemmeno di un caricatore automatico. Invece, includo i file nella directory di origine. Puoi scorrere quei file invece di fare qualcosa del genere<\/a><\/strong> :<\/p>\n Ma ci\u00f2 potrebbe dipendere da quando e cosa stai facendo.<\/p>\n Forse. Ecco il punto: ogni volta che una persona si radica nell’uso di un certo paradigma di programmazione, detta persona cerca di applicarlo ovunque e cerca di farlo tutto il tempo.<\/p>\n Non tutti, ma molti. Me stesso incluso.<\/p>\n E quando ti ritrovi a progettare qualcosa in modo eccessivo, perch\u00e9 non fare un passo indietro e provare a semplificare un po’ il tuo carico di lavoro?<\/p>\n Il problema \u00e8 ancora risolto e lo fa in un modo che ha un sovraccarico significativamente inferiore.<\/p>\nNon sovra-ingegnerizzare<\/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>\nQuesto \u00e8 troppo semplice<\/h2>\n