Se hai svolto un lavoro, o anche una lettura, sulla programmazione orientata agli oggetti, probabilmente ti sei imbattuto nell’idea di immutabilit\u00e0. Questa \u00e8 l’idea di qualcosa che non cambia.<\/p>\n
A volte puoi avere valori immutabili e talvolta puoi avere oggetti immutabili (almeno dopo che sono stati istanziati).<\/p>\n
L’opposto di immutabile (ma comunque era la mia tartaruga ninja preferita).<\/p>\n
Il fatto \u00e8 che pi\u00f9 lavoro con codice orientato agli oggetti, meno tendo a lavorare con variabili immutabili. Certo, user\u00f2 le costanti come definite in un file di configurazione, ma \u00e8 probabile che tu non mi trovi a memorizzare valori all’interno di una classe come const<\/a>.<\/p>\n Questo probabilmente implica qualcosa su di me e sulle mie capacit\u00e0, ma \u00e8 vero. Per fortuna, le revisioni del codice<\/a> sono ottime per aiutarti a vedere opportunit\u00e0 su dove sfruttare strategie che normalmente non avresti. E questo \u00e8 il caso dei valori immutabili nei plugin di WordPress.<\/p>\n Naturalmente, questa \u00e8 una di quelle cose che \u00e8 stata portata alla mia attenzione da un amico<\/a> durante la revisione del mio codice.<\/p>\n Quando si lavora con WordPress, molti di noi hanno probabilmente familiarit\u00e0 con functions.php<\/strong> e wp-config.php<\/strong> e il ruolo che svolgono nell’applicazione principale di WordPress.<\/p>\n S\u00ec, ci sono momenti in cui le cose appartengono a wp-config.php<\/strong>, e s\u00ec, ci sono volte in cui le cose appartengono a functions.php<\/strong>, ma a volte penso che quel particolare file sia abusato con troppe funzioni, valori e cos\u00ec via .<\/p>\n Ma per quanto riguarda i plugin? In particolare, che dire dei plugin orientati agli oggetti? Ad esempio, supponiamo che tu stia lavorando con un’API che richiede una chiave API, quindi non ti imbatti in un limite di velocit\u00e0 particolare con una versione gratuita dell’applicazione.<\/p>\n Di solito, potresti trovarmi a memorizzare il valore nella classe del plugin principale come una variabile di istanza che pu\u00f2 essere passata, o forse \u00e8 in una classe contenitore a cui posso fare riferimento e utilizzare il suo metodo get .<\/strong><\/p>\n Ma che dire dell’utilizzo di una\u00a0 propriet\u00e0 const<\/a> in una classe e quindi del suo passaggio tramite iniezione setter?<\/p>\n Ad esempio, supponiamo che esista una classe plug-in che si basa su una classe helper per eseguire il rendering di qualcosa sullo schermo. La chiave API pu\u00f2 essere definita in questa classe e quindi passata all’helper quando necessario<\/a> :<\/p>\n Successivamente, la classe helper pu\u00f2 effettuare una chiamata all’API arbitraria (la chiamo Canvas poich\u00e9 ipoteticamente saremo qualcosa) utilizzando il suo URL e passa la chiave API come parte della stringa di query.<\/p>\n Per di qua:<\/p>\n Certo, ci sono altri modi in cui questi valori possono essere mantenuti (di nuovo usando functions.php<\/strong> o qualcosa di simile).<\/p>\n Ma se stai lavorando con la programmazione orientata agli oggetti e vuoi lavorare con valori immutabili in un plugin di WordPress, non avrebbe senso mantenerlo nel contesto delle classi che compongono il plugin?<\/p>\n<?php\n\nclass Main_Plugin {\n\n const ACME_API_KEY = '123456789';\n\n public function init() {\n\n $helper = new Helper_Class();\n $helper->render_acme_data( self::ACME_API_KEY );\n }\n}<\/code><\/pre>\n<?php\n\nclass Helper_Class {\n\n public function render_acme_data( string $api_key) {\n\n $canvas_url = 'https:\/\/url-for-canvas.com?api_key='. $api_key;\n $canvas = new Canvas( $canvas_url );\n\n $canvas->draw();\n }\n}<\/code><\/pre>\n\n