Какое наиболее удобное решение написания класса на JS?
Уважаемые разработчики, какую библиотеку на JavaScript или подход вы исспользовали для того чтобы класс был наиболее читабелен? Желательно чтобы именно библиотека и JavaScript.
До обраного В обраному 0
Схожі топіки 50 коментарівКакое наиболее удобное решение написания прототипного наследования на Java?
Отличная шутка. А в ES6 классы уже появились.
Мені одному хочеться зробити щось недобре з людьми, які використовують термін «клас» в контексті JavaScript? Вот немає тут класичного відношення клас — екземпляр класа. Як на мене, використання терміну «клас» тут більше заплутує чим пояснює. А те, що в ES6 зробили ще і синтаксичний цукор з ключовим словом class — взагалі щось надзвичайне.
Звісно, плутанина виникає в основному в тих, для кого js — не перша мова програмування. Ну. а для тих, для кого перша . варто побажати їм удачі, коли будуть розбирати ортодоксальне ООП в інших мовах.
Ваши проблемы. С моей точки зрения ключевое слово класс в контексте JavaScript вполне уместно ввели.
ввели для неосиляторов же :)
Хех, вот мої проблеми з цим як раз закінчились, коли я чуть більше ніж повністю перестав асоціювати «класи» в JavaScript з класами, скажем, в Java. В цей момент все швидко стало на свої місця.
Як на мене, різні речі важливо називати різними словами. В іншому ж випадку виникає плутанина. І проблема не в тому, що «комусь не дано», а проблема в тому це забирає час на рівному місці в купи людей, а користі не приносить.
Один знайомий, який багато працював з JavaScript, якось сказав, що це дуже круто, що в JavaScript часто попадаються заплутані речі. А круто лише тому, що . йому платять більше, за те, що він це шарить :)
вот честно, удобнее говорить что в JS класс написан, чем функция-конструктор. удобнее говорить людям что это класс наследует такой-то, а не с установленным прототипом другой функции-конструктора.
сахар нужен. как в языке человеческом так и в самом JS.
хотя считаю что люди должны понимать, что находится за этим сахаром, если они его используют
хз. тут справа звички. В js наслідування специфічне і замість «клас A наслідує клас В» краще використовувати «об’єкт A має прототип об’єкт B». Доречі. а так подумати. що ви розумієте під «клас A наслідує клас В»? Там ж методів «наслідування» не один є. Ваше твердження не можна зрозуміти з прив’язкою до мови як такої, потрібно обов’язково знати в контексті якої моделі «наслідування» йде мова.
метод наследование в джс один — цепочка прототипов, другого «наследования» в нем не существует. а то что ктото миксины называет «наследованием», «наследованием» это не сделаетпроверка проста:
ok, хай буде так. Тільки тепер, якщо погуглити, кожен автор винаходить свій спосіб «правельної» прив’язки Child.prototype до чогось типу new Parent(), «правельний» спосіб викликати батьківський конструктор в нащадку і багато інших «правельних» речей, які в JS зовсім не в тему, але активно використовуються в інших мовах програмування.
В результаті, маємо вермішель з прототипів, замикань та call/apply, які, до речі, зовсім не стандартизовані і в кожного свої.
на самом деле способ один, это когда у функции-конструктор в прототипе установлен объект у которого в прото находится прототип родительской функции-конструктора — это единственное наследование которое есть в джс. просто некоторый добавляют всякой ерунды время от времени, но если удовлятворяется приведенное условие, то детали не важны.
и еще. выше я дал абсолютно точное описание того что является в джс наследованием — так вот, можете считать меня лентяем но мне проще сказать класс, и меня все поймут почемуто, чем пытатся каждый раз говорить то что написано выше
Тобто, з ваших слів, класом в JS можна називати будь-яку функцію А, для якої є семантичний сенс написати «. instanceof A». Більш ніяких властивостей цих сутностей не фіксується і вони можуть мінятися від реалізації до реалізації. Я вірно зрозумів?
класс в джс = функция-конструктор + определенный прототип (последнее не обязательно, но без него нет смысла создавать функции-конструктор, за исключением очень редких кейсов)именно это подразумевается под классом в джс
Так, соррі. Я щось подібне хотів написати про наслідування. Не важливо, насправді. Ідея була в тому, щоб кінець-кінцем показати, що багато паралелей з ортодоксального ООП проводити не варто тут.
А питання автора теми було більше схоже на пошук бібліотек (!), які якісь з фітч ортодоксального ООП переносять в JS. Ви погодились серед своїх слів з тим, що різні бібліотеки це роблять різним чином (в тому числі і mixin-ом). І я хотів сказати, що не варто це робити (через костилі робити ООП фітчі в JS).
Так что это скорее личные привычки и предпочтения, когда хочется или привык оперировать понятием, которого почему-то нет в JS.
на самом деле такого понятие/термина не существует, и самый близкий является как раз класс, ибо если мы связываем прототип с функцией-конструктором то мы говорим о контракте/интерфейсе для экземпляров которые будут созданы при помощи функции-конструктора.
Формально, перед любой функцией можно поставить new. Я же предложил назвать термином «конструктор» функцию, которая специально для этого рассчитана чтобы быть вызванной с new. То есть, «функция, которая специально написана» — это, среди прочего, означает что она использует прототип. Остальные функции я «конструкторами» предлагаю не называть, а называть их просто «функциями».
Просто сойдемся на том что «такого термина в JS нет». А то будем так выдумывать каждый сам себе свои термины, и доказывать остальным что «это так будет всем удобно». А когда такой (или какой-то еще) термин официально появится в JS, тогда и разговор будет предметным.
Не ссортесь, я вас помирю. Вы оба от части правы.Термин «класс» есть. Он существует как в контексте JS, так и вне его.Так вот «класс» это ни что иное как паттерн (да, тот самый паттерн ООП, как другие типа синглтон, фабрика и т.п.). И при помощи этого паттерна могут создаваться объекты, потом реализовываться наследование и т.д.
В разных языках этот паттерн выглядит по разному, где-то он выражен простым ключевым словом class, а в JS стандарта ES5 и более ранних данный паттерн реализуется через функцию. Вот и всё.
Поэтому утверждение, что в JS классов нет вполне верное. Однако есть паттерн, называющийся «класс», который реализует поведение подобное поведению классов в других языках программирования.
именно это я и пытаюсь объяснить Дмитрию
А что не так с классами в ES6?
знания одного языка не мешает использовать другой, если мешает, то значит человек просто не знает этот другой
Мені важко судити про саме ваш досвід. Але як ви, скажем, розумієте фразу «клас А наслідує клас В» в контексті JavaScript? Ви ж маєте знати, що способів «наслідування» там є багато. Звідки ви знаєте який мається на увазі саме зараз?
Это нормально если в каком-нибудь языке свое понятие «класс» если он соответствует определенному множеству объектов в абстрактном понимании, классическое понятие «класс» — в математике, а не в «ортодоксальном ООП»
А чем Вас стандартные возможности ES5 с прототипным наследованием и подмешиваниями не устраивают? В ES6 синтаксический сахар ввели, ничего нового, если есть возможность- используйте его. Сам я пока еще на ES5, так как местами один и тот же код и на сервере и клиенте должен работать, а с ES6 на клиенте пока туговато.
Тоже пишу на кофескрипте, больше нравится чем ES6(babel)Вот, например, как выглядит у меня Абстрактный сервис и его наследник.gist.github.com/. zo0m/a4f9e8852dc574654423
function MyClass() чим такий підхід незручний? Добавляй методи, наслідуй від інших класів, використовуй mixins. Одним словом насолоджуйся ООП. Наскільки я знаю, для цього не потрібні бібліотеки.
А я жаваскрипт до сих пор не очень понимаю, но если надо классы — пишу на кофискрипте, а тот сам их волшебным образом превращает в эти ваши замыкания и прототипы.
а потом отакие темы штампуют
Даже не знаю, как мое сообщение коррелирует с той темой.
Ща тут начнётся, набегут матёрые теоретики и начнут учить что классов в JS нет и вы ничего не понимаете.Никакие не использую, стандартных средств хватает. Для удобочитаемости нужно придумывать хорошие имена переменных, придерживаться например правила называть «приватные» поля с _, можно ещё jsDoc использовать. IDE от JetBrains последний понимают, можно описывать свои типы данных и получать подсказки и автокомплит.
О правильности пусть судит браузер. Вопрос стоял конкретно: удобочитаемость. Мой рецепт — решать вопрос при помощи коментов, пока это возможно.
Я не спорю, что есть тяжёлые задачи для javascript. Например игры и прочие программы с охренительно долгим временем жизни, добавлением плагинов, интернационализации, и конечно мегатонн рекламного счастья. Но тогда бы и вопрос стоял иначе.
В подавляющем большинстве случаев JS — это тонкий клиент. А тяга писателей кода сделать их говна конфетку, к сожалению, не оправдывает надежд. Получается всё то же говно, но в фантиках.
Решение в общем случае — меньше кодить, больше комментить. В JS нет средств сделать код хорошим сам по себе. Равно как его нет и в CSS, и в XSLT, и в прочих попытках «упростить» кодирование перекладыванием работы с компьютера на человека. А для человеков лучше писать на их языке, то есть коментить — так дешевле выйдет и быстрее.