Singletons у WordPress, перегляд (час і місце?)
Перш ніж розпочати публікацію про використання синглтонів у WordPress (або, точніше, шаблону Singleton ), я хочу переконатися, що ви прочитали наступні дві статті:
- Клонування в PHP, або чому ваш синглтон може вбити WordPress Томас Шольц
- Синглтони та їх використання в WordPress від Карла Александера
Обидві ці статті надають надзвичайно цінну точку зору на цей шаблон і небезпеки його використання під час нашої роботи в WordPress; однак, чи означає це, що ми повинні повністю їх уникати?
Я так не думаю.
Знову ж таки, я також розумію, що в статтях не йдеться про те, щоб їх повністю уникати. Вони надають вагомі аргументи щодо того, як їх використовувати, і небезпеки їх використання, якщо ви вирішите це зробити.
І хоча я точно використовував їх у минулому, я взагалі припинив. Однак нещодавно я натрапив на варіант використання проекту, який, на мою думку, є прийнятним.
Все ще використовуєте Singletons у WordPress?
Щоб пояснити, чому я розглядаю саме цей шаблон, я вважаю, що варто спочатку зрозуміти прецедент використання. Простіше кажучи:
- Існує сторінка адміністрування, яка дозволяє користувачеві вибрати, як вони бажають відображати дати на передній частині сайту.
- Коли користувач збереже параметр, він запише формат на основі PHP для дати в таблицю WordPress.
- Під час відтворення дати значення буде отримано з бази даних і застосовано до дати, яку потрібно відобразити.
І для тих, кому цікаво, існує лише кілька – скажімо, чотири чи п’ять – способів, якими ми дозволяємо користувачеві відображати дату.
Оскільки цей конкретний проект дозволяє користувачам імпортувати файли CSV із даними (включно з датами) і відтворювати дані з файлів CSV, хоча й у іншому форматі, варто зазначити, що на сервері виконується значна кількість форматування дати.
Природно, виникає питання:
Чому б просто не відформатувати дату, коли користувач імпортує свій CSV?
І це тому, що користувач може вибрати спосіб відображення дати після імпорту CSV.
З огляду на це, у плагіні є цілий інший механізм, який відповідає за перевірку, дезінфекцію та запис введених користувачем даних у базу даних.
Але коли приходить час захоплювати значення з бази даних, особливо коли це відбувається у формі читання значення з таблиці бази даних і робити це в кількох точках по всій програмі, чи не було б сенсом мати одну точку з яке значення можна отримати?
Огляд високого рівня того, як це функціонує.
Або, інакше кажучи, чи не має сенсу змінити одне місце в програмі, яке може легко каскадувати по всій решті програми, а не шукати всі можливі місця:
- читання варіанту,
- переконавшись, що це встановлено,
- визначення значення за замовчуванням, якщо його не встановлено,
- і повернення значення?
І тут я бачу ефективне використання єдиного елемента в WordPress: спосіб зчитування даних у кількох точках по всій програмі. Однак це несе з собою деякі наслідки:
- екземпляр класу не потрібно створювати більше одного разу (я маю на увазі, що це вся ідея синглтона),
- він не матиме справу зі змінними даними,
- це не буде написання інформації чи маніпулювання інформацією.
Іншими словами, він несе повну відповідальність за отримання інформації та її повернення. Це воно. Більш нічого.
Приклад реалізації
Отже, як це може виглядати? Ось приблизна реалізація для цілей розмови:
<?php
class Date_Formatter {
private static $instance;
private function __construct() {
}
private static function get_instance() {
if (null === self::$instance) {
self::$instance = new self;
}
return self::$instance;
}
public static function get() {
self::get_instance();
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
Як бачите, він відповідає всім пунктам вище. Тобто він читає дані, встановлює значення за замовчуванням, а потім повертає його.
Цей клас не робить нічого, крім читання та повернення дуже конкретного набору даних.
Застереження щодо кешування
Очевидно, оскільки цей клас читає дані з бази даних, його можна – і, можливо, потрібно – кешувати. Однак суть цієї публікації полягає не в тому, щоб вникати в перехідні процеси, терміни дії та працювати над усіма цими нюансами.
Натомість мова йде про оцінку того, чи є це дійсним варіантом використання для реалізації singleton у WordPress.
Зачекайте, це не повинно бути саме так!
Я знаю, я знаю. Псих! Я вважаю, що це правильна термінологія, але залишаймося професійними.
До цього моменту вся публікація розповідала про те, чому ви можете дослідити використання одиночних елементів у WordPress, щоб у вас був спосіб легкого отримання інформації за допомогою узгоджених об’єктно-орієнтованих принципів.
Але я все ще не вважаю, що тут потрібне використання сінглона в WordPress. Принаймні, я вважаю, що статична функція цілком підійде. І єдина причина, чому я вважаю, що це нормально, полягає в тому, що створення екземпляра класу кожного разу, коли вам потрібно отримати доступ до функції, яка отримує дані, які не будуть змінюватися в межах класу, є надмірним.
Так як це виглядає?
<?php
class Date_Formatter {
public static function get() {
$default_format = 'm/d/Y';
$format = get_option( 'yhd_directory_importer', false );
if (false === $format) {
return $default_format;
}
$format = $format['date'];
$format = (isset( $format) && isset( $format['format']) )? $format['format']: $default_format;
return $format;
}
}
І це, на мою думку, краще рішення, ніж реалізація довільного шаблону проектування, коли він взагалі не потрібен.
Але я готовий переконати в протилежному.
Думки більш досвідчених розробників?
Я чув від свого друга та колеги, що просто використання функції простору імен може бути навіть правильним шляхом. Зрозуміло, що існує багато способів вирішити цю проблему.
І разом з цим мені цікаво почути від решти вас, як ви можете ще більше рефакторити це. Я не дуже стурбований реалізацією функції get, оскільки вона в основному збирається для демонстрації.
Натомість мене цікавлять способи вирішення цього за межами того, що тут представлено. Або, точніше, просто ваше сприйняття того, що ви бачите.