Використання OOP у темах

Я бачу дуже багато плагінів, що використовують об'єктно-орієнтоване кодування, коли це насправді не потрібно.

Але ще гірше - розробники тем починають робити те саме. Комерційні теми та безкоштовні популярні теми, такі як Suffusion, навіть моя улюблена тема - Hybrid, заповнюють усі їх функції всередині класу, інстанціюють його один раз у function.php та виконують його функції процедурно :)

Wtf? Який сенс робити це? Очевидно, ви не будете використовувати два чи більше екземплярів однієї теми одночасно.

Припустимо, що плагіни роблять це для простору імен (що смішно), але в чому тема виправдання? Я щось пропускаю?

Яка перевага кодування такої теми?

Я можу зрозуміти вашу плутанину на основі прикладу, який ви надали. Це дійсно поганий спосіб використання класу ... і лише тому, що використовується клас, не створюється OOP системи.

У випадку з гібридом вони просто використовують клас для простору імен своїх функцій. Зважаючи на те, що Hybrid є тематичною основою , це робиться для того, щоб дочірні теми могли повторно використовувати імена функцій, без розробника не турбуватися про зіткнення імен. У багатьох випадках тематична рамка (батьківська тема) настільки складна, що багато розробників дитячої теми ніколи не зрозуміють, що саме відбувається під кришкою.

Якщо Hybrid не використовував структуру класів, розробникам дочірньої теми потрібно було б знати, що всі існуючі виклики функцій, щоб вони могли уникнути повторного використання імен. І так, ви можете просто встановити всі свої функції за допомогою унікального слугу, але це робить код важким для читання, важким для обслуговування та за своєю суттю не повторним використання, якщо ви розробляєте подальші системи, які хочуть використовувати той самий функціонал.

Щоб відповісти на ваші запитання

Wtf? Який сенс робити це? Очевидно, ви не будете використовувати два чи більше екземплярів однієї теми одночасно.

Ні, ви не будете використовувати два чи більше екземплярів однієї теми. Але, як я вже сказав, подумайте про структуру класу в даному випадку як про розширення імен функцій, а не про створення традиційного об'єкта. Збирати все разом у класі та або примушувати його до методів виклику ( myClass->method();), або до виклику методів безпосередньо ( myClass::method();) - це дуже чистий спосіб ідентифікувати речі з простору імен у читаному, багаторазовому використанні.

Звичайно, ви завжди можете використовувати щось на кшталт myClass_method();цього, але якщо ви хочете повторно використовувати будь-який з цього коду в іншій темі, в плагіні або в антогерній рамці, вам доведеться повернутися назад і змінити всі свої префікси. Зберігати все в класі більш чисто і дозволяє переробити та перерозподілити набагато швидше.

Припустимо, що плагіни роблять це для простору імен (що смішно), але в чому тема виправдання? Я щось пропускаю?

У більшості ситуацій я погодився б із вами. Однак ця більшість швидко згасає. Я розміщую кілька сайтів на установці MultiSite, які використовують варіанти однієї теми. Замість того, щоб заново створювати одну і ту ж тему з незначними відмінностями, у мене є один "клас" для батьківської теми, і всі дочірні теми поширюють цей клас. Це дозволяє мені визначати спеціальні функціональні можливості для кожного сайту, зберігаючи загальне відчуття рівномірності у всій мережі.

З одного боку, розробники тем можуть обрати на основі класу підхід до простору імен щодо їх функціональності (що не смішно, якщо ви працюєте в середовищі, де ви знову і знову використовуєте шматки одного і того ж коду). З іншого боку, розробники тем можуть обрати підхід на основі класу для легкого розширення по дочірній тематиці.

Яка перевага кодування такої теми?

Якщо ви використовуєте на своєму сайті лише гібрид, переваги для вас як кінцевого користувача мало. Якщо ви будуєте дочірню тему для Hybrid, є переваги щодо простору імен та розширення. Якщо ви працюєте на ThemeHybrid , перевага полягає в швидкому та ефективному використанні коду для інших ваших проектів (прототип, левіафан тощо).

І якщо ви розробник тем, який любить специфічну особливість Hybrid, але не всю тему, перевага полягає у швидкому та ефективному використанні коду у вашому негібридному проекті (якщо це також GPL).

Швидкість

Моя поточна основна тема має 13 класів. Коли я будую нову тему, я або використовую ці класи такими, якими вони є, або розширюю їх. Ця система робить процес побудови нової теми дуже, дуже швидким.

Тугі сфери застосування

Мені рідко потрібні глобальні змінні, тому що все, що повинен знати мій код, приховано у членів класу. Тож я маю змогу поділити змінну між двома дуже різними фільтрами чи діями без ризику зіткнення з погано записаними плагінами.

Технічне обслуговування

Кожен клас - один файл. Якщо мені потрібно оновити тему клієнта, я просто оновлюю деякі файли. Що б не трапилося всередині класів, залежить від мене, якщо я пропоную той самий API.

Приклад: над comment_form();викликом я використовую просту дію:

do_action( 'load_comment_class' );
comment_form();

Який клас коментарів буде завантажений, вирішує мій контролер. Що саме відбувається всередині класу коментарів, визначає індивідуальний клас.

Спробуйте це з чистим процедурним підходом, і ви зіпсуєтеся. :)

Читабельність

Так набагато простіше перечитати і зрозуміти власний код через кілька місяців, якщо ви розділили все своїм завданням.

Деякі приклади корисних ієрархій класів

• Meta_Box-> розширено на Shortdesc_Meta_Boxі Simple_Checkbox_Meta_Box-> продовжено наSidebar_Switch
• User_Profile_Addon-> продовжено на User_Profile_Checkbox(див. питання 3255 )
• Comment_Form -> продовжено на {$theme_name}_Comment_Form

Ще один момент, який слід врахувати: швидкість.

if ( !class_exists('cccYourClassName') )  
// VERSUS  
if ( !function_exists('ccc_your_function_name') )

Після короткого огляду / роздруківки я знайшов ~ 1.700 внутрішніх функцій та ~ 1.400 функцій користувача = ~ 3.100 / 3.200 функцій VS. ~ 250 класів. Я думаю, це говорить найбільше про те, скільки потрібно було б шукати. Якщо ви задіяли !function_exists('')близько 50-100 функцій у своїй темі ... просто встановіть таймер для однієї, а потім починайте займатися математикою. Навіть якщо це не OOP, це хороший спосіб зробити код

1) багаторазове використання
2) ремонтопридатне
3) обмінне
4) трохи швидше

Коли ви подивитеся на різні класи, що плавають у Інтернеті, які допомагають швидко робити метабокси, віджети тощо. деякі рядки в контролері, який обробляє ваші класи.

Деякі стверджують, що інкапсуляція - єдина (або принаймні первинна) користь, яку пропонує ООП, і що спадщина і стан є десь між нудним і злим:

http://obiecte.blogspot.com/2008/09/oop-sucks.html

Автор більше розмовляє про використання класів / об’єктів як конструкцій, ніж як контейнери для статичних функцій, але цікаво читати зовсім інше питання щодо того, хто знаходиться прямо поза табором OOP.

Я можу написати наступний плагін WordPress в Haskell.

О, цілком дискусія! Я також повинен визнати, що я використовую заняття для інкапсуляції набагато частіше, ніж ні. Тут ідея про те, що в своїх плагінах я можу перенести свої функції в клас, а в межах цього класу використовувати дуже прості, змістовні назви методів, які є загальними навіть серед інших плагінів, які я пишу. У цьому випадку класи є заміною просторів імен, яких я змушений уникати для середовищ 5.2.x.

Хоча є мало випадків, коли OOP корисний для модульності, простий акт обертання ваших функцій також створює додатковий бонус для розширення крос-плагінів. Наприклад, я нещодавно розширив рішення для виставлення рахунків на основі класу, і будучи таким, я міг розширити основний клас, додати додатковий код до різних функцій (w / parent :: call) або навіть замінити функції, все без інтерналізації розширеного плагіна.

Але все-таки, обгортання класів здебільшого є лише заміною просторів імен.

Який сенс скаржитися на код, який ви не написали?

Якщо код вам не подобається, напишіть свій власний!

Простий. Проблема вирішена.

Програмістам подобається робити речі своїм шляхом. Тож не припускайте, що ви можете сказати їм, як писати код, який віскі пити, яку марку сигарети курити чи яку релігію слід дотримуватися. Вони просто налагодять такий діатриб і продовжуватимуть робити те, що хочуть. ;-)

Код - це не поезія. Код - це варіація пісні синатри "My Way" ...