Есть ли какая-либо информация о том, что WordPress станет полностью ООП в будущих версиях?
15
Я могу с уверенностью сказать 99,9999%, что WordPress никогда не станет полностью ООП в будущей версии, и не в последнюю очередь то, что тема снова и снова появлялась в списке wp-хакеров, и члены основной команды не проявили интереса к делать это.
Рассматривая свой личный опыт программирования и преподавания ООП начиная с 1990 года, я согласен с основной командой и считаю, что полный ООП будет ошибкой. Хотя когда-то я был фанатом ООП и думал, что ООП - панацея, я с тех пор пришел к выводу, что в некоторых контекстах он имеет свою ценность, но в других контекстах он мешает.
Одна из самых больших проблем, с которыми я столкнулся в ООП, заключается в том, что она заставляет разработчика выпекать структуру задолго до того, как разработчик действительно поймет, какой должна быть эта структура, что затем приводит к хрупкой проблеме базового класса .
Конечно, для отдельных аспектов WordPress ООП имеет большой смысл, и если вы изучите ядро, вы найдете такие классы; Widget, List_Tables (в 3.1) и т. д.
На данный момент я рад работать с WordPress в основном не-ООП-парадигме и думаю, что если бы это был чистый ООП, WordPress никогда бы не получил следующее, что есть. Почему? Потому что ООП подняло бы планку сложности для будущих разработчиков WordPress и плагинов, и это, вероятно, привело бы к тому, что приложение было недостаточно гибким, чтобы развиваться, поскольку основная команда узнала больше о потребностях своих пользователей в прошлом. 6 лет.
FWIW.
Многие компоненты WP переписываются в коде ООП с каждым новым выпуском, и новые компоненты, как правило, используют его (например,
WP_Customizerвещь). Но если вы спрашиваете, изменит ли WP свою архитектуру на полностью объектно-ориентированную, то нет, в настоящее время нет информации, которая бы предлагала такую вещь.Я бы не сказал, что этого никогда не произойдет, но вряд ли это произойдет в ближайшем будущем, и, вероятно, не из-за проблемы «базового класса» :)
Прежде всего, существуют только недостатки в использовании процедурного кода над ООП для приложения CMS, такого как WordPress, просто потому, что такие приложения предназначены для расширения с помощью плагинов. Добавление комбинации функций и глобальных переменных вовсе не облегчает эту задачу. На момент написания WP никто не мог предсказать, каким станет WP, и было сделано много неудачных решений. Сейчас довольно сложно догнать, потому что большинство плагинов и тем перестали бы работать должным образом. Реализация огромного уровня совместимости, чтобы избежать этого, вероятно, замедлит WP и добавит еще больше путаницы среди разработчиков. Также подумайте о цели - облегчить жизнь разработчикам за счет пользователей?
Если это поможет - очень старая дискуссия о wp-хакерах, но все еще актуальная для этой темы, и предложенная сообществом идея , теперь помеченная как «территория плагина». В последнее время я не заметил другой активности в этом направлении.
источник