Se voc\u00ea fez algum trabalho \u2013 ou mesmo alguma leitura \u2013 sobre programa\u00e7\u00e3o orientada a objetos, provavelmente j\u00e1 se deparou com a ideia de imutabilidade. Essa \u00e9 a ideia de algo ser imut\u00e1vel.<\/p>\n
\u00c0s vezes, voc\u00ea pode ter valores imut\u00e1veis \u200b\u200be, \u00e0s vezes, objetos imut\u00e1veis \u200b\u200b(pelo menos depois de instanciados).<\/p>\n
O oposto de imut\u00e1vel (mas ele era minha tartaruga ninja favorita, de qualquer maneira).<\/p>\n
O problema \u00e9 que quanto mais trabalho com c\u00f3digo orientado a objetos, menos costumo trabalhar com vari\u00e1veis \u200b\u200bimut\u00e1veis. Claro, usarei constantes conforme definido em um arquivo de configura\u00e7\u00e3o, mas \u00e9 improv\u00e1vel que voc\u00ea me encontre armazenando valores em uma classe como const<\/a>.<\/p>\n Isso provavelmente implica algo sobre mim e minhas habilidades, mas \u00e9 verdade. Felizmente, as revis\u00f5es de c\u00f3digo<\/a> s\u00e3o \u00f3timas para ajud\u00e1-lo a ver oportunidades de onde aproveitar as estrat\u00e9gias que voc\u00ea normalmente n\u00e3o usaria. E esse \u00e9 o caso dos valores imut\u00e1veis \u200b\u200bnos plugins do WordPress.<\/p>\n Claro, esta \u00e9 uma daquelas coisas que me chamaram a aten\u00e7\u00e3o por um amigo<\/a> ao revisar meu c\u00f3digo.<\/p>\n Ao trabalhar com o WordPress, muitos de n\u00f3s provavelmente est\u00e3o familiarizados com functions.php<\/strong> e wp-config.php<\/strong> e o papel que eles desempenham no aplicativo principal do WordPress.<\/p>\n Sim, h\u00e1 momentos em que as coisas pertencem a wp-config.php<\/strong>, e sim, h\u00e1 momentos em que as coisas pertencem a functions.php<\/strong>, mas \u00e0s vezes acho que esse arquivo espec\u00edfico \u00e9 abusado com muitas fun\u00e7\u00f5es, valores e assim por diante .<\/p>\n Mas e os plugins? Especificamente, e os plugins orientados a objetos? Caso em quest\u00e3o, digamos que voc\u00ea esteja trabalhando com uma API que requer uma chave de API, para que voc\u00ea n\u00e3o atinja um limite de taxa espec\u00edfico com uma vers\u00e3o gratuita do aplicativo.<\/p>\n Normalmente, voc\u00ea pode me encontrar armazenando o valor na classe principal do plugin como uma vari\u00e1vel de inst\u00e2ncia que pode ser passada, ou talvez esteja em uma classe de cont\u00eainer \u00e0 qual eu possa me referir e usar seu\u00a0 m\u00e9todo get<\/strong>.<\/p>\n Mas que tal usar uma\u00a0 propriedade const<\/a> em uma classe e depois pass\u00e1-la via inje\u00e7\u00e3o de setter?<\/p>\n Por exemplo, digamos que h\u00e1 uma classe de plugin que depende de uma classe auxiliar para renderizar algo na tela. A chave da API pode ser definida nesta classe e ent\u00e3o passada para o auxiliar quando necess\u00e1rio<\/a> :<\/p>\n Em seguida, a classe auxiliar pode fazer uma chamada para a API arbitr\u00e1ria (estou chamando de Canvas, pois hipoteticamente seremos algo) usando sua URL e passa a chave da API como parte da string de consulta.<\/p>\n Deste jeito:<\/p>\n Claro, existem outras maneiras de manter esses valores (novamente usando functions.php<\/strong> ou algo semelhante).<\/p>\n Mas se voc\u00ea est\u00e1 trabalhando com programa\u00e7\u00e3o orientada a objetos e quer trabalhar com valores imut\u00e1veis \u200b\u200bem um plugin WordPress, n\u00e3o faria sentido mant\u00ea-lo no contexto das classes que comp\u00f5em o 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