Нужен ли ООП на сайтах PHP, не могу ли я просто применить его концепцию к процедурному коду…. - PullRequest
1 голос
/ 01 декабря 2011

Я знаю, что существует бесчисленное множество вопросов о разнице между ООП и процедурной, когда использовать какой-либо из них и перевешивают ли выгоды дополнительные издержки, изучение синтаксиса, путаница наследования и т. Д. Большинство из того, что я обнаружил, имеет тенденцию просто обсуждатьразличия и преимущества, а не необходимость в этом.

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

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

Хотя ООП необходим в большинстве приложений PHP, особенно когда скорость выполненияСвятой Грааль для большинства сайтов?хорошо, поэтому миллисекунды не будут заметны, если только сайт с интенсивным использованием, но как фанат скорости электронной музыки, является королем!

Я использую ООП в таких сложных вещах, как игры и облачное ПО в реальном времени, но на статических сайтах?даже базы данных с большими объемами?

Есть ли у кого-нибудь примеры реальных сайтов, которые получают выгоду от ООП и почему?

Если предположить, что оба случая хорошо структурированы, будут ли интенсивно использоваться сайты, такие как ebay или monster.co.uk больше пользы от ООП или ускорения процедурного ()?и почему?

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

Разве я не могу просто применить модульное мышление ООП с четким MVC и хорошо прокомментированным кодом?

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

И в процедурном порядке уже существует своего рода наследование без необходимости проходить через обручи для его объявления.У вас нет такого же уровня управления, но он выполняет работу хорошо и быстро.

Вы даже можете симулировать класс, группируя функции в родительской функции и используя функцию селектора для доступа к ним.Это все еще далеко!

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

Зачем создавать объект и использовать метод для 'получения' значения, когда я мог бы просто ссылаться на значение напрямую с помощью процедурного?

хорошо сделано для получения этогодалеко, не понял, что я так много печатал.Во всяком случае, прежде чем я отступлю дальше, я собираюсь закончить это здесь.

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

Ответы [ 4 ]

9 голосов
/ 01 декабря 2011

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

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

3 голосов
/ 01 декабря 2011

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

Требуется ли ООП в большинстве приложений PHP, особенно, когда скорость выполнения является святым Граалем для большинства сайтов? хорошо, поэтому миллисекунды не будут заметны, если только сайт с интенсивным использованием, но как фанат скорости электронной музыки, является королем!

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

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

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

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

Вы можете написать хороший процедурный код, но это сложнее, чем написать хороший ООП-код. Более слабые программисты с меньшей вероятностью будут писать безумные спагетти-коды, когда им предоставляется система ООП для работы.

Зачем создавать объект и использовать метод для «получения» значения, когда я мог бы просто ссылаться на значение напрямую с помощью процедурного?

Это ваш единственный реальный вопрос реализации. Идея использования Getters / Setters заключается в том, что вы можете изменить внутреннюю работу класса, не нарушая другой код, который от него зависит.

2 голосов
/ 01 декабря 2011

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

Подразумевается, что вам не нужна скорость в играх, а скорость на веб-сайтах.

PHP никогда не является узким местом, если это так, напишите его на C.

Не пишите процедурный код, потому что он "быстрее". Это глупо.

Есть ли у кого-нибудь примеры реальных сайтов, которые получают выгоду от ООП и почему?

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

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

Я бы лично сказал, что, скорее всего, ваш код является модульным и обслуживаемым, если бы он был ОО.

Это не обязательно, хотя.

И какое-то наследство уже существует в процедурном порядке без необходимости прыгать через обручи, чтобы объявить его. У вас нет такого же уровня контроля, но он делает работу хорошо и быстро.

В ОО-программировании все сводится к инкапсуляции, что означает связывание данных с некоторыми функциями, которые ими управляют.

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

Классы и OO просто дают вам сахар и полезности.

Это инструмент для написания модульного кода, если он помогает вам его использовать.

Не стоит заранее оптимизировать ОО, потому что он "медленный". Если вас интересует такая микрооптимизация, начните писать C или ASM.

1 голос
/ 21 октября 2016

Я думаю, что многие люди, которые пропагандируют ОО, моложе и когда-либо писали / учили только когда-либо, и поэтому очень негативно относятся к процессуальному, старомодному и «наследственному».

IMO легко написать модульный процедурный PHP, который будет СУХИМ и может быть легко поддержан. Хитрость заключается в том, чтобы использовать функции и 'include' для повторного использования стандартных php и html соответственно. В конце концов, PHP просто читает БД и генерирует html - нет особой необходимости добавлять дополнительную сложность ОО, если вы этого не хотите.

...