В каких случаях использовать Class, а в каких function (js)?

Question

[Михаил Р.]

Приветствую!

Изучаю ооп js и возник вопрос, здесь говорится о Class и простых function. Изучаю исходник vue, там про Class не слова, одни function.

Вопрос: стоит ли использовать Class, и если да, то в каких случаях?

Спасибо!

Answer 1

[Дмитрий Евграфович]

вообще классы - это синтаксический сахар для функций, но пока что это не полноценные классы, какие есть в других языках и даже в сравнении с 'классами' на функциях их возможности урезаны, поэтому их применение несколько сомнительно. Захотите приватные свойства, например, а их нет. Поэтому лучше на функциях (или typescript/dart)

Comments

[Антон Спирин]

...поэтому их применение несколько сомнительно

Что за логический кульбит? Классы это удобный лаконичный синтаксис, снижающий когнитивную нагрузку. Использовать их можно только ради этого.

[Дмитрий Евграфович]

Антон Спирин, кульбит основан на том, что классы в 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, а обычные классы) применимы на нескольких примерах, то будет очень полезно.

Answer 2

[Никита Егоров]

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

Comments

[Антон Спирин]

это просто синтаксический сахар

Не совсем. Попробуйте повторите без использования классов.