Дмитрий Александров, ваш наброс мог бы прокатить, если бы я не был тимлидом, который вышеописанным образом реализовал несколько ERP систем, в тч и для гос органов. При этом имея под собой по большей части мидлов с джунами, которые без проблем справлялись с разработкой и многолетней поддержкой минимальной командой.
ООП-кодеры не могут друг с другом договориться: геттеры/сеттеры - плохо, private методы - плохо, статические методы - плохо. Ещё возьмите идею Elegant Objects (имхо больше всего похожее на то, что я советую делать вне ООП) и прочие подобные. У каждого свои правила. И почти все борются с какими-то проявлениями самого ООП.
На счёт конторы. Само собой, я стороной обхожу конторы, в которых поклоняются классике ООП. Тк не все ребята смогут спокойно принять тот факт, что можно писать чище и иметь лучшую поддержку. Благо, работу меняю нечасто. И обычно ищу новые проекты, под которые нужно собрать команду. Или ищу проекты без ООП, в которых нужно отрефакторить проект (да, процедурщики без опыта и правильных паттернов в 95% скатывают проект в легаси. Совершенно не спорю).
Дмитрий Александров, если что, я не топлю за ФП, тк в нём есть жуткие вещи, типа каррирования, которые являются анти-паттернами, усложняющими чтение. И изменение состояния приложения в любом случае будет. И вообще, я скорее, процедурщик, пользующийся основами ФП для удобства масштабирования.
Хочу объяснить, почему считаю ООП - плохой идеей для того, чтобы организовать свой код.
Предположим что вы решили писать на ООП. Вам придётся изучить пачку паттернов, добрая половина из которых создана лишь для обхода узких мест ООП. Они усложняют чтение. Потом вы узнаете о SOLID, ПО станет писать чуть проще. Оно чуть позже станет превращаться в легаси. Потом вы поймёте, что и SOLID создаёт новые проблемы, которые нужно решать. Итд итп. В итоге, через несколько лет, будучи седым, вы оказываетесь одним из ООП-разработчиков, которые не могут прийти к единому мнению, какие же из десятков паттернов и принципов нужно использовать, чтобы чуть меньше стрелять себе в ногу.
А в "соседнем потоке" зелёные джуны, прочитавшие за день об иммутабельности, чистых функциях, разбиении функционала на модули, пишут максимально легкочитаемый, бесконечно масштабируемый код, который никогда не превратится в легаси.
Итог: одни просто разбивают код на модули, другие придумывают для этого неудобные парадигмы, и сами же воюют с ними. Вы посмотрите на комментарии в этом топике. Люди, как и вы, просто не знают, в чём проблема их кода, и как можно иначе. Ваш класс - это мой модуль с функциями. Путаницы меньше, тк данные отдельно и на видном месте.
Я архитектор нескольких крупных проектов без ООП. Мои проекты могут поддерживать даже джуны. А вы говорите заученными лозунгами, имея поверхностные знания в программировании, увы.
Вы вообще не понимаете, о чём говорите. В процедурном и функциональном стилях данные точно так же "разбиваются на кучи таблиц". Это Файлы, модули, отдельные переменные. Просто ООП-адепты не знают ничего, кроме ООП. И думают, что вокруг одни говнокодеры, а они молодцы.
Имхо такие ораторы прекрасно показывают уровень людей, топящих за ООП. Они просто настолько узколобо развиты, что думают, что вне ООП жизни нет ) А оказывается без ООП всё делается точно так же, только проще )
Saboteur, у всех ООПшников одна и та же проблема. Они, видимо, не слышали, что в программировании есть файлы и модули, с помощью которых можно и нужно разбивать функции логически. Ещё они не слышали, что упаковывание данных с методами в один объект - это почти всегда плохая идея, приносящая много гемора на будущее. Иммутабельность и чистые функции - это то, что поможет читать и разбираться в проектах огромной сложности, тк код будет без побочных эффектов и однонаправленным.
Имхо дробление на модули, отделение данных и методов, иммутабельность и чистые функции - это простейшие правила, которые помогают писать проекты любой сложности, без использования чужеродного для JS ООП. Эти правила изучаются за час. И в итоге получаем крутые легкочитаемые проекты, с которыми справится даже джун без знания паттернов ООП и прочего "глубокомысленного" бреда.
Разница заметна. И, увы, у ООП явные проблемы. Идёт смешивание данных и методов. В функциональном подходе функции отлично выносятся в отдельные файлы-модули. Данные остаются отдельно. Имхо ООП программисты бесповоротно испорчены, поэтому не видят очевидных проблем, выдавая их за плюсы.
Igor Tarasov, AJAX и проблема несменяемого URL, увы, никак не связаны. Возьмите для примера обычный POST-запрос классической HTML формы с фильтрами. AJAX не используется, страница отфильтруется и перезагрузится, а URL не изменится.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
ООП-кодеры не могут друг с другом договориться: геттеры/сеттеры - плохо, private методы - плохо, статические методы - плохо. Ещё возьмите идею Elegant Objects (имхо больше всего похожее на то, что я советую делать вне ООП) и прочие подобные. У каждого свои правила. И почти все борются с какими-то проявлениями самого ООП.
На счёт конторы. Само собой, я стороной обхожу конторы, в которых поклоняются классике ООП. Тк не все ребята смогут спокойно принять тот факт, что можно писать чище и иметь лучшую поддержку. Благо, работу меняю нечасто. И обычно ищу новые проекты, под которые нужно собрать команду. Или ищу проекты без ООП, в которых нужно отрефакторить проект (да, процедурщики без опыта и правильных паттернов в 95% скатывают проект в легаси. Совершенно не спорю).