Na semana passada, fiz minha apresentação no WordCamp Atlanta sobre Namespaces e Autoloading. (o título completo era Namespaces, Autoloading, and Improving Plugin Architecture, mas isso é um bocado, não é?)

Devido à natureza da palestra, optei por escrever uma postagem para acompanhar a postagem, compartilhar os slides e compartilhar um exemplo de plug-in GitHub para ajudar a apoiar a palestra.

Então se você esteve presente, obrigado(!) e aqui está o post, prometi. E para aqueles que não compareceram, espero que este post ainda ajude a demonstrar os conceitos e tópicos que discuti no WordCamp.

Namespaces e carregamento automático

Antes de falar sobre namespaces e carregamento automático no WordPress, a razão pela qual quero falar sobre isso é porque isso pode afetar diretamente a qualidade do seu código e pode fazê-lo por meses e anos.

Afinal, muitos de nós desenvolvedores já não fazem a pergunta:

Como podemos tornar nosso código melhor do que já é?

E muitos de nós são inteligentes o suficiente para saber o que não sabemos. Portanto, temos que trabalhar dentro das restrições que nos são dadas.

Às vezes temos tempo para investigar maneiras de fazer isso; outras vezes, trabalhamos com o conhecimento que temos. E não há nada de errado com isso.

Mas porque sabemos o que não sabemos, sabemos que há potencial para mais.

Primeiro, seu código

Quando se trata de falar sobre tópicos como namespaces e carregamento automático no contexto do WordPress, acho que muitas vezes recebemos respostas mistas.

Afinal, poderíamos estar falando sobre coisas como o Theme Customizer ou a API REST ou algo mais divertido.

Quero dizer, "namespaces e autoloading" simplesmente não soam empolgantes ou avançados quando comparados aos recursos e tecnologias mais recentes disponíveis, certo?

Mas não, eles não são realmente chatos. E através deste post e da apresentação que o acompanha e do código-fonte, vou mostrar por que e como eles não são.

Eles não são chatos

Acho justo dizer que os desenvolvedores – pelo menos uma parte de nós ou uma parte deles dependendo de como você se vê – são notórios por discutir sobre aspectos da programação.

“Conversa chata de qualquer maneira."

Na verdade, não é incomum ouvir alguém discutindo sobre a melhor maneira de inicializar e escrever um loop for com o melhor desempenho possível ao iterar em um pequeno conjunto de banco de dados, apesar do fato de termos processadores quad-core e 16 GB de RAM em nossas máquinas desktop.

Então, se nos importamos tanto com algo tão pequeno, certamente nos importamos com o quadro maior. Coisas como:

Código aprimorado
Melhor organização
Maior capacidade de manutenção
Depuração mais fácil
Ganhar mais dinheiro (bem, talvez).

E namespaces e carregamento automático podem levar diretamente a todos os itens acima (bem, não posso falar sobre dinheiro, mas tem potencial).

Se eu fosse resumir os namespaces de função e o local de carregamento automático em todos os itens acima, diria que:

Namespaces e carregamento automático levam a código aprimorado por meio de melhor organização, compartimentação ou modularização e relacionamento mais estreito por meio de seus conceitos.

Além disso, isso aumenta a capacidade de manutenção porque o código é organizado em pacotes que podem facilitar a depuração à medida que o produto cresce.

Tudo isso pode gerar economia de tempo ou melhor aproveitamento do tempo, o que, dependendo do seu modelo de negócio, pode impactar no resultado final.

Mas isso ainda não descreve nenhuma dessas coisas. Mas certamente, neste ponto, eles soam mais interessantes do que quando foram introduzidos pela primeira vez.

Então, o que eles são?

Antes de entrar nas definições de cada um e os papéis que eles desempenham, vamos dar uma olhada em como a falta de namespaces e carregamento automático no WordPress impactou negativamente sua experiência ao usar temas, plugins, complementos ou qualquer outra coisa que você tenha.

Então vamos voltar por um momento e olhar para cada um individualmente.

Namespaces

Imagine que você herdou um projeto e está prestes a começar a trabalhar nele. Digamos que seja um plugin do WordPress.

Você o instala; você vai ativá-lo e então você recebe pelo menos um destes:

Talvez você veja aquela mensagem desagradável de organização na parte superior da janela do navegador exibindo um rastreamento de pilha.
Talvez você veja uma mensagem falando sobre algum conflito com outro pacote existente.
Ou talvez quando você tenta ativar um plug-in, a página é atualizada, mas o plug-in não é ativado.
Talvez você tenha feito uma auditoria de código e veja as verificações de class_exists em toda a base de código.

Qualquer um ou todos os itens acima podem contribuir para problemas, é claro, com projetos do WordPress. Mas os namespaces podem realmente corrigir muito disso na maioria das vezes.

Ou seja, a razão pela qual você está enfrentando esses problemas é que o código com o qual você está trabalhando faz parte do namespace global (versus seu namespace) e o PHP não gosta quando há classes e módulos com o mesmo nome .

Mas quando você nomeia algo, você dá a ele sua área relativa a si mesmo que ainda funcionará bem com outros componentes, mesmo que eles tenham o mesmo nome de classe.

Carregadores automáticos

No que diz respeito aos carregadores automáticos, eles são um pouco menos complicados em alguns aspectos. Primeiro, pense no código que você escreve ou no código com o qual trabalha – especialmente no contexto dos plugins do WordPress – e depois pense em quantas vezes você escreve ou vê o seguinte:

incluir
incluir_uma vez
exigir
requer uma vez

E às vezes você os vê no topo do arquivo que inicia o plugin, e às vezes você os vê espalhados por toda a base de código.

Se eles estiverem todos contidos em um único arquivo, isso não é tão ruim, porque pelo menos você sabe onde eles estão. Mas se eles estão espalhados por todo o lugar, você não tem ideia de onde uma dependência está sendo trazida para o sistema.

O carregamento automático pode resolver tudo isso carregando as dependências quando necessário (e para quem estiver interessado, o carregamento automático é mais rápido que a inclusão manual).

Namespaces

Com tudo isso dito, estamos prontos para falar sobre namespaces e carregamento automático. Mas os namespaces são o conceito fundamental, então vamos começar por aí.

Mas depois de todos os itens acima, você pode ver as vantagens de usá-los. Talvez eles sejam até divertidos, certo? Pode ser?

Independentemente disso, precisamos de uma definição com a qual possamos trabalhar ao falar sobre isso pelo resto do artigo.

O manual do PHP fornece a seguinte definição :

Os namespaces são projetados para resolver dois problemas que os autores de bibliotecas e aplicativos encontram ao criar elementos de código reutilizáveis, como classes ou funções…

E isso não é ruim, mas é bem longo, técnico e pode ser um pouco demais para quem está começando. Então vamos simplificar um pouco para este artigo:

Um pouco melhor, talvez?

Uma maneira de agrupar classes e interfaces relacionadas com uma finalidade semelhante.

Não vou falar sobre interfaces nesta palestra; no entanto, eu sei que existem desenvolvedores orientados a objetos de nível intermediário que os usam, então eu queria ter certeza de pelo menos mencioná-los.

Um exemplo prático

Eu não gosto de exemplos de programação que não dão aplicações práticas ou do mundo real. Muitas vezes, recebemos exemplos de coisas que nunca codificaríamos.

Quantas vezes você leu um artigo orientado a objetos e ele dá um exemplo de uma classe animal ou uma classe de carro? Não vamos programar um carro.

É muito mais provável que estejamos trabalhando com arquivos. Então, vamos dar uma olhada em um conjunto de classes responsáveis por ler e escrever arquivos. Ou seja, temos sido bons programadores orientados a objetos e separamos nossas classes com base nas responsabilidades que elas mantêm.

E sim, você pode ter interfaces; no entanto, eles estão além do escopo deste artigo, portanto, não serão incluídos.

Então, para o nosso FileReader, talvez o básico da classe seja assim:

Uma classe para ler arquivos.

Observe que a função aceita o nome do arquivo que deve ser aberto para leitura. A verificação de erros, como ele lê o arquivo e o que ele retorna são deixados para a implementação da classe.

E para o FileWriter, temos algo assim:

Uma classe para escrever arquivos.

Essa classe, por outro lado, aceita a informação que vai gravar no disco e o nome do arquivo no qual deve ser gravada.

Novamente, como no exemplo acima, ele não inclui verificação de erros, gravação por meio de um recurso, fechamento dos recursos e assim por diante.

Mas não se trata de trabalhar com arquivos. Em vez disso, trata-se de mostrar como criar um namespace em seu código, e esses dois exemplos devem ser fundamentais para isso.

Notas sobre namespaces

Há uma ressalva para o que você vê nas imagens do código de exemplo acima: Essas classes não têm namespace. Ou seja, eles estão residindo no namespace global, o que os deixa prontos para conflitos com outras classes.

Veja da seguinte forma: imagine que você empacota esse código em um plugin para outra pessoa, e então eles carregam outro plugin que também tem como FileReader ou FileWriter. Como tudo fará parte do mesmo namespace global, você enfrentará um conflito.

Lembrar:

Os namespaces são uma maneira de agrupar classes e interfaces relacionadas com uma finalidade semelhante.

Então vamos pegar as classes e o namespace do código.

Primeiro, forneceremos um namespace de nível superior no qual essas classes e todas as outras classes residirão; em seguida, forneceremos um subpacote (ou sub-namespace ou subespaço como os ouvi serem chamados) no qual essas classes de arquivo residirão.

Isso significa que nosso FileReader agora ficará assim:

Uma classe com namespace para leitura de arquivos.

E nosso FileWriter agora ficará assim:

Uma classe com namespace para gravar arquivos.

Primeiro, você pode ver que usar namespaces é fácil: você simplesmente usa a palavra-chave namespace e então declara o namespace (que poderia facilmente ser WCATL) no topo com os subpacotes a seguir.

Mas isso leva a outros tópicos – principalmente sobre organização de arquivos, instanciação e carregamento automático – todos os quais valem a pena serem abordados.

Na organização do arquivo

Neste ponto, é importante ter uma palavra sobre organização de arquivos. Dependendo de com quem você fala, você vai descobrir que alguns desenvolvedores – surpresa, surpresa – têm uma opinião sobre como os arquivos devem ser organizados (e eu não sou diferente).

Por um lado, você não precisa organizar seus arquivos. Na verdade, você pode colocar tudo no diretório raiz do seu projeto, colocar as informações no namespace e estar pronto para começar.

Arquivos não organizados

O conjunto de arquivos acima é para um projeto pequeno, então você pode imaginar quantos arquivos existiriam para um projeto grande.

Mas quando você tem seus arquivos organizados assim, pode tornar um pouco difícil escrever um autoloader porque um autoloader precisa saber onde encontrar os arquivos com base em seu namespace.

É aqui que entram em jogo os termos “organização lógica” e “organização virtual”.

Organização lógica refere-se a como os arquivos são organizados no disco, como o que você vê acima. Eles estão localizados logicamente no diretório raiz.
Organização Virtual refere-se a como os arquivos são organizados em relação aos seus namespaces. Isso significa que existem diretórios e subdiretórios que são mapeados para namespaces, subpacotes e assim por diante.

Então, se você pegasse o projeto acima, seus namespaces, seus subpacotes e os organizasse lógica e virtualmente, seria algo assim:

Namespaces e carregamento automático: arquivos organizados

E embora você possa optar por organizar seus arquivos como quiser, sou fã de garantir que haja paridade entre os dois. Ou seja, gosto que minha organização lógica e virtual combinem como você vê na imagem acima.

À medida que passo a discutir o carregamento automático, você verá por que isso é importante.

Notas sobre namespaces

O que acontece, porém, quando precisamos instanciar classes com namespace? Quando as classes não têm namespace, é fácil usar a palavra-chave ‘new’.

Instanciação sem um namespace.

Mas temos que instanciar uma classe com namespace, temos que dar um passo adiante e usar o nome totalmente qualificado:

Namespaces e Autoloading: Instanciação com um namespace.

Mas isso fica complicado, não é? Este exemplo em particular não é tão ruim, mas imagine se você estivesse trabalhando em algo com mais subpacotes. Ficaria bem trabalhoso, não é?

Para esse fim, podemos usar o que é chamado de aliasing. É simples também. Podemos definir use a palavra-chave ‘use’ no topo do arquivo para fazer referência ao namespace que queremos como alias e então usar o último subpacote como parte do alias para instanciar nossa classe.

Parece confuso, não é? Talvez vê-lo em ação ajude:

Alias de namespaces.

E isso é tudo o que há para isso. Sim, você pode levar o alias um passo adiante, mas isso é o que estou levando no contexto deste artigo.

Carregamento automático

Neste ponto, temos a base para o carregamento automático. Sim, trabalhar com namespaces pode ser muito trabalhoso se você não estiver acostumado; no entanto, é importante entender porque o carregamento automático requer um pouco de trabalho que pode ser inesperado se você nunca foi apresentado a ele antes.

Independentemente disso, as coisas mais importantes a serem lembradas sobre namespaces, neste momento, são:

Os namespaces são uma maneira de agrupar classes e interfaces relacionadas com uma finalidade semelhante.
Crie paridade por meio de seus arquivos e namespaces, garantindo que sua organização lógica e virtual seja a mesma.

E agora é hora de olhar para o carregamento automático.

Notas sobre carregamento automático

Primeiro, vamos ver a definição de autoload conforme fornecida pelo manual do PHP :

A função spl_autoload_register() registra qualquer número de autoloaders, permitindo que classes e interfaces sejam carregadas automaticamente se não estiverem definidas no momento. Ao registrar autoloaders, o PHP recebe uma última chance de carregar a classe ou interface antes que falhe com um erro.

Não é ruim. É longo, no entanto. Assim como fizemos com namespaces, vamos usar uma definição mais curta para este artigo:

Uma maneira de carregar automaticamente interfaces e classes sem usar instruções include e require.

Novamente, não usaremos interfaces neste artigo, embora alguns desenvolvedores o façam. E isso fornecerá a definição de trabalho para o restante deste artigo.

Um exemplo prático

Depois de ter seus arquivos organizados, com namespaces e prontos para carregar, é hora de fazer exatamente isso, certo? Quero dizer:

seus arquivos estão organizados,
você está pronto para carregá-los

Então é hora de fazer isso automaticamente, certo? Mas há um problema. Todo o “carregamento automático” de arquivos requer um pouco de trabalho.

Escrevendo um Autoloader

Ou seja, é automático, mas ainda exige um pouco mais de trabalho da nossa parte. Antes de entrar nessas etapas, é importante observar:

não é totalmente automatizado,
temos que escrevê-lo.

Por mais legal que fosse ter o código carregado automaticamente, temos que ler alguns dados, analisá-los e tentar carregar o arquivo apropriado.

Mas supondo que você o escreva corretamente e seu namespace e organize seus arquivos da mesma maneira para cada projeto, você pode reutilizar seu autoloader. Ou seja, você escreve uma vez e pode usá-lo em outros projetos.

Etapas para um carregador automático

Ao escrever um autoloader, há apenas alguns passos a seguir. O autoloader deve ser capaz de responder aos seguintes arquivos:

Onde estão os arquivos?
Como eles são nomeados?
O arquivo existe?

Se todos os itens acima forem verdadeiros (ou você puder responder “sim” a todos eles), o autoloader fará o que deve fazer.

Daremos uma olhada em algum código em um momento, mas a primeira coisa a notar é que ele usa uma função chamada spl_autoload_register.

SPL refere-se à Biblioteca PHP Padrão, e a função aceita uma função como argumento, e essa função aceita o nome da classe que será instanciada. É mais procedimental do que orientado a objetos, e falarei sobre isso brevemente, mas é importante ter em mente enquanto você lê este código.

Aqui está a primeira parte do código. Vou explicar o que está fazendo depois do fato:

Autoloading, Parte 1 – Encontrando a classe

Nesta parte do código, a função recebe o nome totalmente qualificado da classe a ser instanciada (como “WCATLFileFileReader()”).

Em seguida, ele separa todas as partes do nome totalmente qualificado em partes. O nome da classe é o último índice do array, e opto por nomear meus arquivos como “class-filereader.php” para que a função crie uma variável, $class_file, que se refira ao nome do arquivo.

Mas ainda não terminamos. Ainda temos que obter o nome totalmente qualificado (ou seja, onde o arquivo está localizado no disco). Isso pode ser algo assim:

Autoloading, Parte 2 – Obtendo o nome totalmente qualificado

Neste ponto, preparamos uma variável, $full_qualified_path, que fará referência ao diretório de nível superior.

Em seguida, o código percorre todos os índices do array e cria um caminho para o arquivo de classe. Você pode imaginar isso como construir uma string como “wcatlfile” que combinamos com o $class_file.

Isso significa que o caminho totalmente qualificado para o arquivo se torna “wcatlfileclass-filereader.php”.

E, finalmente, incluímos o arquivo. Observe que esse código não está verificando se o arquivo existe. Embora eu recomende, ele foi deixado de fora por causa do tamanho e porque, em nosso exemplo, sabemos que o arquivo existe.

Se o arquivo não existir, existem várias opções:

Lança uma exceção,
Pegar uma exceção,
Exibir uma mensagem de erro de sua preferência,
Ou alguma outra opção que eu possa estar considerando neste artigo.

Independentemente disso, a ideia é ser defensivo em seu código para que você possa se preparar para o caso de um arquivo não existir e poder lidar com a falha normalmente.

No carregamento automático

Antes de concluir, é importante observar o seguinte:

Ao longo do exemplo, usamos código orientado a objetos ao colocar o namespace no código. Afinal, é um conceito orientado a objetos.
Nosso autoloader é escrito em código procedural. O que da?

Em última análise, isso tem a ver com a Biblioteca PHP Padrão. Você pode escrever um autoloader orientado a objetos, mas acho que é um pouco exagerado em muitos casos.

O processo de carregamento de um arquivo é um processo passo a passo, portanto, escrevê-lo de maneira processual é um ajuste natural.

Finalmente, outros podem optar por usar ferramentas como o Composer para trazer dependências. Essas são ótimas ferramentas, e há muitas vantagens em usar algo assim; no entanto, está além dos conceitos e tópicos deste artigo e é melhor deixar para uma palestra futura.

Recursos (e obrigado!)

Este foi um dos artigos mais longos que escrevi para o meu site.

Isso ocorre em parte porque é baseado em uma palestra para um WordCamp e também porque quero ter certeza de fornecer uma introdução e base sólidas onde você pode começar a incorporar namespaces e carregamento automático em seus plugins do WordPress.

Além deste artigo, também forneci os seguintes recursos:

Os slides da minha apresentação estão disponíveis no SpeakerDeck.
Tenho o código desta apresentação disponível para download no GitHub.

E com isso, espero que isso forneça uma introdução sólida para namepsaces e carregamento automático e que você possa começar a incorporar isso cada vez mais em seu trabalho. Isso beneficia muito seu trabalho e outros desenvolvedores que podem acabar usando seu trabalho também.

Fonte de gravação: tommcfarlin.com