Использование классов вместо глобальных функций в functions.php


11

Во многих темах, которые я видел (включая TwentyEleven) и в примерах, которые я нашел в Интернете, при создании functions.phpфайла для темы вся функциональность объявляется в глобальной области видимости. Чтобы уточнить, вот как выглядит типичный файл функций:

function my_theme_do_foo() { // ... }

function my_theme_do_bar() { // ... }

add_action( 'foo_hook', 'my_theme_do_foo' );

Мне кажется, что вещи могли бы быть "инкапсулированы" немного лучше, если бы использовался класс:

class MyTheme {
    function do_foo() { // ... }
    function do_bar() { // ... }
}

$my_theme = new MyTheme();

add_action( 'foo_hook', array( &$my_theme, 'do_foo' ) );

Преимущества второго подхода (на мой скромный взгляд):

  • Более короткие имена функций
  • Доступ к переменным экземпляра (самое большое преимущество IMO)
  • Нет глобальных функций

Недостатки:

  • Имя класса все еще может вызывать конфликты
  • Не так ясно, чтобы «настроить» с дочерней темой (придется расширить родительский класс)
  • Большинство тем не сделали это таким образом, так что вы бы противостоять тенденции

Я, наверное, упускаю из виду некоторые вещи, но мне интересно, почему бы не принять подход ООП? Это чувствует себя немного "чище" для меня, если что-нибудь. Возможно я ошибаюсь?

Я довольно новичок в разработке темы WordPress, так что простите меня, если это общеизвестно в сообществе WP :). Просто пытаюсь понять, почему вещи такие, какие они есть.


Вы можете проверить темы у Ковшенина - wordpress.org/extend/themes/profile/kovshenin, он использует подход ООП в functions.php
Мамадука

Ответы:


9

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

Мы не делаем это для стандартных тем WordPress, потому что это повышает барьер для входа. Функции довольно просты. Удаление действий, связанных с классами, может быть затруднено (и может привести к ошибкам в определенных обстоятельствах).

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

Я подумывал о том, чтобы сделать код темы вариантов Двадцать одиннадцатого классом, но так и не нашел его. Такая отдельная, подобная плагину функциональность кажется хорошим кандидатом для инкапсуляции.


Спасибо за ответ, Нацин. Я не задумывался о сложности «отцепления» действий с классами. Что касается инкапсуляции опций - мы думали о том же: github.com/jestro/struts
Энди Адамс,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.