Si vous avez fait des travaux – ou m\u00eame des lectures – sur la programmation orient\u00e9e objet, vous avez probablement rencontr\u00e9 l’id\u00e9e d’immuabilit\u00e9. C’est l’id\u00e9e que quelque chose est immuable.<\/p>\n
Parfois, vous pouvez avoir des valeurs immuables, et parfois vous pouvez avoir des objets immuables (au moins apr\u00e8s leur instanciation).<\/p>\n
Le contraire d’immuable (mais c’\u00e9tait ma tortue ninja pr\u00e9f\u00e9r\u00e9e, de toute fa\u00e7on).<\/p>\n
Le fait est que plus je travaille avec du code orient\u00e9 objet, moins j’ai tendance \u00e0 travailler avec des variables immuables. Bien s\u00fbr, j’utiliserai des constantes telles que d\u00e9finies dans un fichier de configuration, mais vous ne me trouverez probablement pas en train de stocker des valeurs dans une classe en tant que const<\/a>.<\/p>\n Cela implique probablement quelque chose sur moi et mes capacit\u00e9s, mais c’est vrai. Heureusement, les r\u00e9visions de code<\/a> sont tr\u00e8s utiles pour vous aider \u00e0 voir les opportunit\u00e9s d’exploiter des strat\u00e9gies que vous ne feriez pas normalement. Et c’est le cas des valeurs immuables dans les plugins WordPress.<\/p>\n Bien s\u00fbr, c’est l’une de ces choses qui a \u00e9t\u00e9 port\u00e9e \u00e0 mon attention par un ami<\/a> lors de la r\u00e9vision de mon code.<\/p>\n Lorsque vous travaillez avec WordPress, beaucoup d’entre nous connaissent probablement functions.php<\/strong> et wp-config.php<\/strong> et le r\u00f4le qu’ils jouent dans l’application principale de WordPress.<\/p>\n Oui, il y a des moments o\u00f9 des choses appartiennent \u00e0 wp-config.php<\/strong>, et oui, il y a des moments o\u00f9 des choses appartiennent \u00e0 functions.php<\/strong>, mais parfois je pense que ce fichier particulier est abus\u00e9 avec beaucoup trop de fonctions, de valeurs, etc. .<\/p>\n Mais qu’en est-il des plugins? Plus pr\u00e9cis\u00e9ment, qu’en est-il des plugins orient\u00e9s objet\u00a0? Par exemple, supposons que vous travaillez avec une API qui n\u00e9cessite une cl\u00e9 API, de sorte que vous ne vous heurtez pas \u00e0 une limite de d\u00e9bit particuli\u00e8re avec une version gratuite de l’application.<\/p>\n Habituellement, vous pouvez me trouver en train de stocker la valeur dans la classe principale du plug-in en tant que variable d’instance pouvant \u00eatre transmise, ou peut-\u00eatre dans une classe de conteneur \u00e0 laquelle je peux me r\u00e9f\u00e9rer et utiliser sa\u00a0 m\u00e9thode get<\/strong>.<\/p>\n Mais qu’en est-il de l’utilisation d’une\u00a0 propri\u00e9t\u00e9 const<\/a> dans une classe, puis de la transmettre via une injection de setter ?<\/p>\n Par exemple, supposons qu’il existe une classe de plug-in qui s’appuie sur une classe d’assistance pour afficher quelque chose \u00e0 l’\u00e9cran. La cl\u00e9 API peut \u00eatre d\u00e9finie dans cette classe puis pass\u00e9e dans le helper si besoin<\/a> :<\/p>\n Ensuite, la classe d’assistance peut appeler l’API arbitraire (je l’appelle Canvas puisque nous serons hypoth\u00e9tiquement quelque chose) en utilisant son URL et transmet la cl\u00e9 API dans le cadre de la cha\u00eene de requ\u00eate.<\/p>\n Par ici:<\/p>\n Bien s\u00fbr, il existe d’autres fa\u00e7ons de conserver ces valeurs (encore une fois en utilisant functions.php<\/strong> ou quelque chose de similaire).<\/p>\n Mais si vous travaillez avec de la programmation orient\u00e9e objet et que vous voulez travailler avec des valeurs immuables dans un plugin WordPress, n’aurait-il pas de sens de le garder dans le contexte des classes qui composent le 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