To druga i ostatnia część z cyklu o – jak sugeruje tytuł – bezpośrednich zapytaniach do bazy danych. W szczególności chodzi o zmianę statusów postów (ale ma to znaczenie nie tylko).
Zdjęcie: Ross Findon na Unsplash
To kolejny post, który będzie ilustracją tego, jak używać $wpdb do szybkiego aktualizowania informacji na podstawie metadanych.
Kod podany w tym poście działa, ale jeśli chcesz uczynić go bardziej zorientowanym obiektowo, to jest więcej pracy do wykonania.
Zanim jednak przejdziemy do właściwego posta, należy zauważyć, że jeśli chodzi o programowanie obiektowe, jest dużo pracy, którą można poświęcić na projektowanie klas i tworzenie poziomów abstrakcji.
W pewnym momencie musisz narysować przysłowiową granicę między tym, kiedy zamierzasz używać interfejsów, a tym, jak szczegółowe będą twoje klasy pod względem tego, co abstrahują, i tym podobne.
Celem tego posta jest pomoc w zapewnieniu lepszego projektowania zorientowanego obiektowo, ale nie jest to ćwiczenie, aby uczynić go tak optymalnym, jak to tylko możliwe. Tematy takie jak ten omawiam w innej serii postów.
Ale miej to na uwadze, czytając kod w dalszej części postu.
Zapytania do bazy danych w celu szybkiej aktualizacji danych, część 2
Biorąc pod uwagę, gdzie skończyliśmy, mamy jedną funkcję wykonującą następujące czynności:
- pobrać wszystkie posty powiązane z określonym kluczem meta,
- określić, czy musimy wyjść wcześniej,
- aktualizować status postów istniejących postów.
Pierwszą rzeczą, na którą należy zwrócić uwagę, jest to, że pojedyncza funkcja to za dużo, więc należy ją podzielić na kilka innych funkcji. A ponieważ jest zorientowany obiektowo, musimy upewnić się, że to, co robi funkcja, niekoniecznie jest oparte na poprzednich krokach – na tym właśnie polega programowanie proceduralne.
Zamiast tego wykorzystamy tę okazję do skonfigurowania funkcji, aby działały na wszelkich przekazywanych im danych, niezależnie od tego, w jaki sposób się tam dostały.
Wreszcie, do Ciebie, jako dewelopera, należy określenie, czy chcesz mieć do tego jedną klasę, więcej niż jedną, czy też zestaw klas powiązanych, które dziedziczą po klasie nadrzędnej.
Ponownie, chodzi o to, jak abstrakcyjny chcesz zrobić kod.
Na razie jednak przejdźmy do przodu z rozbijaniem rzeczy.
1 Chwyć identyfikatory postów za pomocą powiązanego klucza meta
Podobnie jak w pierwszym poście, chcemy się upewnić, że pobieramy identyfikatory wpisów, które są powiązane z określonym kluczem meta.
Aby ta funkcja była jak najbardziej elastyczna, skonfigurujemy ją tak, aby:
- zaakceptuj meta klucz jako ciąg,
- zwróć tablicę
Funkcja będzie wtedy wyglądać mniej więcej tak:
W pierwszym poście podzieliliśmy to na trzy kroki (które również zostały opisane powyżej). Tutaj jednak możemy połączyć drugi i trzeci krok w jedną funkcję.
2 Zaktualizuj status postu
Jak wspomniałem, jednym aspektem programowania obiektowego jest upewnienie się, że funkcje, których używamy, są niezależne od sposobu generowania danych, które otrzymują.
Zamiast tego mają pojedynczy algorytm do uruchomienia, aby skupić się na danych przekazywanych do funkcji. W takim przypadku chcemy pobrać zestaw wyników — które są identyfikatorami postów — i zaktualizować ich status posta, tak aby był ustawiony na wersję roboczą.
Oznacza to, że funkcja zaakceptuje tablicę, ale niczego nie zwróci. Potencjalnie mógłbyś śledzić wiele postów, które zaktualizował (lub jeśli w ogóle coś zaktualizował), ale ja skupiam się tylko na refaktoryzacji kodu, który już mamy.
Więc to właśnie zamierzamy zrobić. Pierwszą rzeczą jest upewnienie się, że istnieją rzeczywiste dane, z którymi można pracować. A jeśli tak, to przeprowadź iterację listy identyfikatorów postów i zmień ich status postów:
Widać, że nie różni się to zbytnio od pracy wykonanej w pierwszym poście, ale teraz rodzi kilka pytań.
3 Rozważania zorientowane na obiekt
Podczas pracy z takim kodem:
- Czy to wszystko należy do tej samej klasy, czy do oddzielnych klas?
- Czy powinna istnieć klasa bazowa, a jeśli tak, to dlaczego lub dlaczego nie?
- Czy powinna być wywoływana pojedyncza funkcja publiczna, która wywołuje te metody (i oznacza je jako prywatne)?
- Czy powinniśmy pozostawić funkcje publiczne?
W tym poście zrobię co następuje:
- Ujawnij każdą funkcję jako metodę publiczną. Dzieje się tak, że jeśli istnieją dane zwrócone z pierwszej metody, możesz potencjalnie zrobić z nią coś innego.
- Trzymaj to w jednej klasie. W ten sposób możemy utworzyć instancję pojedynczej klasy, a następnie użyć jej do wykonania dowolnej pracy, którą musimy wykonać. Gdyby istniały inne metody, użylibyśmy tych samych metod.
- Zacznij od interfejsu. Nie zamierzam zawracać sobie głowy pisaniem interfejsu tylko po to, aby pokazać interfejs (zakładam, że łatwo to wydedukować, biorąc pod uwagę funkcje, które mamy w tej chwili), ale zamierzam wziąć klasę i pokazać, jak możemy wywołać funkcje „od zewnątrz do wewnątrz".
Więc zacznę od ostatniego punktu i będę pracował wstecz. Oto jeden ze sposobów pracy z kodem:
A oto jak wygląda cała klasa :
Ogólnie rzecz biorąc, będzie to służyło tym samym celom, co pierwsze, ale w sposób bardziej zorientowany obiektowo.
To nie jest droga
Jak wielokrotnie próbowałem powtórzyć w tym poście, nie jest to ostateczny sposób na wykonanie tej pracy. Zamiast tego jest to jeden ze sposobów wykonywania pracy.
Możesz ponownie zaprojektować, ponownie uwzględnić lub ponownie wykorzystać to, jak uznasz za stosowne. Celem jest jednak pokazanie, jak oddzielić logikę, którą zwykle postrzegamy jako proceduralną, w coś, co jest nieco mniej zależne od siebie i pozostawia miejsce na dodatkową pracę.