Prototipagem Rápida com WordPress: Análise de Conceito

No post anterior, comecei a percorrer o processo de levar a ideia de um plugin que o prototipa rapidamente em algo que funcione dentro do WordPress. E, embora funcione, não segue necessariamente nenhum princípio orientado a objetos, nem está em um lugar em que podemos continuar adicionando recursos facilmente.

Não, isso não é um argumento para explicar por que a orientação a objetos é melhor. Acontece que é minha maneira preferida de escrever código, então estou abordando dessa maneira.

Eu sei que o código de exemplo que estou dando é simples e sei que pode ser feito um caso de que algo assim pode ser deixado como está. Mas o objetivo disso é mostrar como pegar um conceito, prototipá-lo e depois movê-lo para algo que siga os princípios orientados a objetos.

E, na minha experiência, é muito mais difícil fazer isso com um exemplo complexo desde o início. se você perde leitores desde o início, então que esperança há para eles entenderem o que está por vir?

Dito isso, vamos dar uma olhada no código do post anterior e fazer uma análise de conceito para ver o que pode funcionar bem dentro de uma classe e como podemos começar a organizá-lo usando classes, namespaces e assim por diante.

Análise de conceito

Sempre que se trata de programação, é tão fácil querer pular imediatamente para escrever código e, em seguida, enviá-lo até que ele faça algo que queremos.

E uma vez que funciona, parece que terminamos e podemos passar para a próxima tarefa. Mas para projetos maiores, isso nem sempre é o caso. Na verdade, muitas vezes é melhor fazer um pouco de análise de conceito de análise orientada a objetos em seu projeto antes de avançar.

Simplesmente pular para a codificação nem sempre é a melhor abordagem.

Um caso para análise

Caso em questão: no momento da redação deste artigo, um dos meus colegas de equipe e eu estamos discutindo se devemos estender uma classe ou escrever uma nova classe para lidar com informações de geolocalização para dados extraídos da API do Google Maps.

Posso improvisar e escrever algo que funcione? Claro. Mas será que se integrará bem com o aplicativo? Não sem análise de conceito, planejamento e coordenação com o resto do sistema.

E esse é o propósito da análise.

Analisando nosso trabalho

Então, o que isso significa para o plugin que vimos ontem? Neste momento, temos o seguinte:

• uma função responsável por criar uma meta box e exibir o conteúdo dentro dela,
• uma função para consultar o banco de dados e recuperar as últimas postagens mais recentes,
• uma função para exibir os resultados na caixa meta
• uma função para exibir uma mensagem quando não há resultados na meta box

Além disso, várias dessas funções estão relacionadas a ganchos que fazem parte da API do WordPress. Ou seja, a função para criar a meta box está ligada ao WordPress e sua função complementar para renderizar a exibição faz parte do mesmo componente.

Então temos a funcionalidade de consultar o banco de dados e temos funções diretamente relacionadas às visualizações.

Então, como isso ficaria se fôssemos diagramar isso em várias classes e arquivos que ajudariam a criar isso de uma maneira mais orientada a objetos?

Nenhuma solução única

Não existe uma solução única e algumas soluções são muito mais avançadas do que outras. Mas como estou tentando encontrar um equilíbrio aqui, vou abordar isso de uma maneira mais simples do que trabalhar muito com abstração, herança, interfaces e tudo mais.

Foco no que temos

Por enquanto, vamos nos concentrar nas classes individuais e nas responsabilidades que elas podem ter. Por exemplo:

• Acho que vamos precisar de uma classe que represente a caixa meta. Este deve ser responsável por criar a meta box.
• Também precisaremos de uma classe responsável por exibir o conteúdo da meta box. Você pode pensar que incluir uma função na classe para a meta box funciona bem. Ele faz; no entanto, se você quiser pensar em cada classe como tendo uma única responsabilidade, podemos criar uma classe especificamente para a exibição e especificamente para a caixa meta e injetar a exibição na caixa meta durante a instanciação. Falaremos mais sobre isso mais tarde.

Neste ponto, nosso diagrama pode ser algo assim:

Quebrando a caixa meta.

Em seguida, precisamos considerar a outra funcionalidade. Ou seja, a funcionalidade para exibir os resultados na caixa meta e a funcionalidade para exibir os resultados quando não houver nenhum.

Para exibir qualquer coisa na caixa meta, precisamos ter uma maneira de consultar o banco de dados para recuperar os resultados. A partir daí, precisamos ser capazes de determinar se há resultados, se não houver, e então injetar esses resultados na visualização.

Dadas essas informações, parece que precisamos de uma classe para consultar o banco de dados e, em seguida, precisamos de uma classe para ampliar uma mensagem na exibição da caixa meta.

Talvez uma maneira de organizar as aulas seria assim:

Consultando o banco de dados e preparando mensagens.

A versão final do diagrama pode ser um pouco apertada, mas estamos vendo algo assim:

A organização final para nossas aulas.

Para efeito de explicação:

• O post retriever pede ao banco de dados os últimos três posts mais recentes.
• O mensageiro posterior determinará qual mensagem injetar na tela.
• A tela renderizará a mensagem que foi definida.
• A meta box renderizará sua exibição no navegador da web.

Então, basicamente pegamos algumas funções que foram conectadas ao WordPress e as dividimos em componentes que podem se comunicar uns com os outros, cada um dos quais é relativamente fácil de trabalhar e não faz mais do que um único trabalho.

Convertendo em código

Agora que temos uma ideia de como podemos converter o conceito anterior em código, veremos como fazer isso nos próximos artigos.

Observe que como você opta por implementar seu código ou projetar suas classes pode ser um pouco diferente do que eu tenho acima e você pode ter sugestões de como organizar melhor o que está acima. Se for o caso, deixe um comentário.

Na próxima postagem, veremos como converter isso em código funcional e, depois disso, veremos como organizar isso em namespaces e organização de arquivos adequados.

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