Какое наиболее удобное решение написания класса на JS?
Уважаемые разработчики, какую библиотеку на JavaScript или подход вы исспользовали для того чтобы класс был наиболее читабелен?
Желательно чтобы именно библиотека и JavaScript.
Facebook
Twitter
LinkedIn
Богдан Лысенко
var Animal = (function(){
var Animal = function() {
};
Animal.prototype.doSomething = function() {
console.log('do something');
};
return Animal;
})();
var Cat = (function(Animal){
var Cat = function() {
};
var parent = Animal;
Cat.prototype = new parent();
Cat.prototype.constructor = Cat;
Cat.prototype.doSomething = function() {
parent.prototype.doSomething.call(this);
console.log('do something more');
};
return Cat;
})(Animal);
var cat = new Cat();
cat.doSomething();
Dmytro Volkov
Какое наиболее удобное решение написания прототипного наследования на Java?
Андрей Литвинов
Отличная шутка. А в ES6 классы уже появились.
Igor Lytvynenko
Мені одному хочеться зробити щось недобре з людьми, які використовують термін «клас» в контексті JavaScript? Вот немає тут класичного відношення клас — екземпляр класа. Як на мене, використання терміну «клас» тут більше заплутує чим пояснює. А те, що в ES6 зробили ще і синтаксичний цукор з ключовим словом class — взагалі щось надзвичайне.
Звісно, плутанина виникає в основному в тих, для кого js — не перша мова програмування. Ну.... а для тих, для кого перша ... варто побажати їм удачі, коли будуть розбирати ортодоксальне ООП в інших мовах.
Ваши проблемы. С моей точки зрения ключевое слово класс в контексте JavaScript вполне уместно ввели.
Oleksandr Tkalenko
Igor Lytvynenko
Хех, вот мої проблеми з цим як раз закінчились, коли я чуть більше ніж повністю перестав асоціювати «класи» в JavaScript з класами, скажем, в Java. В цей момент все швидко стало на свої місця.
Як на мене, різні речі важливо називати різними словами. В іншому ж випадку виникає плутанина. І проблема не в тому, що «комусь не дано», а проблема в тому це забирає час на рівному місці в купи людей, а користі не приносить.
Один знайомий, який багато працював з JavaScript, якось сказав, що це дуже круто, що в JavaScript часто попадаються заплутані речі. А круто лише тому, що .... йому платять більше, за те, що він це шарить :)
вот честно, удобнее говорить что в JS класс написан, чем функция-конструктор. удобнее говорить людям что это класс наследует такой-то, а не с установленным прототипом другой функции-конструктора.
сахар нужен. как в языке человеческом так и в самом JS.
хотя считаю что люди должны понимать, что находится за этим сахаром, если они его используют
хз... тут справа звички. В js наслідування специфічне і замість «клас A наслідує клас В» краще використовувати «об’єкт A має прототип об’єкт B». Доречі... а так подумати... що ви розумієте під «клас A наслідує клас В»? Там ж методів «наслідування» не один є. Ваше твердження не можна зрозуміти з прив’язкою до мови як такої, потрібно обов’язково знати в контексті якої моделі «наслідування» йде мова.
метод наследование в джс один — цепочка прототипов, другого «наследования» в нем не существует. а то что ктото миксины называет «наследованием», «наследованием» это не сделает
проверка проста:
function Parent () {}
....
function Child () {}
....
if (new Child() instanceof Parent) {
console.log('Child inherited from Parent')
}
ok, хай буде так. Тільки тепер, якщо погуглити, кожен автор винаходить свій спосіб «правельної» прив’язки Child.prototype до чогось типу new Parent(), «правельний» спосіб викликати батьківський конструктор в нащадку і багато інших «правельних» речей, які в JS зовсім не в тему, але активно використовуються в інших мовах програмування.
В результаті, маємо вермішель з прототипів, замикань та call/apply, які, до речі, зовсім не стандартизовані і в кожного свої.
на самом деле способ один, это когда у функции-конструктор в прототипе установлен объект у которого в прото находится прототип родительской функции-конструктора — это единственное наследование которое есть в джс. просто некоторый добавляют всякой ерунды время от времени, но если удовлятворяется приведенное условие, то детали не важны.
и еще. выше я дал абсолютно точное описание того что является в джс наследованием — так вот, можете считать меня лентяем но мне проще сказать класс, и меня все поймут почемуто, чем пытатся каждый раз говорить то что написано выше
Тобто, з ваших слів, класом в JS можна називати будь-яку функцію А, для якої є семантичний сенс написати «... instanceof A». Більш ніяких властивостей цих сутностей не фіксується і вони можуть мінятися від реалізації до реалізації. Я вірно зрозумів?
класс в джс = функция-конструктор + определенный прототип (последнее не обязательно, но без него нет смысла создавать функции-конструктор, за исключением очень редких кейсов)
именно это подразумевается под классом в джс
Так, соррі. Я щось подібне хотів написати про наслідування.
Не важливо, насправді.
Ідея була в тому, щоб кінець-кінцем показати, що багато паралелей з ортодоксального ООП проводити не варто тут.
А питання автора теми було більше схоже на пошук бібліотек (!), які якісь з фітч ортодоксального ООП переносять в JS. Ви погодились серед своїх слів з тим, що різні бібліотеки це роблять різним чином (в тому числі і mixin-ом). І я хотів сказати, що не варто це робити (через костилі робити ООП фітчі в JS).
Dmytro Volkov
вот честно, удобнее говорить что в JS класс написан, чем функция-конструкторУдобнее кому? Общаясь с разработчиками на JS я не раз слышал слово «объект», «прототип», «конструктор», но не слышал слово «класс». И при этом отлично их понимал, и они вроде бы не чувствовали неудобства при таком общении.
Так что это скорее личные привычки и предпочтения, когда хочется или привык оперировать понятием, которого почему-то нет в JS.
Удобнее кому?людям
Общаясь с разработчиками на JS я не раз слышал слово «объект», «прототип», «конструктор»ок, а как вы собираетесь назвать одним словом фукнцию-конструктор с ее прототипом? может я какого-то термина не знаю, просветите пожалуйста
ок, а как вы собираетесь назвать одним словом фукнцию-конструктор с ее прототипом?Я бы назвал это «конструктор». А то что возвращает конструктор я бы назвал «объект». Как по мне, это и просто, и удобно, и понятно.
Я бы назвал это «конструктор».опускает понятие прототипа, ибо часто под таким конструктором подразумевают присваивание «методов» внутри него, что есть большое зло
на самом деле такого понятие/термина не существует, и самый близкий является как раз класс, ибо если мы связываем прототип с функцией-конструктором то мы говорим о контракте/интерфейсе для экземпляров которые будут созданы при помощи функции-конструктора.
ибо часто под таким конструктором подразумевают присваивание «методов» внутри негоЧто? Я не понял, кто так подразумевает, и зачем? И что такое «методы» в этом контексте, и кто присваивает методы и какого объекта и внутри чего (внутри конструктора я так понимаю)?
Формально, перед любой функцией можно поставить new. Я же предложил назвать термином «конструктор» функцию, которая специально для этого рассчитана чтобы быть вызванной с new. То есть, «функция, которая специально написана» — это, среди прочего, означает что она использует прототип. Остальные функции я «конструкторами» предлагаю не называть, а называть их просто «функциями».
на самом деле такого понятие/термина не существует, и самый близкий является как раз классМне все еще не очевидно почему этот термин «самый близкий». Логичнее мне кажется тут термин «конструктор». Но о терминах и как что называть спорить нет смысла.
Просто сойдемся на том что «такого термина в JS нет». А то будем так выдумывать каждый сам себе свои термины, и доказывать остальным что «это так будет всем удобно». А когда такой (или какой-то еще) термин официально появится в JS, тогда и разговор будет предметным.
Что? Я не понял, кто так подразумевает, и зачем?по моему вы поняли о чем я. я о замене прототипа, через рантайм расширение «методами» во время инициализации/выполнения функции-конструктора.
И что такое «методы» в этом контексте, и кто присваивает методы и какого объекта и внутри чего (внутри конструктора я так понимаю)?«метод» в джс — это свойство объекта которому присвоена функция, и предполагается ее вызов в скоупе этого объекта, что почти всегда реализуется механизмом самого языка
термин «конструктор»сильно широкий.
«функция, которая специально написана» — это, среди прочего, означает что она использует прототип.но это не значит что прототип используется должным образом программистом
Просто сойдемся на том что «такого термина в JS нет». А то будем так выдумывать каждый сам себе свои термины, и доказывать остальным что «это так будет всем удобно». А когда такой (или какой-то еще) термин официально появится в JS, тогда и разговор будет предметным.а вот тут вы не правы. уже официально есть, хоть и является сахаром, но по факту именно то что я всегда называл классом и тысячи других людей. и то что это стало стандартом лишний раз подчеркивает что таки людям так удобнее
Alexander
Не ссортесь, я вас помирю. Вы оба от части правы.
Термин «класс» есть. Он существует как в контексте JS, так и вне его.
Так вот «класс» это ни что иное как паттерн (да, тот самый паттерн ООП, как другие типа синглтон, фабрика и т.п.). И при помощи этого паттерна могут создаваться объекты, потом реализовываться наследование и т.д.
В разных языках этот паттерн выглядит по разному, где-то он выражен простым ключевым словом class, а в JS стандарта ES5 и более ранних данный паттерн реализуется через функцию. Вот и всё.
Поэтому утверждение, что в JS классов нет вполне верное. Однако есть паттерн, называющийся «класс», который реализует поведение подобное поведению классов в других языках программирования.
А что не так с классами в ES6?
Звісно, плутанина виникає в основному в тих, для кого js — не перша мова програмування. Ну.... а для тих, для кого перша ... варто побажати їм удачі, коли будуть розбирати ортодоксальне ООП в інших мовах.у меня JS основной язык программирования, Java периодически пишу для бекенда, никаких проблем не испытываю, так же не испытывают проблем люди которые супортят после меня этот бекенд.
знания одного языка не мешает использовать другой, если мешает, то значит человек просто не знает этот другой
Мені важко судити про саме ваш досвід. Але як ви, скажем, розумієте фразу «клас А наслідує клас В» в контексті JavaScript? Ви ж маєте знати, що способів «наслідування» там є багато. Звідки ви знаєте який мається на увазі саме зараз?
Dmitry Yaremenko
Это нормально если в каком-нибудь языке свое понятие «класс» если он соответствует определенному множеству объектов в абстрактном понимании, классическое понятие «класс» — в математике, а не в «ортодоксальном ООП»
Dmitriy Mozgovoy
А чем Вас стандартные возможности ES5 с прототипным наследованием и подмешиваниями не устраивают? В ES6 синтаксический сахар ввели, ничего нового, если есть возможность- используйте его. Сам я пока еще на ES5, так как местами один и тот же код и на сервере и клиенте должен работать, а с ES6 на клиенте пока туговато.
Dmitriy Iashin
ES6 + Babel
Gennady Dogaev
Просто оставлю это здесь habrahabr.ru/post/195944
Igor Kalashnikov
Тоже пишу на кофескрипте, больше нравится чем ES6(babel)
Вот, например, как выглядит у меня Абстрактный сервис и его наследник.
gist.github.com/...zo0m/a4f9e8852dc574654423
Smart Bones
Какое наиболее удобное решение написания класса на JS?coffeescript.org/#classes
mrself
function MyClass(){} чим такий підхід незручний? Добавляй методи, наслідуй від інших класів, використовуй mixins. Одним словом насолоджуйся ООП. Наскільки я знаю, для цього не потрібні бібліотеки.
Ivan Kukobko
А я жаваскрипт до сих пор не очень понимаю, но если надо классы — пишу на кофискрипте, а тот сам их волшебным образом превращает в эти ваши замыкания и прототипы.
Виктор Ткаченко
dou.ua/...cles/reasons-to-be-fired
а потом отакие темы штампуют
Ivan Kukobko
Даже не знаю, как мое сообщение коррелирует с той темой.
Сергій Дмитрук
babeljs.io + ES2015
anonymous
Ща тут начнётся, набегут матёрые теоретики и начнут учить что классов в JS нет и вы ничего не понимаете.
Никакие не использую, стандартных средств хватает. Для удобочитаемости нужно придумывать хорошие имена переменных, придерживаться например правила называть «приватные» поля с _, можно ещё jsDoc использовать. IDE от JetBrains последний понимают, можно описывать свои типы данных и получать подсказки и автокомплит.
Олексій Пєніє
О правильности пусть судит браузер. Вопрос стоял конкретно: удобочитаемость. Мой рецепт — решать вопрос при помощи коментов, пока это возможно.
Я не спорю, что есть тяжёлые задачи для javascript. Например игры и прочие программы с охренительно долгим временем жизни, добавлением плагинов, интернационализации, и конечно мегатонн рекламного счастья. Но тогда бы и вопрос стоял иначе.
В подавляющем большинстве случаев JS — это тонкий клиент. А тяга писателей кода сделать их говна конфетку, к сожалению, не оправдывает надежд. Получается всё то же говно, но в фантиках.
Решение в общем случае — меньше кодить, больше комментить. В JS нет средств сделать код хорошим сам по себе. Равно как его нет и в CSS, и в XSLT, и в прочих попытках «упростить» кодирование перекладыванием работы с компьютера на человека. А для человеков лучше писать на их языке, то есть коментить — так дешевле выйдет и быстрее.
Gennady Dogaev
В подавляющем большинстве случаев JS — это тонкий клиент.В последние несколько лет эти тонкие клиенты жутко растолстели
По прожорливости — о, да. Но как раз таки из-за попытки заменить качественный доступ к объектной модели (которая есть в браузере) неуклюжими скриптами.
Заканчивается это предсказуемо — под операционку писать едва ли не проще, чем под браузер. То есть в итоге серьёзные заказчики приходят к выводу о необходимости честных приложений. В том время как для счастья мало надо.
По прожорливостиПо объёму кода, по выполняемым задачам. Все полюбили AJAX, SPA. Всякий ангулар же появился не из-за того, что все хотят писать модно (хотя новизна, «крутость» и влияют на выбор технологий), а из-за того, что старыми подходами писать то, что требуется сейчас, сложновато.
Конечно, написать веб-приложение без фреймворка можно, потом просто затрахиваешься поддерживать и расширять, и с прожорливостью не особо порешаешь всё равно.
С этим никто не спорит. Вопрос об объектно-ориентированности на JS. Я утвеждаю, что это на сейчас не работает ни в каком удобоваримом виде.
На ES6 ещё какое-то подобие будет, и решается именно удобочитаемость. То есть если учиться — то сразу на него. Там много мелочей, которые надо было внедрить ещё лет 15 назад, но... «это вам не надо, есть же костыли».
Олексій Пєніє
Никакую. В отсутствие объектно-ориентированной среды выполнения — пользуйся тем что есть. И привыкни что скрипт — это скрипт, его задача — манипуляция объектами другой сущности. То есть главная задача — это по возможности вообще уйти от программирования, создавая объекты сразу такими как они должны быть, чтобы манипуляции были минимальны. Да и самих объектов поменьше, цикл жизни покороче.
Иными словами, простота — наше всё. JS — не сервер со своим «мозгом», а манипулятор чужим. Так что де-факто чем он занимается — это сношает мозги браузеру.
Если нечитабельно — пиши коменты. В конце концов, в продакшен ты всё равно его сожмёшь, так что пиши много именно для удобочитаемости. Если коменты написаны хорошо, то львиную долю кода вообще не станут читать, а сразу найдут тот кусочек который ответственный за фичу.
Artem Perchyk
Лол, прикольно. Скоро там ES6 обещают? Классы и человеческое наследование как в Java, хотет.
Большинство фич уже реализовано в последних версиях хрома, едж и фф: kangax.github.io/compat-table/es6
Но «как в джаве» — это не очень хорошая идея, поскольку один язык, в котором ООП делали «как в джаве» мы уже знаем)
А вообще, в ES6 классы — это просто сахар для все той же прототипной модели, так что путать жс и джаву по-прежнему смертный грех)
Євген Козлов
в отсутствии строгой типизации малополезно.
лучше уж познайте все прелести прототипного наследования с динамической типизацией.
Victor Mikhaylov
зачем оно там нужно, сила JS в функциональном программировании
50 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів