Зачем писать в ООП стиле в JS?

Question

[beginer123]

Не совсем понимаю, почему программируют в основном используя ООП подход?
Лично мне кажется запутанным все эти классы, методы, приватные методы, наследование,инкапсуляция и прочее.
Тем более в JS(понимаю в каком нибудь c++ так исторически сложилось что используется ООП)
В чем удобство?
Почему бы не писать програмы через функции?(функциональный стиль)
И вызывать их друг из друга если нужно
Например

function getUsers(){....}
function getFollowers(){....}
function getLikes(){....}

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

Comments

[Neonoviiwolf]

Напишите простыню хотя бы на 800 строк, сами перейдёте на ООП

[beginer123]

Neonoviiwolf:
Я пишу программы всегда так, пытался переписать используя классы, но честно так и не понял в чем будет преимущество, все только запутанее становиться, решил оставть функции
В чем же преимущество ООП? На конкретном примере

[Илья]

beginer123: попробуйте реализовать что нибудь сложнее формочки с несколькими полями. Какое-нибудь SPA новостное. Я понимаю что в "функциональном стиле" это тоже можно написать, но нормальный ООП будет намного органичнее и понятнее.

[Adamos]

Например, когда на страничке подключается десяток скриптов и в трех из них есть функция getUsers - это... заставляет задуматься.
Простенький пример: понадобилось мне тут работать с неделями: определить неделю по дате, определить метку времени начала и конца недели, найти предыдущую и следующую неделю, вывести диапазон дат. Разве не логично все эти действия завернуть в один класс и не высовывать из него в глобальное пространство имен?

Рискну предположить, что вы просто не научились думать классами и именно поэтому застряли в процедурных простынях.

[Coder321]

Adamos: неа, логичней юзать moment для этого)

[Adamos]

Coder321: у вас чертовски подходящий ник для этого комментария.
Ну конечно, ради того, чтобы не писать очевидный класс на 20 строк, нужно подключать чужую библиотеку, подстраиваться под ее логику, а потом обнаружить, что ради вывода диапазона дат именно так, как тебе нужно, все равно нужно написать еще 20 строк. Мы все так делаем - значит, это правильно!

[Coder321]

Adamos: вы видимо не увидели смайл в конце)

Answer 1

[Ptolemy_master]

Мои пять копеек.
В принципе незачем. Для маленьких проектов самое то.
Но есть одно но. Когда ваш проект будет расти, управляться со всей этой коллекцией функций будет ох как сложно.
Представьте, что помимо простого вызова пользователей и лайков, вам надо будет считать их, производить множество других манипуляций.
Что вам больше понравится?

1. Длиннющий список функций
getUsers
getLikes
calculateUserRating
moveUser
copyUser
saveUser
saveLike
getLike
userLikes (это список лайков или пользователь ставит лайк?)
... и еще стопицот или
2. Небольшой список объектов
User
Like
Rating

и простые, понятные вызовы типа

User.getList
User.calculateRating
User.copy
User.getLikes
User.doLike

Заметна разница?

Comments

[beginer123]

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

[Влад Токарев]

beginer123: так кроме методов у объекта могут быть и свойства, например User.name, к которому можно будет обращаться из метода класса, а не передавать его в функцию как параметр.

[Ptolemy_master]

На самом деле никакой не гемор. Конечно, когда у вас всего 10 функций, это все фигня и кажется, что данный подход - overkill. Когда проект разрастается, становится трудно отслеживать весь этот набор функций, кроме того, как правильно заметили, объекты можно снабдить свойствами (полями) и это действительно гораздо удобнее и логичнее, чем делать через функцию. О том, как правильно это делать, и вообще зачем, читайте в книге "Шаблоны JavaScript".

[ixpl0]

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

[ixpl0]

Влад Токарев, в процедурном или функциональном программировании никто не запрещает вам иметь объект const user = { name: "" }

[Влад Токарев]

ixpl0, объект можно, а вот, если есть есть у объекта поля firstName и lastName, то fullName красивее получать геттером экземпляра класса, а не отдельной функцией.

Answer 2

[Евгений]

Из Википедии:

JavaScript — мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript.

Т.е. люди так пишут, потому что язык им это позволяет.
Эта тема очень широка и глубока. Вас никто не заставляет писать в каком-то определенном стиле. В том же "Си с Крестами" Вы вполне можете писать императивно-функциональный код. У Вас будет точка входа в методе main, а дальше творите что хотите. Но есть одна небольшая проблема - этот код кроме Вас никто не будет понимать и принимать. Именно по этому в разработке ПО (заметьте не в языке программирования, а именно в ремесле разработки ПО) появляются такие вещи, как шаблоны проектирования, code convensions и code style. Людям приходится договариваться, находить оптимальный для себя вариант общения через код. Даже если Вы работаете один, Ваша команда состоит как минимум из двух человек - это Вы, и Вы в будущем. И написав лапшу из последовательного вызова функций Вы подкладываете огромную свинью себе в будущем. Почитайте Боба Мартина "Чистый код", он там не плохо на эту тему размышляет.

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

Answer 3

[Saboteur]

1. Не путайте функциональное программирование с процедурным (императивным). Это ВООБЩЕ разные вещи.
2. ООП это парадигма, которая хорошо работает в крупных проектах и облегчает дальнейшую разработку и поддержку продукта.
3. ООП позволяет инкапсулировать значительную часть кода в практически независимые объекты, что позволяет распределить разработку на несколько программистов, практически без потери производительности. В Императивном программировании это будет вызывать на порядки больше конфликтов, а объекты - в этом плане достаточно независимы, поэтому достаточно раздавать программистам задачи так, чтобы в один объект не лезло два программиста. Именно третье - самое главное в ООП. ВСЕ крупные продукты, где нужно скооперировать хотя бы 10-20 программистов без ООП будет очень печально, не говоря уж о продуктах, где нужны сотни людей.

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

Comments

[beginer123]

1. функциональное это когда код состоит из функций без ООП, так?

2. А крупные это какие? Хочу четко определить границы крупных и некрупных..
Т.е хочу четко определить для себя когда использовать ФП а когда ООП.

Т.е програмные продукты в которых участвует 1-3 человека можно спокойно писать использую Функции без ООП?

[DevMan]

beginer123: тебе уже 2 человека написали что использование функций не равно функциональному программированию.

[Saboteur]

beginer123:
1. Не поленись открыть википедию и прочитай определение функционального программирования. Перестань его путать с процедурным. Это вещи из разных вселенных.

2. Крупная процедура, это когда ты на нее смотришь и не очень понимаешь что она делает. Нормальная - когда ты можешь охватить ее взглядом и полностью понять что она делает. Тоже касается объектов.
Суть заключается в том, что когда через год, тебе нужно будет что-то исправить в коде, стоит вопрос сколько времени тебе нужно будет читать старый код, чтобы понять что он делает. Если код грамотно и логично разложен на небольшие процедуры или небольшие объекты, в которые ты можешь быстро вникнуть и поправить, а два дня вычитывать 20 экранов кода, чтобы сделать изменение в 1 строчку.

3. От количества человек это не очень зависит. Просто когда поработал в крупных проектах, в которых без ООП никак, ты получаешь опыт разработки, ты понимаешь что этот опыт полезен и удобен. И начинаешь даже маленькие продукты писать уже в ООП, просто потому что привычка и удобство для самого себя.

1-3 человекам тоже нужно как-то кооперироваться. Процедуры кооперируются хуже, чем объекты.

[ixpl0]

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

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

[Saboteur]

ixpl0,
Я не ООПшник, я даже не профессиональный разработчик.

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

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

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

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

Answer 4

[Илья]

Чтобы реализовать сложную, хотя на самом деле любую, бизнес-логику.
А не поняли вы преимущества ООП, только потому, как мне кажется, что создали класс, накопипастили туда функций которые писали до этого, и довольные остались.
Если подходить к разработке со стороны предметной области и сущностей (объектов), то ООП сам собой образовывается.
Что нибудь про SOLID почитайте, что ли.

В чем же преимущество ООП? На конкретном примере

По поводу примера, попробуйте реализовать подобный органайзер: https://www.wed-expert.com/organizer.
Как по мне, тут сразу же видно сущности: категория и элемент (от него наследуются: задача, гость, затрата).
После того как вы опишите данные сущности, весь код будет представлять из себя оперирования этими объектами (добавить, удалить, редактировать).
Если говорить про какой-нибудь React, то с его компонентной "идеологией", используя сущности очень реализовать.

Answer 5

[Павел]

ФП vs ООП старо как мир. Интерпретатору/компилятору абсолютно фиолетово какой стиль вы используете. Есть задача — она должна решаться, если ваш код её решает, используя, конечно же, минимум ресурсов, то какая разница как он написан.
Некоторые языки взяли за основу, конкретные парадигмы, например только ООП, в таких языках, естественно, всё будет ориентировано на это, поэтому писать на них как-то иначе — менее продуктивно и ещё менее понятно для другого программиста.
Удобство какого либо подхода — это субъективно. Если вы пишите на языке, который допускает использование любого подхода, то выбирайте тот, который больше нравится. Если только у вас нет комплексов, что кому-то узколобому ваш прекрасно работающий код покажется смешным, из-за того, что вы выбрали ФП вместо ООП.

Comments

[Илья]

Удобство какого либо подхода — это субъективно. Если вы пишите на языке, который допускает использование любого подхода, то выбирайте тот, который больше нравится.

Не совсем верно.
Если говорить про такие языки как Prolog/Erlang, то они очень функциональные.
На них сложно написать какую-либо бизнес логику, но вот обработку данных на них писать легко.
Также функциональные языки (именно языки, а не стиль) априори более надежные, т.к. вы получается входные параметры, и должны что-то вернуть.
Функциональные языки (и стиль), надежны за счет того что они просты и довольно примитивны.

[Adamos]

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

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

[Павел]

Adamos: Я про спагетти-код не говорил. Где вы это там увидели? И про трудно-читаемый код тоже. Я говорил про код, который хорошо написан в рамках своей парадигмы. Если программист хороший, то прочитать такой не составит большого труда. Ну, а если узколобый, то он даже разбираться не станет, а просто на ровном месте 40 ям найдёт и пойдёт своими делами заниматься.

[Adamos]

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

Answer 6

[Лежебокер]

В чём удобство?
Раньше сам задумывался, не понимал что хорошего в классах?А потом понял, что лень это двигатель прогресса.В том смысле что ты однажды написал класс в хэдере и пользуйся им на здоровье.
В чём же преимущество ООП?На конкретном примере.
Допустим, есть две фабрики.Обе выпускают машины, но подход разный.Одни используют функции, а другие классы.У тех кто используют функции проблемы, потому что заказов много, а чтобы их сделать нужно вызвать много функций.А у тех кто используют классы, их нет, поскольку они один раз написали класс и теперь всё время его вызывают простым auto Renault(Logan);.
Также с наследованием и полиморфизмом
Вышли две новые машины, которые унаследовали что-то от старой и этим фабрикам пошли заказы.Первые начали писать тонны функций, а вторые добавили в базовый класс к унаследованным функциям приставку virtual
Вот тебе польза наследования и полиморфизма.
Ну с инкапсуляцией легко, хотя достичь её непросто.Нужно просто не вдаваться в детали.Как, с кнопками громкости в пульте.Ты можешь только переключать на "Громче" или "Тише", но ты не можешь выбрать определённый уровень громкости, ведь ты рано или поздно доберёшься до него.Инкапсуляция скрыла от тебя детали.И у классовиков тоже инкапсуляция.Они один раз написали класс и он будет работать, и им не важно как, главное работает и они получают что хотят.

P.S.
Я много бурды наговорил, но это моё понимание ООП

Comments

[Илья]

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

Эээ, а функции повторно использовать нельзя???

Вышли две новые машины, которые унаследовали что-то от старой и этим фабрикам пошли заказы.Первые начали писать тонны функций, а вторые добавили в базовый класс к унаследованным функциям приставку virtual

Когда вы пишите на функциях, у вас в принципе понятия объектов нет.
Но что мешает вам написать к примеру так:

function oldFunction(params) {
    return 1;
}
function newFunction(params) {
    return oldFunction(params) + 1;
}

Как, с кнопками громкости в пульте.Ты можешь только переключать на "Громче" или "Тише", но ты не можешь выбрать определённый уровень громкости, ведь ты рано или поздно доберёшься до него.

Вообще мимо.
Если говорить про кнопки, мы не знаем какие происходят процессы внутри, мы просто знаем что когда нажмем "Громче", станет громче.

Почитай лучше про SOLID, как по мне это понятнее "классического" объяснения ООП.

[Лежебокер]

Илья:
Эээ, а функции повторно использовать нельзя?

Естественно, можно.Но что лучше?
auto Renault(Logan);
или

int checkStuff();
string buildEngind();
int buildWheels();
int buildTransmission();
int buildFuelTank();
int constructAuto();
int test();

Когда вы пишите на функциях, у вас в принципе понятия объектов нет.
Но что мешает вам написать к примеру так
Ничего, но когда много функций так будет сложнее, не так ли?

Вообще мимо.
Если говорить про кнопки, мы не знаем какие происходят процессы внутри, мы просто знаем что когда нажмем "Громче", станет громче.

Именно.В этом и есть принцип инкапсуляции.Она скрывает от нас детали.Мы знаем что будет если нажать на эту кнопку и мы выбираем:Нажать на эту, или на другую?

А также я недавно читал статью на Хабре про ООП, где сказано что, у объекта ООП должно быть состояние.Он привёл пример.Есть товар и на них есть ценник который можно менять.А есть их количество.Это объект ООП?Нет.У него нету состояния.Давайте ему его сделаем.Например, количество товаров не может быть отрицательно, а цена должна быть всегда положительной.Вот теперь это объект ООП.

P.S.
как сделать цитату?

[Илья]

Естественно, можно.Но что лучше?

Лучше функция-конструктор (фабрика), которая и будет вызывать все нужные функции.
Это конечно менее удобно, но какой-никакой выход из ситуации.

Ничего, но когда много функций так будет сложнее, не так ли?

Естественно так будет сложнее.
Но функции должны быть очень элементарными (см. чистая функция).
И собственно если все функции написаны по этим правилам, то система будет большой.
Однако, "большая система" != "сложная система".
В большой системе и объектов хренова туча будет.
А если еще углубляться в CQRS и DDD, то будет множество побочных объектов.

А также я недавно читал статью на Хабре про ООП, где сказано что, у объекта ООП должно быть состояние.Он привёл пример.Есть товар и на них есть ценник который можно менять.А есть их количество.Это объект ООП?Нет.У него нету состояния.Давайте ему его сделаем.Например, количество товаров не может быть отрицательно, а цена должна быть всегда положительной.Вот теперь это объект ООП.

Самое простое и самое идиотское объяснение ООП.
Из вашего примера, человек добавил поведение, а не состояние.
Это разные вещи.
И если говорить про ООП, не обязательно чтобы было состояние. Состояние может быть, и это отличает ООП от ФП, т.к. там нет состояний вообще (в идеале).
Так что выбейту эту дурь из головы, состояние не обязано быть.
Есть такое понятие/pattern как ValueObject, в нем нет состояния, но однако он очень часто используется в ООП (ну потому что его использование, это уже ООП).

P.S.
как сделать цитату?

[ixpl0]

Имхо такие ораторы прекрасно показывают уровень людей, топящих за ООП. Они просто настолько узколобо развиты, что думают, что вне ООП жизни нет ) А оказывается без ООП всё делается точно так же, только проще )

Answer 7

[Дмитрий Александров]

ФП и ООП можно сравнить с БД, К примеру:
1) Вся БД это одна единственная таблица в которую придется складывать вообще все. Это грубо говоря подход ФП.
2) Вся БД разбита на кучи таблиц в каждой из которых хранятся данные своего типа. Это ООП.
Для маленькой простой программы будет проще первый вариант а второй окажется диким оверхэдом, для большой и сложной программы впринципе можно задействовать первый вариант но он будет дико неудобным и запутанным а второй вариант крайне удобным и в савокупности кода станет меньше и он будет менее запутан.

Comments

[ixpl0]

Вы вообще не понимаете, о чём говорите. В процедурном и функциональном стилях данные точно так же "разбиваются на кучи таблиц". Это Файлы, модули, отдельные переменные. Просто ООП-адепты не знают ничего, кроме ООП. И думают, что вокруг одни говнокодеры, а они молодцы.

[Дмитрий Александров]

ixpl0, понимаю, прекрасно понимаю. И даже понимаю многие тонкости. Вот только есть разница, причем огромная. В ООП можно абсолютно четко понять и проследить что\куда\откуда . В ФП черт голову сломит.
Тут конечно надо в голове держать что оба подхода (ООП\ФП) в конкретной реализации языка могут иметь свои особенности.
Если пойти дальше, то найдите мне хоть одного нормального программиста который знает чуть больше одного языка и подхода и который скажет "подход ФП в виде файлы\модули\отдельные переменные\области видимости" удобнее чем четкие границы "класса который все это заворачивает в единое звено". Или наоборот что нужен "огород с классами и своими типами когда можно было обойтись парой структур."
И таки да, я не отношу себя ни к ООП ни к ФП адептам. Асболютно любой ЯП и абсолютно любой стиль имеет место быть и быть удобным для опредленного круга задач, вот когда пытаются натянуть абсолютно не предназначенное куда не надо это говнокод и говноподход говноязыка.
По этой причине могу себя причислить к жестким ненавистиникам js ,питона и даже go, которые тащят их в области абсолютно не предназначенные для них и делают абсолютно хреновые вещи с помощью них. Но смотря какой контекст.

[ixpl0]

Дмитрий Александров, если что, я не топлю за ФП, тк в нём есть жуткие вещи, типа каррирования, которые являются анти-паттернами, усложняющими чтение. И изменение состояния приложения в любом случае будет. И вообще, я скорее, процедурщик, пользующийся основами ФП для удобства масштабирования.

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

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

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

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

[Дмитрий Александров]

ixpl0, Ок, я понял что конкретно Вы, вот вообще не различаете чем прекрасен ООП и ФП, а также чем ужасен ООП и ФП.
Могу лишь намекнуть про бред что Вы написали по части.
Во первых Вы не решаете "Как писать", это решают совсем другие люди и решения они не принимают бросая кубик рубик. Они решаеют что и как НАДО писать, по каким паттернам и выдвигают best practices для юных. И это относится к любому подходу и любому ЯП.
Во вторых юные джуны, с огромными амбициями завалят проект, и точно так же уничтожат читабельность и абсолютно все остальное, вместе с заказчиком и потенциальными клиентами, а на остаток в виде действущих клиентов заставит бежать куда подальше от конторы их обслуживающей.

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

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

[ixpl0]

Дмитрий Александров, ваш наброс мог бы прокатить, если бы я не был тимлидом, который вышеописанным образом реализовал несколько ERP систем, в тч и для гос органов. При этом имея под собой по большей части мидлов с джунами, которые без проблем справлялись с разработкой и многолетней поддержкой минимальной командой.

ООП-кодеры не могут друг с другом договориться: геттеры/сеттеры - плохо, private методы - плохо, статические методы - плохо. Ещё возьмите идею Elegant Objects (имхо больше всего похожее на то, что я советую делать вне ООП) и прочие подобные. У каждого свои правила. И почти все борются с какими-то проявлениями самого ООП.

На счёт конторы. Само собой, я стороной обхожу конторы, в которых поклоняются классике ООП. Тк не все ребята смогут спокойно принять тот факт, что можно писать чище и иметь лучшую поддержку. Благо, работу меняю нечасто. И обычно ищу новые проекты, под которые нужно собрать команду. Или ищу проекты без ООП, в которых нужно отрефакторить проект (да, процедурщики без опыта и правильных паттернов в 95% скатывают проект в легаси. Совершенно не спорю).

Answer 8

[sta-ger]

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

Comments

[ixpl0]

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

Answer 9

[NSA-bot]

Советую почитать эту книжку. Она без привязки к конкретному языку, хотя там и есть примеры на java, но они максимально простые, только для объяснения теории.
https://vk.com/wall-54530371_3964