@beginer123

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

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

Далее просто использовать их как конструктор друг за другом или друг в друге
Я пишу программы всегда так, пытался переписать используя классы, но честно так и не понял в чем будет преимущество, все только запутанее становиться, решил оставть функции
В чем же преимущество ООП? На конкретном примере
  • Вопрос задан
  • 695 просмотров
Пригласить эксперта
Ответы на вопрос 9
Ptolemy_master
@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

Заметна разница?
Ответ написан
zolt85
@zolt85
Программист
Из Википедии:

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


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

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

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

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

По поводу примера, попробуйте реализовать подобный органайзер: https://www.wed-expert.com/organizer.
Как по мне, тут сразу же видно сущности: категория и элемент (от него наследуются: задача, гость, затрата).
После того как вы опишите данные сущности, весь код будет представлять из себя оперирования этими объектами (добавить, удалить, редактировать).
Если говорить про какой-нибудь React, то с его компонентной "идеологией", используя сущности очень реализовать.
Ответ написан
Комментировать
PaulTMatik
@PaulTMatik
ФП vs ООП старо как мир. Интерпретатору/компилятору абсолютно фиолетово какой стиль вы используете. Есть задача — она должна решаться, если ваш код её решает, используя, конечно же, минимум ресурсов, то какая разница как он написан.
Некоторые языки взяли за основу, конкретные парадигмы, например только ООП, в таких языках, естественно, всё будет ориентировано на это, поэтому писать на них как-то иначе — менее продуктивно и ещё менее понятно для другого программиста.
Удобство какого либо подхода — это субъективно. Если вы пишите на языке, который допускает использование любого подхода, то выбирайте тот, который больше нравится. Если только у вас нет комплексов, что кому-то узколобому ваш прекрасно работающий код покажется смешным, из-за того, что вы выбрали ФП вместо ООП.
Ответ написан
EnDeRJaY
@EnDeRJaY
cout >> "Hello World!" >> endl;
В чём удобство?
Раньше сам задумывался, не понимал что хорошего в классах?А потом понял, что лень это двигатель прогресса.В том смысле что ты однажды написал класс в хэдере и пользуйся им на здоровье.
В чём же преимущество ООП?На конкретном примере.
Допустим, есть две фабрики.Обе выпускают машины, но подход разный.Одни используют функции, а другие классы.У тех кто используют функции проблемы, потому что заказов много, а чтобы их сделать нужно вызвать много функций.А у тех кто используют классы, их нет, поскольку они один раз написали класс и теперь всё время его вызывают простым auto Renault(Logan);.
Также с наследованием и полиморфизмом
Вышли две новые машины, которые унаследовали что-то от старой и этим фабрикам пошли заказы.Первые начали писать тонны функций, а вторые добавили в базовый класс к унаследованным функциям приставку virtual
Вот тебе польза наследования и полиморфизма.
Ну с инкапсуляцией легко, хотя достичь её непросто.Нужно просто не вдаваться в детали.Как, с кнопками громкости в пульте.Ты можешь только переключать на "Громче" или "Тише", но ты не можешь выбрать определённый уровень громкости, ведь ты рано или поздно доберёшься до него.Инкапсуляция скрыла от тебя детали.И у классовиков тоже инкапсуляция.Они один раз написали класс и он будет работать, и им не важно как, главное работает и они получают что хотят.

P.S.
Я много бурды наговорил, но это моё понимание ООП
Ответ написан
jamakasi666
@jamakasi666
Просто IT'шник.
ФП и ООП можно сравнить с БД, К примеру:
1) Вся БД это одна единственная таблица в которую придется складывать вообще все. Это грубо говоря подход ФП.
2) Вся БД разбита на кучи таблиц в каждой из которых хранятся данные своего типа. Это ООП.
Для маленькой простой программы будет проще первый вариант а второй окажется диким оверхэдом, для большой и сложной программы впринципе можно задействовать первый вариант но он будет дико неудобным и запутанным а второй вариант крайне удобным и в савокупности кода станет меньше и он будет менее запутан.
Ответ написан
@sta-ger
Game Developer
ООП дисциплинирует. ФП хорошо применимо в небольших проектах, которые делаются, так сказать, "на скорую руку". Для крупных, масштабируемые проектов, над которыми работают несколько людей ООП необходимо. Поработаете с крупным проектом - поймете.
Ответ написан
NSA-bot
@NSA-bot
Советую почитать эту книжку. Она без привязки к конкретному языку, хотя там и есть примеры на java, но они максимально простые, только для объяснения теории.
https://vk.com/wall-54530371_3964
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы