Si ha realizado alg\u00fan trabajo, o incluso alguna lectura, sobre la programaci\u00f3n orientada a objetos, es probable que se haya topado con la idea de la inmutabilidad. Esa es la idea de que algo no cambia.<\/p>\n
A veces puede tener valores inmutables y, a veces, puede tener objetos inmutables (al menos despu\u00e9s de que se instancian).<\/p>\n
Lo opuesto a inmutable (pero \u00e9l era mi tortuga ninja favorita, de todos modos).<\/p>\n
La cuesti\u00f3n es que cuanto m\u00e1s trabajo con c\u00f3digo orientado a objetos, menos tiendo a trabajar con variables inmutables. Claro, usar\u00e9 constantes como se definen en un archivo de configuraci\u00f3n, pero no es probable que me encuentres almacenando valores dentro de una clase como const<\/a>.<\/p>\n Eso probablemente implica algo sobre m\u00ed y mis habilidades, pero es verdad. Afortunadamente, las revisiones de c\u00f3digo<\/a> son excelentes para ayudarlo a ver oportunidades sobre d\u00f3nde aprovechar estrategias que normalmente no har\u00eda. Y tal es el caso de los valores inmutables en los complementos de WordPress.<\/p>\n Por supuesto, esta es una de esas cosas que un amigo<\/a> me llam\u00f3 la atenci\u00f3n al revisar mi c\u00f3digo.<\/p>\n Cuando trabajamos con WordPress, es probable que muchos de nosotros estemos familiarizados con functions.php<\/strong> y wp-config.php<\/strong> y el papel que desempe\u00f1an en la aplicaci\u00f3n principal de WordPress.<\/p>\n S\u00ed, hay momentos en los que las cosas pertenecen a wp-config.php<\/strong>, y s\u00ed, hay momentos en los que las cosas pertenecen a functions.php<\/strong>, pero a veces creo que se abusa de ese archivo en particular con demasiadas funciones, valores, etc. .<\/p>\n Pero, \u00bfqu\u00e9 pasa con los complementos? Espec\u00edficamente, \u00bfqu\u00e9 pasa con los complementos orientados a objetos? Por ejemplo, supongamos que est\u00e1 trabajando con una API que requiere una clave de API, por lo que no se encuentra con un l\u00edmite de velocidad particular con una versi\u00f3n gratuita de la aplicaci\u00f3n.<\/p>\n Por lo general, es posible que me encuentre almacenando el valor en la clase de complemento principal como una variable de instancia que se puede pasar, o tal vez est\u00e9 en una clase de contenedor a la que puedo referirme y usar su m\u00e9todo de obtenci\u00f3n .<\/strong><\/p>\n Pero, \u00bfqu\u00e9 pasa con el uso de una\u00a0 propiedad const<\/a> en una clase y luego pasarla a trav\u00e9s de una inyecci\u00f3n de setter?<\/p>\n Por ejemplo, supongamos que hay una clase de complemento que se basa en una clase auxiliar para representar algo en la pantalla. La clave API se puede definir en esta clase y luego pasar al asistente cuando sea necesario<\/a> :<\/p>\n A continuaci\u00f3n, la clase de ayuda puede realizar una llamada a la API arbitraria (lo llamo Canvas ya que hipot\u00e9ticamente seremos algo) utilizando su URL y pasa la clave API como parte de la cadena de consulta.<\/p>\n De esta manera:<\/p>\n Claro, hay otras formas en las que se pueden mantener estos valores (nuevamente con el uso de functions.php<\/strong> o algo similar).<\/p>\n Pero si est\u00e1 trabajando con programaci\u00f3n orientada a objetos y desea trabajar con valores inmutables en un complemento de WordPress, \u00bfno tendr\u00eda sentido mantenerlo en el contexto de las clases que componen el complemento?<\/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