Запити до бази даних для швидкого оновлення даних, частина 2
Це друга і остання частина серії про прямі запити до бази даних, як випливає з назви. Зокрема, йдеться про зміну статусів дописів (але це стосується не лише цього).
Фото Росса Фіндона на Unsplash
Це ще одна публікація, яка буде ілюстрацією того, як використовувати $wpdb для швидкого оновлення інформації на основі метаданих.
І код, наданий у цій публікації, працює, але якщо ви хочете зробити його більш об’єктно-орієнтованим, тоді є ще багато роботи, яку можна зробити.
Однак перед тим, як перейти до фактичної публікації, важливо зазначити, що коли мова йде про об’єктно-орієнтоване програмування, існує багато роботи, яка може піти на дизайн класу та створення рівнів абстракції.
У якийсь момент вам доведеться провести межу між тим, коли ви збираєтеся використовувати інтерфейси, наскільки детальними будуть ваші класи з точки зору того, що вони абстрагують, тощо.
Метою цієї публікації є надання кращого об’єктно-орієнтованого дизайну, але це не вправа зробити це максимально оптимальним. Я обговорюю подібні теми в іншій серії публікацій.
Але майте це на увазі, читаючи код у решті публікації.
Запити до бази даних для швидкого оновлення даних, частина 2
З огляду на те, де ми зупинилися, у нас є одна функція, яка виконує наступні речі:
- отримати всі публікації, пов’язані з певним мета-ключем,
- визначити, чи потрібно нам вийти раніше,
- оновити статус публікації будь-яких існуючих публікацій.
Перше, що слід зазначити, це те, що одна функція занадто багато, тому її потрібно розбити на кілька інших функцій. А оскільки вона об’єктно-орієнтована, нам потрібно переконатися, що будь-яка функція, яку виконує, не обов’язково залежить від попередніх кроків – це саме те, що стосується процедурного програмування.
Натомість ми скористаємося цією можливістю, щоб налаштувати функції, щоб вони працювали з будь-якими даними, які їм передаються, незалежно від того, як вони туди потрапили.
Нарешті, ви, як розробник, вирішуєте, чи хочете ви мати для цього один клас, більше одного класу чи набір пов’язаних класів, які успадковуються від батьківського класу.
Знову ж таки, все залежить від того, наскільки абстрактним ви хочете зробити код.
Але поки що давайте рухатися далі, розбиваючи речі.
1 Візьміть ідентифікатори публікацій із пов’язаним мета-ключем
Так само, як і в першій публікації, ми хочемо переконатися, що отримуємо ідентифікатори публікацій, пов’язані з певним метаключем.
Щоб зробити цю функцію максимально гнучкою, ми налаштуємо її на:
- приймати мета-ключ як рядок,
- повернути масив
Тоді функція виглядатиме приблизно так:
У першому дописі ми розбили це на три кроки (які також описано вище). Однак тут ми можемо об’єднати другий і третій крок в одну функцію.
2 Оновіть статус публікації
Як я вже згадував, один аспект об’єктно-орієнтованого програмування полягає в тому, щоб переконатися, що функції, які ми використовуємо, не залежать від того, як були згенеровані дані, які вони отримують.
Натомість у них є єдиний алгоритм для запуску, щоб зосередитися на даних, які передаються у функцію. У цьому випадку ми хочемо взяти набір результатів, які є ідентифікаторами дописів, і оновити їхній статус допису, щоб він був налаштований на чернетку.
Це означає, що функція прийматиме масив, але нічого не повертатиме. Потенційно, ви могли б надати йому відстеження багатьох публікацій, які він оновив (або якщо він взагалі щось оновив), але я зосереджений лише на рефакторингу коду, який у нас уже є.
Ось що ми збираємося зробити. І по-перше, переконайтеся, що є фактичні дані, з якими можна працювати. Якщо так, то перегляньте масив списку ідентифікаторів публікацій і змініть їхній статус публікації:
Ви бачите, що це мало чим відрізняється від роботи, виконаної в першому дописі, але зараз це викликає кілька запитань.
3 Об’єктно-орієнтовані міркування
При роботі з таким кодом:
- Це все належить до одного класу чи до окремих класів?
- Чи має бути базовий клас і, якщо так, то чому чи ні?
- Чи має бути викликана єдина публічна функція, яка викликає ці методи (і позначає їх як приватні)?
- Чи повинні ми залишити функції відкритими?
Для цієї публікації я збираюся зробити наступне:
- Розкрийте кожну функцію як публічний метод. Це робиться для того, щоб, якщо є дані, повернуті з першого методу, ви потенційно могли зробити з ними щось інше.
- Тримайте його в одному класі. Таким чином ми можемо створити екземпляр одного класу, а потім використовувати його для виконання будь-якої роботи, яка нам потрібна. Якби були інші методи, ми б використовували ті самі методи.
- Почніть з інтерфейсу. Я не збираюся турбуватися про написання інтерфейсу, щоб просто показати інтерфейс (я припускаю, що це досить легко вивести, враховуючи функції, які ми маємо зараз), але я збираюся взяти участь у класі та показати, як ми можемо викликати функціонує «ззовні всередину».
Тож я почну з останнього пункту й працюватиму назад. Ось один із способів роботи з кодом:
І ось як виглядає весь клас :
Загалом, це буде служити тим самим цілям, що й перший, але більш об’єктно-орієнтованим способом.
Це не той шлях
Як я намагався повторити кілька разів у цій публікації, це не остаточний спосіб виконати цю роботу. Натомість це один із способів виконання роботи.
Ви можете змінити дизайн, змінити фактор або повторно використовувати це, як вважаєте за потрібне. Мета, однак, полягає в тому, щоб показати, як відокремити логіку, яку ми зазвичай сприймаємо як процедурну, у щось, що трохи менше залежить від самого себе та залишає місце для додаткової роботи.