Sur les valeurs immuables dans les plugins WordPress

Si vous avez fait des travaux – ou même des lectures – sur la programmation orientée objet, vous avez probablement rencontré l’idée d’immuabilité. C’est l’idée que quelque chose est immuable.

Parfois, vous pouvez avoir des valeurs immuables, et parfois vous pouvez avoir des objets immuables (au moins après leur instanciation).

Le contraire d’immuable (mais c’était ma tortue ninja préférée, de toute façon).

Le fait est que plus je travaille avec du code orienté objet, moins j’ai tendance à travailler avec des variables immuables. Bien sûr, j’utiliserai des constantes telles que définies 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.

Cela implique probablement quelque chose sur moi et mes capacités, mais c’est vrai. Heureusement, les révisions de code sont très utiles pour vous aider à voir les opportunités d’exploiter des stratégies que vous ne feriez pas normalement. Et c’est le cas des valeurs immuables dans les plugins WordPress.

Bien sûr, c’est l’une de ces choses qui a été portée à mon attention par un ami lors de la révision de mon code.

Lorsque vous travaillez avec WordPress, beaucoup d’entre nous connaissent probablement functions.php et wp-config.php et le rôle qu’ils jouent dans l’application principale de WordPress.

Oui, il y a des moments où des choses appartiennent à wp-config.php, et oui, il y a des moments où des choses appartiennent à functions.php, mais parfois je pense que ce fichier particulier est abusé avec beaucoup trop de fonctions, de valeurs, etc. .

Mais qu’en est-il des plugins? Plus précisément, qu’en est-il des plugins orientés objet ? Par exemple, supposons que vous travaillez avec une API qui nécessite une clé API, de sorte que vous ne vous heurtez pas à une limite de débit particulière avec une version gratuite de l’application.

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 être transmise, ou peut-être dans une classe de conteneur à laquelle je peux me référer et utiliser sa  méthode get.

Mais qu’en est-il de l’utilisation d’une  propriété const dans une classe, puis de la transmettre via une injection de setter ?

Par exemple, supposons qu’il existe une classe de plug-in qui s’appuie sur une classe d’assistance pour afficher quelque chose à l’écran. La clé API peut être définie dans cette classe puis passée dans le helper si besoin :

Ensuite, la classe d’assistance peut appeler l’API arbitraire (je l’appelle Canvas puisque nous serons hypothétiquement quelque chose) en utilisant son URL et transmet la clé API dans le cadre de la chaîne de requête.

Par ici:

• il y a un seul endroit où la valeur est conservée,
• il y a un nom descriptif indiquant ce qu’il stocke,
• il peut être passé à d’autres classes avec une dépendance minimale,
• les autres classes peuvent s’y référer en tant que variables locales ou en tant que variables d’instance (selon la manière dont elles sont transmises).

Bien sûr, il existe d’autres façons de conserver ces valeurs (encore une fois en utilisant functions.php ou quelque chose de similaire).

Mais si vous travaillez avec de la programmation orientée 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 ?