• ООП в высоконагруженных проектах считается устаревшим?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если проект будет писать 1-2 человека за срок до месяца, то можно и функциональное программирование.
    ООП был придуман для того, чтобы сложный и большой проект, можно было грамотно и удобно разбить на части, которые работают максимально независимо друг от друга, и которые разрабатываются и поддерживается людьми, которые друг с другом почти не контактируют.
    ООП подход - как раз и обеспечивает архитектуру того, что уменьшается вероятность факапа от несогласованности действий.

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

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

    allard
    @allard
    Серийный программист
    Когда-то видел хорошее сравнение по вопросу ооп против процедурного программирования.
    Было что-то на подобие:
    Зачем в наше время мыть посуду руками, если у вас рядом стоит посудомоечная машина. Если тебе нужно помыть одну тарелку, то можно это сделать и руками, а если после банкета у тебя гора посуды, то зачем мучаться...
    Так и с процедурным программированием, если вам нужно добавить какую-то мелочь в проект, с которым вы не знакомы, то почему бы и не написать одну функцию и не вставить её вызов куда нужно, это будет нормальным вариантом. Но если вы хотите разработать гигантский проект для работы с большими объемами разных данных, то тут без ооп никак.

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

    Да, процедурный подход выигрывает в производительности на пару процентов у ооп, ну может на пяток процентов в некоторых проектах. Просто, тяжело сравнить производительность, т.к. ни один серьездный проект не разрабатывается на стандартном php в процедурном стиле (вы представьте yii или laravel на функциях). Ну, не считая отдельных специфичных движков, типа kphp.
    Лишаться кучи преимуществ ооп, ради пары процентов процессорного времени, вообще нет смысла.
    Тем более в наше время куча облачных сервисов, любой проект можно смаштабировать...

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

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Мужик не молодец в том плане что совсем функциональный подход это не круто ниразу, но вместе с тем как ни странно прав, в том что сложное ооп (по крайней мере в тех хайлоад проектах что я видел) - не применялось ниразу.
    Ответ написан
    Комментировать
  • ООП в высоконагруженных проектах считается устаревшим?

    miraage
    @miraage
    Старый прогер
    Мужик дегенерат, однозначно.

    // EDIT

    Посмотрел прикрепленные исходники. Закапал святую воду в глаза.
    Выкиньте это всё, покажите ему, например, PHP: The Right Way.

    Я бы на Вашем месте уволился, незадумываясь.
    Ответ написан
    Комментировать