Неполцноенное ООП в javascript и значение этого?

Question

[werwer]

Многие говорят, что ООП в JavaScript неполноценное.
Я пока в изучении не нашёл кардинальных отличий.
Везде наследуются и так далее.

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

Comments

[Максим Федоров]

скорее всего статьи о неполноценности отличаются по годам от JS, которое вы изучаете

[werwer]

Максим Федоров, не совсем понял, в любом случае хотел бы понимать отличия ООП "нормальных языков" от "дваскрипта"

[Вадим]

Если Вы не читали этого, значит искать толком не пытались.
https://webdevblog.ru/chem-prototipnoe-nasledovani...
https://tproger.ru/translations/oop-js-fundamentals/
https://developer.mozilla.org/ru/docs/Web/JavaScri...

Если читали, то вопрос стоит конкретизировать.

Коротко - прототипное наследование более никзоуровневая история, на которой можно реализовать ООП, но не совсем в полном объёме. Хотя JS к этому движется. Но тот же class это обёртка над прототипом.

[Антон Воскобоев]

Неполноценными бывают только программисты.
В умелых руках прототипное ООП JavaScript - преимущество, а не недостаток.

Для осознания:
раз,
два,
три.

Answer 1

[mayton2019]

Тут нужно копнуть в историю и почитать для чего JavaScript созадавался. Какие цели и задачи перед ним ставились. Почитайте это интересно. И в части Lisp в браузерах - тоже.

Что такое вообще ООП применительно к теории и к конкретному языку? На сегодняшний день не существует канонической реализации ООП. Грубо говоря ни один язык не может претендовать на трушное ООП. Хотя другие ООП (класса строго типизированных) просто вводят больше ограничений на компилляцию
и рантайм запрещая на ходу менять тип объекта или внедрять в него новые методы и перегружать существующие.

JavaScript является таким себе податливым пластилином который разрешает очень многое делать
с объектами и именно это является объектом критики. Прототипирование вместо наследования и прочее.
JavaScript насколько я знаю расширяет спецификацию и все таки вводит понятие класса. Ключевое
слово есть. Это хорошо. Это его приближает к ООП и дает возможность больше проводить параллели с back-end например.

Есть языковые надстройки (транспилляторы) типа type-script которые вводят некий повышенный уровень
строгости по отношению к типам. Но Runtime насколько я понимаю по прежнему остается либеральным.

Вообще тема чистоты ООП - это достаточно трольная тема особенно на собеседованиях. Теоретики до сих
пор не могут посчитать сколько же свойств нужно для описания ООП. Там вроде как 3 свойства было или 4.
До сих пор нед единого трактования термина инкапсуляция.

Поэтому всех религоизных фанатиков ООП надо слать к чорту. А на собеседовании отвечать очень обтекаемо
и с отсылкой на всяких Кентов Беков и Фаулеров и Дядек Бобов. Пускай они там друг с другом договоряться
о терминологии а потом уж мы подтянемся.

Answer 2

[Станислав Макаров]

Ну во-первых, как заметил mayton2019 , не существует "полноценного ООП", т.к. в индустрии нет единой математической модели этого подхода. В отличие, например, от реляционной модели, для которой есть общепринятые термины о определения.

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

В C++ и C# есть классовое ООП, соединённое с номинативной стратегией типизации. В JS и Lua есть прототипное ООП, которое в TypeScript приправляется структурной типизацией. В Rust по сути нет наследования, но есть полиморфизм. В Ruby есть концепция метаклассов, которая не особо известна в других языках. Все делают по-своему, говорить, что в каком-то языке "истинное" ООП - глупо, потому что об этом нет договорённости.

Исторически есть две крупные "школы" ООП - школа языка SIMULA и школа языка Smalltalk, вот можете почитать об этом. К этим школам добавляется ещё прототипный подход, который впервые появился в языке Self, джаваскрипт тут Америку миру не открыл. История языков программирования вообще очень длинная и интересная штука, большинство идей в современных промышленных языках были изобретены значительно ранее в других языках, экспериментальных или академических.

JS как язык отвратителен не потому, что в нём "ненастоящее" ООП, а совсем по другим причинам.

с вашей идееологией интересно(с которой я согласен), как вы относитесь к тсу?

Вы спросили не у меня, но позволю себе ответить - TypeScript это лучшее, что было с JS, потому что он делает программирование на JS возможным. Обратите внимание - с точки зрения ООП тайпскрипт ничего нового не вносит, так что на мой взгляд дело вообще не в ООП. А например в том, что в JS никак бл..ь не доедут записи. Как можно в 2023 году программировать на языке без таких элементарных вещей? За что нам такое наказание?

Comments

[Станислав Макаров]

Но вообще конечно JS это рак в теле современного IT, а точнее результат нагибания Гуглом всех остальных платформ. Как я уже писал, если бы Гугл не захватил умы разработчиков, JS просто был бы ещё одним языком, далеко не всеми любимым. Который бы выбирали из числа Python, Go, Ruby.

[mayton2019]

Станислав Макаров, JS гораздо старше гугла. Я просто не понимаю в какой части этой схемы гугл что-то захватывал.

[Станислав Макаров]

mayton2019 Я понимаю что JS гораздо старше гугла, просто именно гугл сделал его достаточно быстрым, чтобы заманить на него и пользователей, и разработчиков. Понимаете, я не верю что сейчас есть некий абстрактный "веб" как независимая платформа для приложений. Эта платформа почти полностью гугловая. Я пишу этот коммент из ФФ, но кажется ему в ближайшие лет 7-10 трындец наступит.
Гугл отхапал себе знатный кусок в войне платформ, а никто будто этого не замечает, не пойму в чём дело.
Сам JS как язык нисколько не заслуживает быть единственным языком этой платформы (слава богу wasm наконец обретает своё влияние), но он именно такую роль сейчас играет. Просто потому что собрались лучшие умы и победили технологией здравый смысл, добавив в V8 всякие штуки вроде угадывания классов и прочие вещи касающиеся мономорфизма объектов.

[mayton2019]

гугл сделал его достаточно быстрым, чтобы заманить на него и пользователей

Где? Да где там этот пресс-релиз в котором гугл объявляет что он делал что-то для языка? Может ты просто путаешь с браузером Chrome?

Я пишу этот коммент из ФФ, но кажется ему в ближайшие лет 7-10 трындец наступит.

С чего это? Чел. Война браузеров закончилась еще лет 10 назад. Их осталось штук 5 и они распределились как ассеты по корпорациям.

слава богу wasm наконец обретает своё влияние

Какое влияние? Да откуда ты факты черпаешь? Что по твоему С++ или Rust разработчики пойдут
писать фронт енд? Или наоборот фронтовики бросят JS и станут учить более сложные языки?
Да зачем это им? JavaScript закрывает все потребности современного браузера. Даже игры
на нем пишут.

Позови сюда в топик разработчика который объяснит зачем ему нужен WASM и разработка
на нем веб приложений! Убедительно объяснит!

[Станислав Макаров]

mayton2019

Может ты просто путаешь с браузером Chrome?

Не, не путаю. Потому что фронтэнд - это и есть Хром. А если бы не фронтэнд - JS был бы... мало кому интересен. Не интереснее какого-нибудь Lua. Бэк на JS пишут на 80% потому, что уже знают JS, а не потому что это объективный выбор из 3-4 языков.

С чего это?

С того, что доля ФФ падает и по сей день. Не то чтобы Мозилла не была сама в этом виновата, но радостнее от этого не становится.

Какое влияние?

https://www.infoworld.com/article/3651503/the-rise...

Или наоборот фронтовики бросят JS и станут учить более сложные языки?
Да зачем это им?

Например мне вот нужно. Я не могу поменять проект, не могу стать бэкендером, я хочу писать фронт на нормальном языке. То что 90% разработчиков не видят дальше своего носа и вообще делятся на "лагеря" - это лишь следствие того, что им в общем-то плевать на то, что вокруг происходит, пока им за их работу платят. А даже если и хотят, допустим, пописать на Rust - ну они просто меняют проект/роль и идут куда-нибудь на бэк. Никто не пытается отвязать платформу (веб-фронтэнд) от JavaScript.

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

[Станислав Макаров]

mayton2019

Где? Да где там этот пресс-релиз в котором гугл объявляет что он делал что-то для языка?

Если бы гугл не пнул всех под зад (в хорошем смысле этого слова) своим движком V8, JS до сих бы тормозил настолько, что падающие снежинки на страничке жрали бы 100% процессора, как в 2004-м году.
Разумеется, вместо Гугла это могла быть другая компания - Mozilla, Microsoft, кто-то ещё - тогда мы б обсуждали эту компанию, а не Гугл.

[mayton2019]

Потому что фронтэнд - это и есть Хром.

Вот это заявление. Мне кажется мы живем на разных планетах. У вас - плюсовики сидят без
работы и за каким-то хреном кодят фронт. Может плохие плюсовики? У вас - не существует
линейки браузеров. У вас он почему-то заявлен один.

Даже не знаю стоит ли продолжать. С такой-то радикальной позицией.

[Станислав Макаров]

mayton2019

У вас - плюсовики сидят без работы и за каким-то хреном кодят фронт.

Работы у нас достаточно, просто не все в восторге от JS, мягко говоря, даже от современного.

У вас - не существует линейки браузеров. У вас он почему-то заявлен один.

https://www.oberlo.com/media/1686051830-most-popul...
Посчитайте, сколько тут браузеров. Именно движков, а не обёрток. Я вижу Хромиум и Сафари. Сафари, который ненавидят все веб-разработчики и который стремительно потеряет в популярности, если Apple отпустит хватку. ФФ плетётся где-то там, скоро его обгонит самсунговский браузер, которым пользуются только те, кто не может поставить Хром на мобилу. Где ваши пять браузеров? Обёртка не стоит ничего, по сравнению с движком. Обёртку много кто смог написать, а вот движок уже настолько сложный, что его никто написать с нуля не сможет за разумные деньги/время. А значит инициатива принадлежит тому, кто имеет основную долю влияния на существующий движок, решает какие API добавлять, какие функции реализовывать.

[Станислав Макаров]

mayton2019

У вас - плюсовики сидят без работы и за каким-то хреном кодят фронт.

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

[Станислав Макаров]

https://gs.statcounter.com/browser-market-share/al... - вот в 2010-м да, было побольше браузеров на свете.

[mayton2019]

Станислав Макаров, Стас я вот вообще не понимаю сути твоего возмущения. Как обиженный тик-токер.

Я только понял что тебе не нравится твое место работы? Вот меняй место работы.
Вот мне не нравился Oracle. Я ушел в разработку. Разработка надоела - я ушел в бигдату.
Надоест - пойду в сыроварню сыр варить.

[Станислав Макаров]

mayton2019 Вы никак не можете понять мою позицию: предметная/прикладная область разработки не должна быть настолько сильно связана с используемым языком, особенно когда это высокоуровневая разработка. Я это и хочу объяснить вам, что это ненормально - что если мне не нравится JS, я должен перестать делать фронт. А если мне нравится HTML и CSS как языки вёрстки интерфейсов (это не совсем так, ну допустим что так)? В мире придумали кучу ОТЛИЧНЫХ языков программирования, почему я не могу сменить только язык? Почему целая КОМАНДА опытных людей не может сменить язык, продолжая делать ту часть продукта, которую они делают?

Вы смотрите с позиции "надоест - уйду", т.е. вам не интересна инициативная позиция "надоест - переделаю". Позиция "надоест - уйду" имеет полное право на жизнь, но она перестала для меня быть привлекательной. Поэтому да, я возмущаюсь, причём системно, и поддерживаю инициативы по смене текущего состояния дел. Меня беспокоит то будущее, куда мы идём в обнимку с этим самым JS.

В концепцию что всё само придёт к правильному состоянию и само уляжется оптимальным образом я в последние несколько лет тоже не совсем верю. Компилировать TS в JS, теряя информацию о типах, чтобы потом V8 в целях оптимизации опять угадывал, в каких переменных какие типы данных могут быть - это технологический идиотизм. Я прекрасно понимаю, как мы к этому пришли, но не вижу для себя оправданий сидеть и любить то, что получилось.

[WbICHA]

Станислав Макаров, не понимаю, почему ты считаешь, что стал столь популярным именно из-за гугла? Жс был задолго до хрома и это был единственный язык, который поддерживался всеми актуальными браузерами. Очевидно, что пихать поддержку какого-то другого языка было бы очень странно.
Имхо, куда больший толчок жсу дало появление ноды. Да, нода использует в8, но с тем же успехом она могла бы использовать паукообезьяну.

[Станислав Макаров]

galeyraf В большинстве языков программирования, где представлена концепция объекта в том или ином виде, также есть и концепция записи. Концепция объекта подразумевает важную штуку, которая называется object identity (даже целая статья на вики есть). Это значит, что при сравнении объектов нас прежде всего интересуют некие их идентификаторы, а не содержимое их полей. Это согласуется с тем, что объект это обычно чёрный ящик, и внешний код не может работать напрямую с полями объекта (со всеми или с большинством). Кроме того, это полезно и при моделировании реального мира - даже если у двух объектов Студент имя, фамилия и отчество полностью совпадают, это не значит что это один и тот же человек. Тут в JS всё в порядке - объекты действительно сравниваются по ссылке, а не по значению (содержимому), как и в других языках.

Но есть куча ситуаций, когда это identity совершенно лишнее. Например, я хочу сохранить в переменной RGB-цвет. Цвет полностью определяется численными значениями своих компонент. Мне нет никакого смысла добавлять к нему ещё дополнительную информацию в виде object identity и говорить, что вот этот цвет (10, 50, 70) НЕ РАВЕН цвету (10, 50, 70) только потому, что цвета - это объекты, и у них не совпадают identity (т.е. ссылки, если говорить про JS). Ну глупо же звучит? Но при этом в JS именно так и будет происходить - т.к. композитные значения я могу сделать только объектами (ну или массивами в частности), мне придётся для их сравнения городить огород с вызовом каких-то кастомных функций сравнения. Я не смогу просто вызвать оператор === для этого. В других языках такой проблемы нет, например в C#.

Я бы даже сказал, что записи - это куда более базовая вещь, чем объекты. Записи и кортежи - это декартово произведение входящих в них компонент. А вот уже объект - это по сути инкапсулированная запись, с добавленным к ней identity и методами для реализации поведения.

Кроме того, правильные записи должны быть иммутабельны - ведь если я поменяю у цвета красный компонент с 10 на 20, это будет уже другой цвет. А для объектов наоборот, менять состояние - это абсолютно нормально, они для этого и придуманы. Потому что у них всегда есть неизменяемое identity в течение всего времени жизни, как бы там внутреннее состояние объекта не изменялось.

Собственно ничего нового я вам не сказал, есть куча статей по сравнению объектов и записей как концепций.

[Станислав Макаров]

WbICHA если б дело было в Ноде, мы бы сейчас видели в каждой вакансии с JS какой-нибудь Express или Koa. Но что-то везде я вижу React да Vue :D .

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

Конечно, полностью согласен. Я ж не говорю что необходимо было другой язык добавлять, я говорю что может не стоило из браузера делать операционную систему и переписывать всё, вплоть до Ворда и Фотошопа только чтобы засунуть это в браузер?) А вот когда всё-таки решили засунуть в браузер вообще всё, тогда конечно уже не помешал бы другой язык исполнения. Собственно достойных попыток было немало - ActiveX-документы (хотя конкретно эта попытка была хреновая), Java-апплеты, Flash, Silverlight... Всё это либо вообще не взлетело толком, либо уже отслужило свой срок. А Гугл взял и вместо выкатывания новой, вендорской технологии, просто ускорил стандартный JS и HTML до небес. И тогда вроде бы написанное приложение работает во всех браузерах - разработчикам очень удобно. Но в Хроме оно работает быстрее всего, поэтому пользователи ставят себе Хром. Отличная схема пересадки на свой браузер, никакого обмана (без сарказма). Только теперь, когда все пересели, можно контролировать эту платформу как хочешь. Особенно удобно предоставлять рекламные сервисы - AdSense куда проще встроить в HTML-приложение, нежели, к примеру, в десктопное приложение на WPF.

[Станислав Макаров]

galeyraf

это можно назвать составным простым значением

Вот именно! В точку, это оно и есть! Т.е. такое же по своей семантике как number или boolean, только составное.

простота инструмента это ценность

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

То же самое и про ЯП: всё хорошо до тех пор, пока ты можешь выразить свою мысль, смоделировать задачу. А программу мы пишем прежде всего для других разработчиков, а не для компьютера, и тут в игру вступают совершенно другие вещи. Легко писать программы в одиночку. Сложнее, когда вас трое. И сильно сложнее, когда вас уже 100-150 человек. Нужно уже как-то передавать свои идеи и решения другим разработчикам с помощью языка программирования. Собственно именно поэтому TypeScript и появился.
На работе разработчики код в основном читают, а не пишут, и общаются друг с другом во многом через код. У меня нет задачи сверстать страничку к вечеру, мне нужно решать сложные вещи в большом проекте, которые должны проработать не один год и не ломаться каждый день. И мой код будут читать годы спустя, я может уже не буду работать в этой компании.

[mayton2019]

galeyraf, у записей часто есть синоним Tuple (кортеж). Это такое себе ультра-легкое объявление
объединения из нескольких переменных. При этом декларация базового имени записи не обязательна.
К примеру если мне надо сделать преобразование комплексного числа (double, double) то я могу объявить функцию следующим образом

На гипотетическом языке

def transformComplexNum(double Re, double Im) : { double, double } = 
    return { .... , ..... };

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

В JavaScript мне кажется Records не особо нужны. Там есть скобочный синтаксис для генерации
объектов на лету. По поводу иммутабельности ... ну можно порассуждать нужно это или нет.

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

Tuples есть в Питоне и в Scala. И современный С++ тоже их реализует через синтаксический сахар.

[Станислав Макаров]

galeyraf mayton2019 записям нужна иммутабельность ровно по той же причине, по которой целочисленному значению 5 нужна иммутабельность. Странно же задавать вопрос, мутабельно ли значение 5, не так ли?

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