Requêtes de base de données pour mettre à jour rapidement les données, partie 2

Ceci est la deuxième et dernière partie d’une série sur – comme le titre l’indique – les requêtes directes de base de données. Plus précisément, il s’agit de changer les statuts des publications (mais cela concerne plus que cela).

Photo de Ross Findon sur Unsplash

Du message précédent :

Ceci est encore un autre article qui va être une illustration de la façon d’utiliser $ wpdb pour mettre à jour rapidement les informations basées sur les métadonnées.

Et le code fourni dans cet article fonctionne, mais si vous cherchez à le rendre plus orienté objet, il y a plus de travail à faire.

Avant de passer au message proprement dit, cependant, il est important de noter qu’en matière de programmation orientée objet, il y a beaucoup de travail qui peut être consacré à la conception de la classe et à la création de niveaux d’abstraction.

À un moment donné, vous devez tracer la ligne proverbiale entre le moment où vous allez utiliser des interfaces, la granularité de vos classes en termes de ce qu’elles extraient, etc.

Et le but de cet article est d’aider à fournir une meilleure conception orientée objet, mais ce n’est pas un exercice qui rend cela aussi optimal que possible. Je discute de sujets comme celui-ci dans une autre série de messages.

Mais gardez cela à l’esprit lorsque vous lisez le code tout au long du reste du message.

Requêtes de base de données pour mettre à jour rapidement les données, partie 2

Étant donné où nous nous sommes arrêtés, nous avons une seule fonction faisant les choses suivantes :

1. récupérer tous les messages associés à une clé méta spécifique,
2. déterminer si nous devons sortir plus tôt,
3. mettre à jour le statut de publication de tous les messages existants.

La première chose à noter est qu’une seule fonction est trop, elle doit donc être divisée en plusieurs autres fonctions. Et puisqu’elle est orientée objet, nous devons nous assurer que tout ce qu’une fonction fait n’est pas nécessairement basé sur les étapes précédentes – c’est précisément ce qu’est la programmation procédurale.

Au lieu de cela, nous utiliserons cette opportunité pour configurer des fonctions, afin qu’elles fonctionnent sur toutes les données qui leur sont transmises, quelle que soit la manière dont elles y sont arrivées.

Enfin, c’est à vous, en tant que développeur, de déterminer si vous voulez avoir une seule classe pour faire cela, plus d’une classe, ou un ensemble de classes liées qui héritent d’une classe parent.

Encore une fois, tout dépend de la façon dont vous voulez rendre le code abstrait.

Pour l’instant, cependant, allons de l’avant avec la rupture des choses.

1 Saisissez les identifiants de publication avec la méta-clé associée

Tout comme dans le premier message, nous voulons nous assurer que nous récupérons les identifiants de publication liés à une clé méta spécifique.

Afin de rendre cette fonction aussi flexible que possible, nous allons la configurer pour :

• accepter la clé méta comme une chaîne,
• retourner un tableau

La fonction ressemblera alors à ceci :

Dans le premier article, nous avons divisé cela en trois étapes (qui sont également décrites ci-dessus). Ici, cependant, nous pouvons combiner la deuxième et la troisième étape en une seule fonction.

2 Mettre à jour le statut de la publication

Comme je l’ai mentionné, l’un des aspects de la programmation orientée objet est de s’assurer que les fonctions que nous utilisons sont indépendantes de la manière dont les données qu’elles reçoivent ont été générées.

Au lieu de cela, ils ont un seul algorithme à exécuter pour se concentrer sur les données transmises à la fonction. Dans ce cas, nous voulons prendre l’ensemble des résultats – qui sont des identifiants de publication – et mettre à jour leur statut de publication afin qu’il soit défini sur brouillon.

Cela signifie que la fonction acceptera un tableau mais ne renverra rien. Potentiellement, vous pourriez lui faire garder une trace de nombreux messages qu’il a mis à jour (ou s’il a mis à jour quoi que ce soit), mais je me concentre uniquement sur la refactorisation du code que nous avons déjà.

C’est donc ce que nous allons faire. Et la première chose est de s’assurer qu’il y a des données réelles avec lesquelles travailler. Et si c’est le cas, parcourez ensuite le tableau de liste des ID de publication et modifiez leur statut de publication :

Vous pouvez voir que ce n’est pas très différent du travail qui a été fait dans le premier post, mais cela soulève maintenant quelques questions.

3 considérations orientées objet

Lorsque vous travaillez avec un code comme celui-ci :

• Appartiennent-ils tous à la même classe ou à des classes distinctes ?
• Devrait-il y avoir une classe de base et, si oui, pourquoi ou pourquoi pas ?
• Devrait-il y avoir une seule fonction publique invoquée qui appelle ces méthodes (et les marque comme privées) ?
• Doit-on laisser les fonctions publiques ?

Pour ce post, je vais faire ce qui suit :

• Exposez chaque fonction en tant que méthode publique. C’est ainsi que si des données sont renvoyées par la première méthode, vous pouvez potentiellement en faire autre chose.
• Gardez-le contenu dans une seule classe. De cette façon, nous pouvons instancier une seule classe, puis l’utiliser pour effectuer tout le travail que nous devons faire. S’il y avait d’autres méthodes, nous utiliserions ces mêmes méthodes.
• Commencez par l’interface. Je ne vais pas m’embêter à écrire une interface dans le seul but de montrer une interface (je suppose que c’est assez facile à déduire étant donné les fonctions que nous avons en ce moment), mais je vais prendre la classe et montrer comment nous pouvons invoquer le fonctionne "de l’extérieur vers l’intérieur".

Je vais donc commencer par le dernier point et revenir en arrière. Voici une façon de travailler avec le code :

Et puis voici à quoi ressemble toute la classe :

D’une manière générale, cela servira les mêmes objectifs que le premier mais d’une manière plus orientée objet.

Ce n’est pas la voie

Comme j’ai essayé de le répéter plusieurs fois dans cet article, ce n’est pas la manière définitive de faire ce travail. Au lieu de cela, c’est une façon de travailler.

Vous pouvez reconcevoir, refactoriser ou réutiliser cela comme bon vous semble. Le but, cependant, est de montrer comment découpler la logique que nous considérons normalement comme procédurale en quelque chose qui est un peu moins dépendant d’elle-même et laisse de la place pour un travail supplémentaire.