✅ Notícias, temas e plug-ins da WEB e do WordPress. Aqui compartilhamos dicas e as melhores soluções para sites.

Prototipagem Rápida: Protótipo para Código, Parte 2

7

O post anterior demonstra muito trabalho em pegar algo que já foi um protótipo rápido e levar esse protótipo para o código. Se você não tem acompanhado, fizemos o seguinte:

  1. conversamos e construímos um protótipo para um plugin,
  2. diagramada uma abordagem orientada a objetos pode funcionar,
  3. e refatoramos nosso protótipo para código real.

Neste ponto, há mais algumas coisas que podemos fazer para melhorar nosso código. Ou seja, podemos introduzir o conceito de namespaces. Isso leva a organização um passo adiante e pode pagar dividendos para projetos maiores.

Então, aqui está uma olhada em como isso se desenrola em nosso projeto atual.

Protótipo para código: namespaces

Eu cobri namespaces em profundidade em posts anteriores. Se você não leu, eu recomendo. Depois volte e confira o restante do post.

Se você optar por pular o artigo, aqui está uma breve definição de um namespace :

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 a ideia geral é que organizemos nossas classes com base em uma relação lógica que elas têm umas com as outras.

Além disso, também organizamos os arquivos em diretórios que correspondem ao namespace. Isso não é algo que precisa ser feito, mas acho que ajuda ter as classes organizadas logicamente no disco da maneira como são organizadas virtualmente no namespace.

Dito isso, vamos organizar os arquivos.

Organizando os arquivos

Em vez de começar com o arquivo de plugin principal, vamos começar organizando nossos arquivos primeiro.

  • Os arquivos Meta Box e Meta Box Display residirão em um diretório chamado Display. Isso é completamente arbitrário, mas como é isso que esses arquivos fazem, parece fazer sentido que seja onde eles residam.
  • Também podemos colocar os arquivos message-description.php e no-post-list.php nesse diretório, mas vamos colocá-los em um subdiretório chamado Views. Você pode chamar isso de Templates ou Partials ou algo similar.
  • Em seguida, temos as classes responsáveis ​​por consultar o banco de dados e a classe responsável por coordenar as mensagens. Vamos colocar cada um deles em Utility. Existem outros lugares que eles podem ir, com certeza, mas lembre-se de que o objetivo é demonstrar como usar namespaces. Então, se você se sentir tão inclinado, sinta-se à vontade para ajustar seus arquivos para se adequar ao seu gosto.

Se você seguiu o que temos acima, você deve ter uma estrutura de diretórios parecida com esta:

Uma maneira de organizar seus arquivos.

Agora é hora de definir namespaces para cada uma das classes. Como organizamos todos eles em seus diretórios, será fácil especificar um namespace; no entanto, é importante reconhecer que precisaremos usar a  palavra-chave use quando estivermos usando classes localizadas em outros namespaces.

Vamos passar por cada um dos nossos arquivos começando com os arquivos em Utility. Primeiro, vamos começar com o Post Messenger :

Você notará que o namespace do arquivo aparece no cabeçalho junto com uma declaração para usar a  classe Post Query que criamos. Anexei o nome da classe ao final do namespace, para não precisar usá-lo em toda a base de código.

Observe que o construtor agora se parece com isso :

Eu adicionei um  argumento $plugin_dir porque precisamos usar isso para exibir os resultados da consulta corretamente. E como eles agora residem em uma área diferente do aplicativo, as funções se parecem com isso :

Em seguida, vamos ver a  classe Post Query. Nada mudou muito nesta classe, exceto que demos a ela um namespace e também atualizamos a consulta apenas para retirar três postagens (conforme este comentário ).

Observe no código que também pré-fixei WP_Query com uma barra porque faz parte do namespace global.

Vamos entrar no  diretório Display e dar uma olhada na classe Meta Box. Isso também recebeu um namespace e também está usando o nome totalmente qualificado da  classe Meta Box Display que veremos momentaneamente.

Observe que este construtor também aceita o diretório do plugin como um argumento e o passa para a  classe Meta Box Display também. Isto é para que as funções responsáveis ​​por exibir as mensagens possam ser encontradas corretamente em sua localização no  diretório Views.

Finalmente, vamos revisar a  classe Meta Box Display. Esta é uma classe simples que inclui o namespace e faz referência ao Post Messenger que analisamos acima.

Neste ponto, completamos o círculo através do plugin. Com uma exceção: o arquivo bootstrap. Adicionamos um namespace a ele e precisamos atualizar a maneira como é instanciado :

Ou seja, temos:

  • definiu o namespace,
  • referenciar a localização da  classe Meta Box ,
  • atualizou os caminhos para incluir onde encontrar os arquivos (o que pode ser feito com um carregador automático),
  • e atualizou a  chamada add_action.

Aqui está a coisa sobre a chamada de ação add: Como o WordPress precisa localizar essa função e a função reside em um namespace, o nome totalmente qualificado da função deve ser identificado para que o WordPress possa invocá-lo. Daí a necessidade de NAMESPACE no nome da função.

Agora estamos organizados (com uma exceção)

Como você pode ver, namespaces e diretórios que correspondem a eles adicionam muita organização a um projeto. É mais fácil de seguir, mais fácil de entender para onde as coisas vão (para arquivos existentes e novos). E dá menos sensação de acumular muitos arquivos em um único lugar.

Mesmo que uma classe seja um pouco monólito, ela ainda pode ser organizada de forma a facilitar a manutenção.

Com isso dito, ainda há algo que eu mudaria neste plugin: Passar o diretório do plugin assim não é algo que ajuda com baixa coesão e acopla mais firmemente as classes porque o arquivo bootstrap precisa passar um valor para uma classe que o passa para outra classe que o usa para carregar arquivos e assim por diante.

Então, existem maneiras de corrigir isso? Absolutamente. E talvez nós vamos dar uma olhada nisso no post final.

Até lá, lembre-se que a versão mais recente do plugin está disponível no branch master, marcado como 0.3.0, no GitHub.

Postagens da série

  1. Prototipagem Rápida com WordPress: Do Conceito ao Plugin
  2. Prototipagem Rápida com WordPress: Análise de Conceito
  3. Prototipagem Rápida: Protótipo para Código, Parte 1
  4. Prototipagem Rápida: Protótipo para Código, Parte 2
  5. Prototipagem Rápida: Apresentando o Autoloading

Fonte de gravação: tommcfarlin.com

Este site usa cookies para melhorar sua experiência. Presumiremos que você está ok com isso, mas você pode cancelar, se desejar. Aceitar Consulte Mais informação