Consultas de banco de dados para atualizar dados rapidamente, parte 2
Esta é a segunda e última parte de uma série sobre – como o título sugere – consultas diretas ao banco de dados. Especificamente, trata-se de alterar os status das postagens (mas é relevante para mais do que isso).
Foto de Ross Findon no Unsplash
Este é mais um post que será uma ilustração de como usar $wpdb para atualizar rapidamente informações com base em metadados.
E o código fornecido nessa postagem funciona, mas se você deseja torná-lo mais orientado a objetos, há mais trabalho a ser feito.
Antes de pular para o post real, porém, é importante observar que quando se trata de programação orientada a objetos, há muito trabalho que pode ser feito no design de classes e na criação de níveis de abstração.
Em algum ponto, você tem que traçar a linha proverbial entre quando você vai usar interfaces, quão granular suas classes vão ser em termos do que elas estão abstraindo e coisas do gênero.
E o objetivo deste post é ajudar a fornecer um design orientado a objetos melhor, mas não é um exercício fazer isso o melhor possível. Eu discuto tópicos como este em outra série de posts.
Mas tenha isso em mente ao ler o código ao longo do restante do post.
Consultas de banco de dados para atualizar dados rapidamente, parte 2
Dado onde paramos, temos uma única função fazendo as seguintes coisas:
- recuperar todas as postagens associadas a uma meta-chave específica,
- determinar se precisamos sair mais cedo,
- atualizar o status de postagem de quaisquer postagens existentes.
A primeira coisa a notar é que uma única função é demais, então ela precisa ser dividida em várias outras funções. E como é orientada a objetos, precisamos ter certeza de que tudo o que uma função está fazendo não é necessariamente baseado em etapas anteriores – é exatamente disso que trata a programação procedural.
Em vez disso, usaremos essa oportunidade para configurar funções, para que elas operem em qualquer dado que seja passado a elas, independentemente de como chegaram lá.
Finalmente, cabe a você, como desenvolvedor, determinar se deseja ter uma única classe para fazer isso, mais de uma classe ou ter um conjunto de classes relacionadas herdadas de uma classe pai.
Novamente, trata-se de quão abstrato você deseja tornar o código.
Por enquanto, porém, vamos avançar com a separação das coisas.
1 Pegue os IDs de postagem com a meta-chave associada
Assim como na primeira postagem, queremos ter certeza de que estamos recuperando IDs de postagem relacionados a uma meta-chave específica.
Para tornar essa função o mais flexível possível, vamos configurá-la para:
- aceite a meta-chave como uma string,
- retornar uma matriz
A função então ficará mais ou menos assim:
No primeiro post, dividimos isso em três etapas (que também são descritas acima). Aqui, porém, podemos combinar a segunda e a terceira etapa em uma única função.
2 Atualizar o status da postagem
Como mencionei, o único aspecto da programação orientada a objetos é garantir que as funções que estamos usando sejam agnósticas quanto à forma como os dados foram gerados e que estão recebendo.
Em vez disso, eles têm um único algoritmo a ser executado para se concentrar nos dados que são passados para a função. Nesse caso, queremos pegar o conjunto de resultados – que são IDs de postagem – e atualizar seu status de postagem para que seja definido como rascunho.
Isso significa que a função aceitará um array, mas não retornará nada. Potencialmente, você poderia manter o controle de muitas postagens atualizadas (ou se atualizou alguma coisa), mas estou focado em apenas refatorar o código que já temos.
Então é isso que vamos fazer. E a primeira coisa é certificar-se de que há dados reais com os quais trabalhar E, em caso afirmativo, itere através da matriz de lista de IDs de postagem e altere seu status de postagem:
Você pode ver que não é muito diferente do trabalho que foi feito no primeiro post, mas agora levanta algumas questões.
3 Considerações Orientadas a Objetos
Ao trabalhar com código como este:
- Todos pertencem à mesma classe ou classes separadas?
- Deve haver uma classe base e, em caso afirmativo, por que ou por que não?
- Deve haver uma única função pública invocada que chame esses métodos (e marque-os como privados)?
- Devemos deixar as funções públicas?
Para este post, vou fazer o seguinte:
- Exponha cada função como um método público. Isso é para que, se houver dados retornados do primeiro método, você possa fazer outra coisa com eles.
- Mantenha-o contido em uma única classe. Dessa forma, podemos instanciar uma única classe e usá-la para fazer qualquer trabalho que precisemos fazer. Se houvesse outros métodos, usaríamos esses mesmos métodos.
- Comece com a interface. Não vou me incomodar em escrever uma interface apenas para mostrar uma interface (suponho que seja fácil deduzir dadas as funções que temos agora), mas vou pegar a classe e mostrar como podemos invocar o funções “de fora para dentro".
Então eu vou começar com o último ponto e trabalhar para trás. Aqui está uma maneira de trabalhar com o código:
E então aqui está a aparência de toda a classe :
De um modo geral, isso servirá aos mesmos propósitos que o primeiro, mas de uma maneira mais orientada a objetos.
Esse não é o caminho
Como tentei reiterar várias vezes neste post, essa não é a maneira definitiva de fazer esse trabalho. Em vez disso, é uma maneira que o trabalho pode ser feito.
Você pode reprojetar, refatorar ou reutilizar isso da maneira que achar melhor. O objetivo, porém, é mostrar como desacoplar a lógica que normalmente vemos como procedural em algo que é um pouco menos dependente de si mesmo e deixa espaço para trabalho adicional.