Использование ООП в темах

Я вижу много плагинов, использующих объектно-ориентированное кодирование, когда в этом нет особой необходимости.

Но что еще хуже, разработчики тем начинают делать то же самое. Коммерческие темы и бесплатные популярные темы, такие как Suffusion, даже моя любимая тема - Hybrid, помещают все свои функции в класс, создают его один раз в functions.php и запускают его функции процедурным способом :)

WTF? Какой смысл делать это? Очевидно, вы не будете использовать два или более экземпляров одной и той же темы одновременно.

Давайте предположим, что плагины делают это для пространства имен (что смешно), но в чем извинение темы? Я что-то пропустил?

В чем преимущество написания такой темы?

Я могу понять вашу путаницу, основываясь на приведенном вами примере. Это действительно плохой способ использовать класс ... и только потому, что класс используется, не делает системный ООП.

В случае Hybrid они просто используют класс для пространства имен своих функций. Учитывая, что Hybrid является структурой тем , это делается для того, чтобы дочерние темы могли повторно использовать имена функций без необходимости беспокоиться о конфликте имен. Во многих случаях структура темы (родительская тема) настолько сложна, что многие разработчики дочерних тем никогда не поймут, что именно происходит внутри.

Если бы Hybrid не использовал структуру класса, разработчикам дочерних тем нужно было бы знать, каковы все существующие вызовы функций, чтобы они могли избежать повторного использования имен. И да, вы могли бы просто поставить перед всеми своими функциями уникальный префикс slug, но это делает код трудным для чтения, сложным для сопровождения и по сути одноразовым, если вы разрабатываете дополнительные системы, которые хотят использовать ту же функциональность.

Ответить на ваши вопросы

WTF? Какой смысл делать это? Очевидно, вы не будете использовать два или более экземпляров одной и той же темы одновременно.

Нет, вы не будете использовать два или более экземпляров одной и той же темы. Но, как я уже сказал, представьте, что структура класса в этом случае является пространством имен функций, а не создает традиционный экземпляр объекта. Объединение в единое целое всего класса и создание его экземпляра для вызова методов ( myClass->method();) или прямого вызова методов ( myClass::method();) - это очень чистый способ пространства вещей в удобочитаемом, многократно используемом виде.

Конечно, вы всегда можете использовать что-то вроде myClass_method();этого, но если вы хотите повторно использовать любой из этого кода в другой теме, в плагине или в другом фреймворке, вам придется вернуться назад и изменить все свои префиксы. Хранение всего в классе является более чистым и позволяет вам перестраивать и переделывать намного быстрее.

Давайте предположим, что плагины делают это для пространства имен (что смешно), но в чем извинение темы? Я что-то пропустил?

В большинстве ситуаций я бы с тобой согласился. Тем не менее, это большинство быстро уменьшается. Я размещаю несколько сайтов на установке MultiSite, которые используют варианты одной и той же темы. Вместо того, чтобы заново создавать одну и ту же тему с небольшими отличиями, у меня есть один «класс» для родительской темы, и все дочерние темы расширяют этот класс. Это позволяет мне определять пользовательские функции для каждого сайта, сохраняя при этом общее чувство единообразия по всей сети.

С одной стороны, разработчики тем могут выбрать основанный на классе подход к пространству имен своей функциональности (что не смешно, если вы работаете в среде, где вы снова и снова используете куски одного и того же кода). С другой стороны, разработчики тем могут выбрать подход на основе классов для легкого расширения дочерними темами.

В чем преимущество написания такой темы?

Если вы используете на своем сайте только Hybrid, вам как конечному пользователю будет мало что известно о преимуществах. Если вы создаете дочернюю тему для Hybrid, есть преимущества от пространства имен и расширяемости. Если вы работаете в ThemeHybrid , преимущество заключается в быстром и эффективном повторном использовании кода в других ваших проектах (Prototype, Leviathan и т. Д.).

И если вы разработчик тем, которым нравится определенная функция 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 функций в вашей теме ... просто установите таймер для одной из них, а затем начните выполнять некоторые математические операции. Даже если это не ООП, это хороший способ сделать код

1) многоразовые
2) ремонтопригодные
3) сменные
4) чуть быстрее

Когда вы посмотрите на различные классы, которые плавают в сети, и которые помогают вам быстро создавать мета-блоки, виджеты и т. Д., Тогда хорошо использовать контроллер, такой как упомянутый @toscho, потому что вы можете просто подключать классы и просто заменять их. некоторые строки в контроллере, который обрабатывает ваши классы.

Некоторые утверждают, что инкапсуляция является единственным (или, по крайней мере, основным) преимуществом, которое предлагает ООП, и что наследование и состояние находятся где-то между скучным и злым:

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

Автор больше говорит об использовании классов / объектов в качестве структур, чем контейнеров для статических функций, но интересно прочитать совершенно другой взгляд на этот вопрос от того, кто находится прямо за пределами ООП-лагеря.

Я могу написать свой следующий плагин WordPress на Haskell.

Ох уж дискуссия! Я должен также признать, что я использую классы для инкапсуляции гораздо чаще, чем нет. Идея заключается в том, что в моих плагинах я могу обернуть свои функции в класс, и в этом классе использовать очень простые, значимые имена методов, которые являются общими, даже среди других плагинов, которые я пишу. В этом случае классы заменяют пространства имен, которых я вынужден избегать в средах 5.2.x.

Несмотря на то, что есть несколько случаев, когда ООП может быть полезен для модульности, простое действие оборачивания ваших функций также создает дополнительный бонус расширяемости кросс-плагина. Например, я недавно расширил решение для выставления счетов, основанное на классах, и, таким образом, я мог расширить основной класс, добавить дополнительный код к различным функциям (w / parent :: call) и даже заменить функции, и все это без интернализации расширенного плагина.

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

Какой смысл жаловаться на код, который вы не написали?

Если вам не нравится код, напишите свой собственный!

Просто. Проблема решена.

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

Код не поэзия. Код представляет собой вариацию песни Синатры "My Way" ...