Parte 4 – WordPress e Programação Orientada a Objetos: Um Exemplo WordPress – Design

Neste ponto, temos requisitos claramente definidos conforme descritos na Parte 3 desta série (confira aqui se você perdeu).

Agora é a hora de começar a pensar no design do nosso novo e melhorado plugin!

Gostaríamos de lembrá-lo de que esta etapa pode levar muito tempo quando você a testa em seus próprios projetos. Você provavelmente não vai acertar tudo na primeira vez também. É provável que você crie um design, comece a implementá-lo e, em seguida, perceba que precisa voltar e repensar sua abordagem.

Vale totalmente a pena o esforço, então leve o tempo que for necessário para fazer tudo certo. Um projeto bem estruturado tornará mais fácil mantê-lo e estendê-lo, e até mesmo reutilizar seu código em outros projetos, portanto, a longo prazo, é um bom uso do tempo.

A seguir, vamos nos concentrar em algumas partes-chave do plugin e discutir como chegamos ao nosso design.

Dissecando a página de configurações

Vamos dar uma olhada na página de administração do plugin.

Você notará que há um título (“Configurações de Limitar Tentativas de Login”), várias seções contendo alguns campos e um botão “Alterar Opções” na parte inferior da página.

Cada seção consiste em um título, como “Estatísticas”, e alguns campos.

Cada campo tem um título à esquerda e o restante de seu conteúdo à direita. Existem campos de texto, botões de rádio e checkboxes e, alguns deles, como “Total Lockouts”, apenas exibem informações e não podem ser modificados diretamente pelo usuário administrador.

Alguns campos também incluem uma descrição, como o campo “Conexão do Site”, mas não todos.

Com o exposto em mente, temos que dividi-lo em partes conceituais que mais tarde se tornarão classes.

A API de configurações do WordPress nos permite registrar páginas de configurações, seções nessas páginas e campos nas seções:

Páginas → Seções → Campos

Pensamos, por que não adicionar mais uma “camada”, os Elements, para tornar nosso plugin mais fácil de estender no futuro.

Páginas → Seções → Campos → Elementos

Portanto, Páginas e Seções são o que já explicamos acima, e os Campos conterão Elementos de qualquer tipo de conteúdo no lado direito.

Levando em consideração todos esses diferentes tipos de elementos, fomos com uma classe Element e várias classes, estendendo-a, para as caixas de seleção, botões de opção, números etc. que renderizarão saídas diferentes.

Também podemos precisar adicionar mais páginas e seções no futuro. Portanto, é provável que precisemos estender essas classes de seção e página de administração.

O mesmo vale para os campos. As classes para “Bloqueios totais”, “Bloqueios ativos” etc. estenderão a mesma classe (pai).

Aqui está um visual simplificado que demonstra essas relações:

É claro que nem todos os “componentes” estão incluídos no diagrama.

Uma estrutura como esta torna o plugin mais fácil de estender; podemos adicionar facilmente um campo, elemento ou seção se for necessário. Poderemos adicionar facilmente mais componentes – campos, elementos ou seções – criando novas classes filhas, sem precisar modificar as existentes.

Pensando e Abstraindo

Agora é um ótimo momento para começar a pensar sobre o que os vários componentes do nosso plugin fazem. Durante a fase de design, não precisamos entrar em muitos detalhes sobre como algo funciona.

Por exemplo, considere todos os elementos, tabelas, estatísticas e praticamente qualquer outra coisa que será exibida ao usuário. Eles podem ser componentes separados sem nada em comum, mas todos eventualmente renderizarão alguma saída. Portanto, algumas funcionalidades serão comuns para componentes que de outra forma são completamente não relacionados. Obviamente, isso também se estende ao restante de nossos componentes.

No visual acima, vemos como uma interface de interface do usuário é implementada por várias classes.

Preste atenção ao fato de que a interface UI é implementada pelas classes Statistics, Lockout Logs, Table e Element que são chamadas de classes pai . Não há necessidade de as classes Radio/Number/Checkbox Element implementarem a interface diretamente, pois elas herdam todas as interfaces de sua classe pai. No entanto, uma classe filha pode substituir um método de sua classe pai.

Como sabemos que nosso plugin vai lidar com configurações, podemos assumir com segurança que leremos e escreveremos seus valores. Ou seja, poder obter , definir e remover opções.

Todas essas ações serão agrupadas em uma classe. Provavelmente armazenaremos nossas opções no banco de dados do WordPress ou algo assim. Por enquanto, não precisamos nos preocupar com como ou onde vamos armazenar nossos dados.

Podemos manter a abstração de opções get/set/remove em nossas mentes, simplificando as coisas conceitualmente, e continuar projetando nosso plugin.

Arquivo de plug-in principal

Aqui, forneceremos algumas informações sobre o plugin ao WordPress através do comentário do cabeçalho e realizaremos algumas inicializações. Vamos organizar nosso código, envolvendo tudo em uma pequena classe.

Dependendo de como as classes do nosso plugin funcionarão juntas, a classe principal terá que instanciar a maioria delas. Até onde sabemos, isso incluirá classes relacionadas a opções, páginas de administração, novas tentativas e bloqueios.

Classes potenciais

Levamos algum tempo para tentar descobrir quais classes vamos precisar e acabamos com uma lista da seguinte forma:

• Novas tentativas
• Bloqueios
• Biscoitos
• Mensagens de erro
• Notificações por e-mail
• Avisos do administrador
• Botões
• Registros de bloqueio
• Bloqueios ativos/totais
• endereço de IP

Tenha em mente que não existe uma única maneira “correta” de estruturar seu plugin. Como acontece com a maioria das coisas no desenvolvimento de software, existem várias maneiras igualmente válidas de resolver um problema.

Na seção “Geral”, por exemplo, as relações entre nossas classes ficariam assim:

A seção "Estatísticas" será semelhante a esta:

Por fim, os “Logs de bloqueio” serão muito semelhantes às “Estatísticas”:

Conclusão

Até agora, definimos nossos requisitos e pensamos em um design para nosso novo e aprimorado plugin. Explicamos como criamos nossa estrutura e também fornecemos alguns diagramas simples mostrando como nossas classes serão relacionadas umas às outras.

Clique aqui para ler a Parte 5 em nossa Série de Programação Orientada a Objetos

Veja também

• WordPress e programação orientada a objetos – uma visão geral
• Parte 2 – WordPress e Programação Orientada a Objetos: Um Exemplo do Mundo Real
• Parte 3 – WordPress e Programação Orientada a Objetos: Α Exemplo WordPress – Definindo o Escopo