Читал статьи, но везде есть свои НО, да еще и в комментариях пишут противоречивую информацию. Хочу раз и навсегда поставить точку в этом вопросе. ООП тормозит или все зависит от древности ооп кода, самого алгоритма и рук кодера? Доводы о том что ООП легче читается вообще не интересуют. Абсолютно не интересно кто будет читать мой процедурный код, специфика скрипта такова что сторонний человек все равно не поймет толком о чем идет речь, тем более что в коде очень много математики + лично мне процедурный код более понятен.
Вот к примеру мой ООП скрипт https://github.com/VasyaSh/Paletter ,а вот точно такой же алгоритм, но в виде одной функции https://php.ru/forum/threads/kuplju-skript.67721/page-4#post-549953 и она работает в 6 раз быстрее, чем ООП. Но причина этого в том, что для таких алгоритмов ООП не нужен. Здесь вместо того, чтобы 10 тыс раз записать число в переменую, 10 тыс раз создается объект Color, да еще с __call() вместо нормальных методов. ООП версию я сделал для красоты. Потому что ООП нужно для построения архитектуры приложения, а не для реализации алгоритма. В приложении в целом не будет разницы, в ООП его "каркас" или нет.
простыми словами, лучше копи паст сложного процедурного кода в 10 местах, чем одна сложная функция на ООП которая используется в 10 местах. из другой моей темы в которой вы отписались. Чат на ООП сильно тормозит или можно смело его написать на ООП? Сам чат не сложный скрипт, но кол-во пользователей велико. А делать мат. вычисления на ООП я уже понял что нельзя, в чем собственно убедился на практике.
отвечу коротко - процедурный код быстрее --- Добавлено --- но, в глобальных переменных, таких как подключение к бд, будет косяк. Надо будет постоянно писать во функции global или прописывать дополнительный аргумент "коннект" test_function( $mysqli, $... ); --- Добавлено --- хотя конструкцию класса написать мона на статике
от себя добавлю - не настолько быстрее. чтобы из-за скорости пренебрегать ООП (удобством, расширяемостью итд) если на то пошло - PHP вообще не рекордсмен скоростей.... потому если нужны математич и другие функции - лучше писать на то что реально быстро - типа C++ итд, а из php обращаться к результатам
ООП код в конце концов понятнее.... хочешь исправить логику - она в модели.. хочешь что то вывести еще на экран.. пошел в контроллер- подготовил данные.. пошел в вьюху - добавил переменную в шаблон... мешанина из кода + длинные портянки кода рано или поздно становятся плохо читаемыми.. по себе знаю))
кто мешает все это сделать в процедурном стиле? почему если процедурный код - то сразу "мешанина кода и длинные портянки"? Разделить логически код, реализовать подобие MVC можно и без ООП. насчет скорости, если дружить с головой и понимать как это все работает, то можно писать код который будет одинаково быстрый. тем более что можно взять от каждого подхода лучшее и писать комбинированный код, где нужно применить ООП, а остальное процедурками.. этого никто не запрещает делать. зачем загонять себя в искусственные рамки и ограничения. ТОЛЬКО одно или ТОЛЬКО другое.. главное, чтобы код решал поставленную задачу.
можно)) если чтото небольшое делаете)) а когда появляются сотни функций, начинаешь в них путаться)) лучше что бы они были по моделям распиханы) что бы методы работы с моделью были собраны в одном классе)
вот тут начну спорить - не лучше в чем ? в opcode ? быстродействии интерпретатора над логистикой кода, без абстрактного занесения конструкции в память ? --- Добавлено --- весь ооп перед началом использования, заносится конструкцией класса в память как константы обыкновенные, далее выстраивается логическая цепочка всех связей, а уж потом начинает работать.
Не лучше как болид ф1 не лучше седана Е класса для жизни --- Добавлено --- @artoodetoo это даже не ф1, что это вообще?))
когда я узнал что пдо = ооп, я вздохнул с облегчением, т.к. не нужно изучать этот вопрос. банальная регистрация пользователя на ооп намного сложнее и даже количество символов больше. да, работать на ооп в чужом коде возможно и легче, но подходит он для простеньких сайтов. а что если при нажатии одной кнопки у вас высчитывается два десятка мат. вычислений?
Если вычисления сложные, а объем большой, лучше реализовать их виде кода на тех же С++, а потом вызывать полученное приложение из PHP через exec, передавая ему данные на вход и забирая ответ.
Наоборот, он подходит для сложных модульных сайтов. Если у тебя сложные вычисления, то напиши процедурный код и вызывай его через ООП.
завышенная планка для меня. доверить разработку стороннему человеку не могу по многим причинам, а си это уже хай левел. решил писать сабж из соседней теме на php+mysql, необходимый минимум выдержит и к моменту когда мой скрипт станет тормозить: 1. или нанять за большие деньги реального специалиста(и стоять у него над головой во время работы, без доступа в интернет и без портов для карт памяти), 2. или самому освоить соккеты+node.js. хороший вариант скелета движка, однако у меня нет необходимости в дальнейшем поручать работу стороннему разработчику, ко всему прочему я не дам исходной код из-за недоверия. все плюсы ООП о которых говорят, для моей задачи теряют актуальность. + процедурный вариант мне лично читать намного удобнее. возможно я сильно ошибаюсь из-за неопытности, время покажет.
Чисто из любопытства, а что за такой секретный проект, чтобы такие меры предпринимались? Мне без шуток интересно, т.к. за всё время у меня не было ни одного клиента, который хоть что-то приблизительное в условиях мне поставил. Хотите верьте, хотите нет, но даже сейчас у меня есть все доступы к серверам моих клиентов. А как иначе? Если что-то случается, то мне нужно оперативно вмешаться, чтобы решить проблему, а не ждать, когда клиент приедет, приставит ствол к виску и откроет доступ.
+1. Причем привелегии этого доступа могут быть выше, чем те, что есть у самого клиента. --- Добавлено --- Вы можете трижды стоять у него за плечом, но у него уже есть полный доступ к системе, он уже может заложить любую закладку, а вы и не просечете. А доступ к интернету нужен обязательно. Документацию наизусть никто не учит. В общем, это как с врачом. Разраб - хирург, а сервер жертва пациент. Если только вы не хотите сами потратить несколько лет, чтобы научиться самостоятельно проектировать сложные системы.
ООП инструмент, никто не говорит, что лучший и единственно возможный. Тут как бы спорить не о чем. Нравится на процедурах - делайте на процедурах, только желательно нормальных процедурах, не в 20 экранов каждая. Если что, можно математические вычисления вынести в объект так, что будет быстро, тут правильно сказали. Главное - использование слова class ещё не говорит, что в проекте ООП.
вот только WordPress обосрался, когда по началу хотел все супер пупер замутить на процедурном кодом. Прошло несколько лет и надо было функции менять и логику. Бдыш - ебать копать... они замутили говнофреймворк
Отвечу коротко. Проект не стандартный. 99 процентов что никто тут не сталкивался. Ценность представляют рассчетные алгоритмы, в меньшей степени интерфейс и то, что не связано с кодингом. Стандартная, шаблонная работа кодера, назовем ее юзабилити - ценности не представляет. Ни о какой передаче доступа к файлам и речи быть не может)) Скажем так, если в сети 90 процентов IPB варезный и это не сильно(возможно) бьет по карману разработчиков данного скрипта, то в моем случае потеря исходников фатальна.(хотя даже при потере исходника, развивать скрипт нормально не смогут.) Касательно ООП. Мне приводили довод, мол процедурный скрипт - это готовый скрипт, переписывать его не будешь. А если скрипт не развивается - это дохлый скрипт. Не знаю на чем был написан тот же IPB или PhpBB, вполне возможно на процедурном, ныне на ооп. Но долголетие этих скриптов говорит о том что все зависит от желания. Еще добавлю, что для многих ООП - нежелание париться. Чат что мне делали, я глянул исходник. Накинули готовых функций. Это не дело. Это не программирование. Сравнить могу с сайтом верстку которого делали в wysiwyg. таблицу создали, параметры отредактировали, а как все это работает - не знают. И при всем этом, даже с моим мизерным опытом, согласен что ООП очень удобно. Но гнобить процедурный стиль из-за того что "сейчас так никто не делает" не стоит. Всему свое место. И еще, со временем возможно парадигма ООП измениться или появиться что-то новое, а процедурный стиль будет всегда. Коротко не получилось))