вообще классы - это синтаксический сахар для функций, но пока что это не полноценные классы, какие есть в других языках и даже в сравнении с 'классами' на функциях их возможности урезаны, поэтому их применение несколько сомнительно. Захотите приватные свойства, например, а их нет. Поэтому лучше на функциях (или typescript/dart)
Антон Спирин, кульбит основан на том, что классы в js не позволяют мне делать то, что я могу делать с помощью классов в других языках из-за их кастрированности. А то, что позволяет - реализуется хаками к функциям либо расширениями javascript. Но не классами. Я не спорю о том, что они более лаконичны и красивы, но до других языков они не дотягивают. Мне классы нужны как полноценный элемент, с помощью которого я смогу реализовать архитектуру, а не как обёртка для пары геттеров.
Антон Спирин, использование интерфейсов, использование приватных свойств, множественное наследование или трейты. И давайте сразу разделю, проблем с реализацией не возникает, потому что рабочий код можно написать вообще без использования ооп, а можно подключить typescript. Но конкретно без этого мне не хватает в классах.
Можно использовать TypeScript или Flow. Тут претензии не к синтаксису классов, а к прототипной природе JavaScript.
использование приватных свойств
С самого рождения в JavaScript существует договоренность насчет приватных свойств и методов. Поэтому записывать это в недостатки так себе аргумент. Отсутствие этого ключевого слова никак не мешает решению задач, а видимость за пределами модуля решается ключевыми словами export и export default.
множественное наследование
Во многих отличных ООП языках его нет. И более того, если вам во фронтенде могло понадобиться множественное наследование, то скорей всего эта необходимость вызвана ошибками проектирования.
Сама часть посыла вашего ответа о том, что предпочтительней использовать функции очень сомнительна и пока конструктивно ничем не аргументирована.
Можно использовать TypeScript или Flow. Тут претензии не к синтаксису классов, а к прототипной природе JavaScript.
Так я это сказал в ответе, упомянув typescript и dart, которые все это позволяют, мы ведь говорим о недостатках родных классов, а не о тайпскрипте, который появился, чтобы это исправить. Если бы автор задавал вопрос "чем тайпскрипт лучше родных функций js", ответ был бы совршенно иным. Но мы говорим о родных классах.
С самого рождения в JavaScript существует договоренность насчет приватных свойств и методов. Поэтому записывать это в недостатки так себе аргумент. Отсутствие этого ключевого слова никак не мешает решению задач, а видимость за пределами модуля решается ключевыми словами export и export default.
Самое рождение javascript состоялось более 20 лет назад. За это время появилось куча новых подходов и методов в разработке, изменились сами требования к программам и если 20 лет назад js использовался для выведения алертов на страницах, то теперь это полноценные приложения, в том числе на телефонах и серверах. И кивать на договоренности 20-летней давности относительно языка, написанного для легкого кода в условиях, когда требуются инструменты для написания сложного кода - так себе аргумент. Export default - не та опера. Мы не о языке говорим, а сравниваем конкретные конструкции, которые были упомянуты в вопросе - классы и функции.
Во многих отличных ООП языках его нет. И более того, если вам во фронтенде могло понадобиться множественное наследование, то скорей всего эта необходимость вызвана ошибками проектирования.
Отлично. Ошибки проектирования. А если мы проектируем бэкенд? А если мы проектируем приложение для телефона? А если это тот редкий случай, когда пишется действительно сложный фронт?
Вообще одно другому не мешает, если язык не умеет чего-то, то очевидно, что требование этого умения от него - это ошибка проектирования. И тут нужно либо выбирать другой инструмент, либо писать так, как может язык. Но вот только если эта возможность появится в языке, ошибка проектирования перестанет быть ошибкой и превратится в лучшую практику. Js не умеет в интерфейсы ровно так же, как в множественное наследование, но вы ведь необходимость интерфейсов в ошибку проектирования не станете записывать? Или станете?
Родные классы синтаксический сахар. У самого их синтаксиса в рамках возможностей языка недостатков нет.
А в ответе вы в ответе утверждаете, что функциональный синтаксис предпочтительней и лучше для использования. Именно с этим утверждением я и не согласен. Тем более, ни одного объективного аргумента именно на эту тему вы не предоставили.
И кивать на договоренности 20-летней давности относительно языка, написанного для легкого кода в условиях, когда требуются инструменты для написания сложного кода - так себе аргумент.
Это отлично работает и все это используют. Никаких неудобств это не приносит ни на телефонах, ни на серверах. Объективных недостатков, при решении задач договоренность не имеет. Ну и вводят в стандарт приватные свойства и методы.
А если это тот редкий случай, когда пишется действительно сложный фронт?
я пишу только очень сложный фронт(крупные стартапы, финтех, социальные сети). Наследование используется только:
class SomeComponent extends Component {
}
Что-то более, очень редкий кейс. Множественное наследование просто-напросто не нужно. В таких языках как например Java, C#, Swift оно отсутствует.
но вы ведь необходимость интерфейсов в ошибку проектирования не станете записывать? Или станете?
За последние годы вещи, которые реализуют на JS стали значительно сложней. Учитывая реалии проектов в которых работаю, лично я, без статической типизации и интерфейсов подобные проекты лучше не начинать.
Вас куда-то в сторону потянуло от начального утверждения, что функции использовать предпочтительней, а классы нет смысла, на недостатки отсутствия интерфейсов и типизации в больших проектах.
Родные классы синтаксический сахар. У самого их синтаксиса в рамках возможностей языка недостатков нет.
А в ответе вы в ответе утверждаете, что функциональный синтаксис предпочтительней и лучше для использования. Именно с этим утверждением я и не согласен. Тем более, ни одного объективного аргумента именно на эту тему вы не предоставили.
Родные классы - синтаксический сахар, который реализует половину возможностей, предоставляемых объектами на функциях. Поэтому в случаях, когда нужен более полный доступ, придется использовать что-то помимо классов, например те же функции, которые лежат в основе классов.
Это отлично работает и все это используют. Никаких неудобств это не приносит ни на телефонах, ни на серверах. Объективных недостатков, при решении задач договоренность не имеет. Ну и вводят в стандарт приватные свойства и методы.
Я бы согласился, да вот только в реальном мире люди испытывают неудобства и именно из-за этого появился typescript с dart и прочими надстройками. Из-за недостатков, которые вы так упорно отрицаете.
Это отлично работает и все это используют. Никаких неудобств это не приносит ни на телефонах, ни на серверах.
Да разумеется не приносит, только с этим удобнее. Вот только когда это все появится в js, все начнут говорить, что это очень удобно и вообще js впереди планеты всей потому, что там есть нормальная поддержка ООП.
я пишу только очень сложный фронт(крупные стартапы, финтех, социальные сети). Наследование используется только... Что-то более, очень редкий кейс. Множественное наследование просто-напросто не нужно. В таких языках как например Java, C#, Swift оно отсутствует.
Если мы говорим о наследовании классов - согласен, это не самая распространенная практика и куда более удобно вставить нужные трейты в класс (поправьте, если ошибаюсь, но в упомянутых вами языках миксины или трейты присутствуют. Но могу ошибаться. В классах js этой конструкции как таковой нет). На выходе получается то же множественное наследование, но под другим названием. Плюс множественное наследование можно применять к интерфейсам и это довольно частый кейс, когда тот или иной класс реализует несколько интерфейсов.
Вас куда-то в сторону потянуло от начального утверждения, что функции использовать предпочтительней, а классы нет смысла, на недостатки отсутствия интерфейсов и типизации в больших проектах.
Так, давайте по порядку. Я говорю, что в сравнении с функциями классы кастрированы потому, что не позволяют сделать то, что позволяют сделать функции. Например задать те же приватные свойства. А еще я указываю на кастрированность классов в js в сравнении с другими языками и говорю, что в них в сравнении с другими языками нет возможности множественного наследования и реализации интерфейсов. Вы же сами спросили, с какими задачами на фронтэнде у меня возникают проблема ПРИ ИСПОЛЬЗОВАНИИ КЛАССОВ. Не при использовании js вместо typescript, а при использовании классов. я вам ответил в контексте классов. Дальше понеслось, что множественное наследование не нужно, что на фронтэнде нет таких задач или они редкие, что в рамках языка у них нет недостатков, но я изначально не говорил об этом, это уже вы начали добавлять. Я изначально говорил лишь о том, о чем говорил.
Антон Спирин, вообще знаете, вы правы, я слишком категоричен был. Просто рассматриваю классы с точки зрения написания полноценного mvc приложения, хотя они вполне могут использоваться для написания небольших либ с набором хелперов типа lodash. Если напишите автору в отдельном ответе, когда классы в js (не модули и классы ts, а обычные классы) применимы на нескольких примерах, то будет очень полезно.
JavaScript - удобный язык, если разработчик хочет использовать разные стили программирования.
В js если хотите использовать ООП, можете использовать прототипный стиль или же функциональный.
Используя классы - не вводится новая объектно-ориентированная модель, внутри все те же прототипы, это просто синтаксический сахар
Сложный
