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

36

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

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

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

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

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

onetrickpony
источник
5
@Ambitious Amoeba - Можете ли вы объяснить, почему вы считаете, что использование классов для плагинов для минимизации коллизий пространства имен смешно? Что касается тем, возможно, было бы также полезно, если бы вы могли привести примеры того, что вы считаете хорошим кодом в темах, и что вы считаете ненужным. Обсуждение этого в реферате вряд ли поможет понять вас или других, особенно тех, кто не знаком с тем, на что вы ссылаетесь.
MikeSchinkel
1
Я использую классы везде, где могу, мне намного легче поддерживать, обновлять и использовать повторно. Помимо личных предпочтений, какие есть веские причины для использования класса?
t31os
1
Странно, только что потерял свой оригинальный комментарий (возможно, ошибка SE?) .. Я повторю его, хотя, какие есть веские причины не использовать класс?
t31os
2
@MikeSchinkel: вы можете сделать это, добавив префикс к имени функции. Я не думаю, что это стоит дополнительных затрат класса просто иметь хорошие имена функций. Во всяком случае, мне любопытно, почему темы делают это, а не столько о плагинах
onetrickpony
4
@ Амбициозная амеба - я, безусловно, дам вам право на свое мнение, но мое мнение отличается. Я полагаю, что ясность, которую классы вносят в код за счет минимизации функций, плавающих в глобальном пространстве имен, стоит того, что я считаю фактически неизмеримой величиной дополнительных затрат, особенно при использовании IDE профессионального уровня, такого как PhpStorm. А классы создают автономный модуль, чтобы разработчик мог знать, какой код требуется модулю. И, наконец, после развития моего стиля плагинов WordPress для использования классов, любой другой метод кажется мне просто небрежным кодированием.
MikeSchinkel

Ответы:

26

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

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

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

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

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

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

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

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

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

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

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

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

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

EAMann
источник
Я не согласен с частью "расширяемости". Вы имеете тот же уровень контроля над родительской темой, что и при использовании действий и типичных функций. Зачем? Вы сами сказали, это не правда ООП. Я также не согласен с пространством имен - вот почему я начал этот вопрос с первого места - попробуйте переопределить любую функцию из Hybrid в любом плагине, и вы увидите, что функции будут конфликтовать. Как вы думаете, почему они все еще добавили префиксы? :) Вы просто не можете обернуть всю тему в классе, это просто не имеет никакого смысла ...
onetrickpony
Я не говорю, чтобы не использовать ООП в темах, как некоторые люди здесь могли бы, наоборот, понять (см. 2.8 виджеты, например, ходунки и т. Д.), Но не так.
onetrickpony
1
Кажется, что у вас есть проблема со специфической реализацией Hybrid, а не с практикой использования ООП в темах или даже с использованием класса для пространства имен функций, определенных в теме. Я пытался ответить на ваши более широкие вопросы: зачем это делать? и повторно: каковы преимущества этого? Я не собираюсь тратить какое-то время на защиту того, что кажется нерешительной реализацией, или на спор против вашей очевидной враждебности к структуре конкретной тематической структуры. В итоге, если вам не нравится, как построен Hybrid, используйте что-то еще.
EAMann
1
Вовсе нет, мне нравится Hybrid (но не классная вещь, конечно). Гибрид вдохновил меня на создание собственной тематической рамки. Возьмите другой пример, Suffusion, тот же тип практики. Опять же, пространства имен в этом случае не работают с темами, все функции в классе оболочки всегда будут конфликтовать с плагинами, потому что плагины загружаются WP «в» темах.
onetrickpony
1
Справедливо. Просто постарайтесь иметь в виду, что большая часть работы WP не начинается с ООП (так как WP - нет), но размещение методов темы в классе, чтобы имитировать, как это делается в плагине, является по крайней мере шагом в правильном направлении. направление ... даже если это недоуменный и плохо реализованный класс. Я определенно согласен с тем, что простое завершение всего в классе и процедурный вызов - это немного странно (и бесполезно из-за POV стороннего разработчика, пытающегося использовать систему). Но если все сделано правильно (а в Hybrid это, очевидно, нет), классный код functions.phpможет быть очень мощным.
EAMann
29

скорость

Моя текущая базовая тема имеет 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
Фуксия
источник
1
Есть ли шанс получить ваши "тематические" классы? Я хочу написать свое, и я хотел бы знать, как вы это делаете.
Хорткор
1
Я еще не решил это. Возможно, в следующем году я разрабатываю новую базовую тему вместе с @bueltge, которая использует некоторые из этих классов. Боюсь, не раньше марта.
fuxia
5
Специально для ваших случаев, бесплатных тем и фреймворков, ООП - это путь. Другие люди должны работать с этими кодами. Авторы должны сделать этот процесс максимально простым и гибким. Замена класса проще, чем замена 20 функций, потому что хорошо написанный класс имеет четко определенный API.
fuxia
2
Я ничего не могу сказать о Гибриде; Я никогда не использовал это. Но, да, контроллер, который организует все за кулисами, предлагает хорошие фильтры и вставляет некоторый шаблон MVC в обычную тему - это хорошая вещь. Не верь мне. Попытайся. :)
fuxia
3
Настало время, WordPress нужна ООП тема для разработчиков; Я надеюсь, что мы нашли время, чтобы работать для нашей цели. Этот небольшой отрывок здесь и преимущества показывают большие возможности с темой для клиентов; быстрый способ реализовать новые темы и отлично подходит для обслуживания.
Bueltge
3

Еще один момент для рассмотрения: скорость.

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

кайзер
источник
2

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

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

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

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

Tex
источник
1
К сожалению, блог открыт только для "приглашенных" пользователей. Еще одно напоминание, почему мы никогда не должны публиковать нашу информацию на бесплатном сервисе и вместо этого должны размещать свои собственные блоги. Фейсбук во многом похож на этот счет. Обновленная ссылка на ресурс будет хорошей. FWIW Я видел темную сторону ООП и никогда не буду использовать ее снова, если это не является абсолютно необходимым в контексте, поскольку функции более высокого порядка обычно расширяют функциональность и помогают уменьшить шаблон и неправильное использование classключевого слова.
Джош Хабдас
2

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

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

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

Jester831
источник
-4

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

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

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

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

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

отметка
источник
10
Этот вопрос не жалуется на код, он требует четкого объяснения того, почему код будет написан определенным образом. Большая часть ядра WP является процедурной, с несколькими новыми функциями, использующими подход ООП. Многие современные плагины также используют ООП для инкапсуляции функциональности. Но большинство тем не делают. ФП спрашивал, почему будет использоваться псевдо-ООП-подход, и приводил в качестве примера гибрид. Ты не отвечаешь на вопрос, ты ругаешь.
EAMann