Por que se preocupar com o carregamento automático no WordPress, parte 1
Uma das coisas mais fáceis que podemos fazer ao trabalhar em plugins do WordPress é descartar as instruções require_once ou include_once em todo o nosso código.
E porque não? É uma maneira fácil de trazer todos os arquivos ou dependências necessários para uma determinada classe, torná-la facilmente legível e não ter que se preocupar em criar arquivos de código enormes. Ou seja, isso nos ajuda a simplificar o que estamos escrevendo para que possamos fazer com que nossas classes [principalmente ou idealmente] façam o que estão fazendo bem.
Se você leu este site no ano passado, sabe que sou fã de carregamento automático e acho que qualquer pessoa que trabalha com PHP – independentemente de estar usando WordPress ou outra plataforma – deveria usar.
Mas isso levanta duas questões, especialmente se você está apenas começando:
- Por que se preocupar com o carregamento automático quando existem outras maneiras de lidar com as dependências de carregamento?
- Como o carregamento automático se compara às linguagens compiladas?
Então achei que valeria a pena responder isso nos próximos posts.
Por que se preocupar com o carregamento automático?
O curta é isso:
- require_once e include_once podem levar a códigos difíceis de depurar,
- é difícil rastrear o código.
Mas como assim?
1 A depuração é difícil
Ao escrever código, se alguma coisa é certa, é que haverá algo que não funcionará como pretendido. Está na natureza do que fazemos, certo?
Então, quando chega a hora de depurar código, todos nós temos nossas estratégias.
- alguns de nós optam por usar echo ou var_dump para rastrear código,
- use um plugin no WordPress,
- outros usam um depurador.
Embora este post não seja sobre como depurar, é o fato de que temos que depurar. Então, se sabemos que vamos ter que fazer isso, não deveríamos facilitar ao máximo para nós mesmos?
PHP é uma linguagem tipada dinamicamente, então há muitas coisas, em geral, que são cuidadas para nós sempre que estamos escrevendo o código. Ou seja, certas coisas são inferidas ou coagidas sempre que o código é executado.
Por exemplo, suponha que você esteja trabalhando com uma string e a esteja comparando com um número. O interpretador fará o que puder para adivinhar o que você está fazendo (você está procurando analisar a string para um inteiro ou vice-versa?) e depois trabalhar com isso.
Trabalhar apenas com variáveis pode ser um exercício de precisão porque queremos que nosso código seja lido como pretendemos. Por que deixar para o intérprete adivinhar o que queremos dizer? E se o intérprete tem que fazer um trabalho extra, os humanos certamente o fazem.
Para esse fim, se sabemos que bugs serão introduzidos e sabemos que existem maneiras de escrever um código mais limpo, por que não o fazemos?
2 O rastreamento é difícil (ou talvez mais difícil?)
Mas isso ainda não fornece uma razão pela qual devemos confiar em algo como um autoloader versus recursos internos da linguagem, não é?
Considere o seguinte: digamos que você esteja procurando em um arquivo tentando encontrar um bug e encontre uma função que tenha algum código, use include_once e, em seguida, use algum outro código.
Isso significa que você tem que ler o código, manter isso arquivado mentalmente, pular para outro arquivo, entender esse código e depois retornar ao arquivo original. E isso pressupõe que o segundo arquivo também não inclua ou exija outros arquivos.
É chamado de código de espaguete por um motivo.
Com isso dito, você pode ver a situação que isso apresenta quando você opta por aninhar esse código em todo o resto do seu programa. Resumindo, você aninhado a inclusão de dependências que inerentemente torna mais difícil rastrear onde algo pode estar errado.
Isso não quer dizer que o carregamento automático corrige isso automaticamente, mas quer dizer que não precisa ser assim. Em vez disso, você pode escrever código que instancia classes, chama métodos e, em seguida, executa código sem a necessidade de incluir nada manualmente.
Código mais legível e rastreável
Ao fazer isso, acho que isso nos força a escrever um código mais limpo, sem dúvida um código mais sustentável. Também torna mais fácil escrever código que podemos rastrear mais facilmente, e isso é mais fácil de alavancar com um depurador.
Ou seja, podemos definir pontos de interrupção em determinados lugares em nosso código, fazer com que o depurador nos leve automaticamente para a classe que está sendo invocada e volte para a função que a estava chamando.
Isso não significa que não possa ser feito de outra maneira, mas os benefícios superam em muito as alternativas. E, é claro, isso ainda deixa a questão de por que o carregamento automático (ou qualquer inclusão de arquivos de terceiros) é necessário.
Mas é isso que será abordado na segunda parte da série.
Outras leituras
Meu post sobre Namespaces e Autoloading no WordPress, assim como o Simple Autoloader for WordPress, são dois outros recursos que obviamente acho relacionados a este post em particular. Portanto, se você tiver tempo, verifique-os (e não hesite em abrir um problema ou uma solicitação de pull no projeto simples do autoloader).