JEWeell Home | About Project

Чи потрібні JavaScript класи?

Опубліковано на 16 жовтня 2012 7:00 ранку Микола С. Zakas Теги: класи, ECMAScript 6, JavaScript, об'єкти Подобається нам це чи ні, ECMAScript 6 буде мати класи [1]. Концепція класів в наявність завжди були поляризаційні. Є люди, які люблять безкласового характеру JavaScript саме тому, що він відрізняється від інших мов. З іншого боку, є ті, хто ненавидить безкласового характеру JavaScript, тому що він відрізняється від інших мов. Одна з найбільших психічних перешкод людям потрібно стрибати при переході з C + + або Java в JavaScript є відсутність класів, і в мене було людям пояснити мені, що це була одна з причин вони або не сподобалося наявність або вирішили не для продовження навчання. JavaScript не мав формального визначення класів, оскільки вона вперше була створена і що викликало плутанину з самого початку. Є немає недоліку в книгах і статтях JavaScript говорити про класи, як якщо б вони були реальними речами в JavaScript. Те, що вони називають класами дійсно тільки користувальницькі конструктори використовуються для визначення користувацьких типів посилань. Довідник типів найближче до класів в JavaScript. Загальний формат досить знайомі більшості розробників, але ось приклад: function MyCustomType(value) { this.property = value; } MyCustomType.prototype.method = function() { return this.property; }; У багатьох місцях цей код описується як оголосити клас з ім'ям MyCustomType. Насправді, все це робить оголосити функцію з ім'ям MyCustomType, який призначений для використання з новими для створення екземпляра MyCustomType тип. Але немає нічого особливого в цій функції, не сказано, що це відрізняється від будь-якої іншої функції, яка не використовується для створення нового об'єкта. Це використання функцій, що робить його конструктор. Код навіть не дивиться, як вона визначенні класу. В Насправді, існує дуже мало очевидний зв'язок між визначенням конструктор і один метод на прототипі. Вони виглядають як два абсолютно окремих шматків коду JavaScript нових розробників. Так, є очевидний зв'язок між двома шматками коду, але він не був схожий на визначенні класу на іншій мові. Ще більш заплутаною, коли люди починають говорити про спадкування. Відразу вони починають кидати навколо таких термінів, як підкласів та суперкласів, концепцій, які мають сенс тільки, коли у вас дійсно є класи для роботи з. Звичайно, синтаксис спадкування настільки ж заплутаним і докладно: function Animal(name) { this.name = name; } Animal.prototype.sayName = function() { console.log(this.name); }; function Dog(name) { Animal.call(this, name); } Dog.prototype = new Animal(null); Dog.prototype.bark = function() { console.log("Woof!"); }; Двоступінчастий процес спадкування за допомогою конструктора та перевизначення прототип неймовірно заплутаним. У першому виданні професійних JavaScript для веб-розробників, я використав термін "клас" виключно. Зворотній зв'язок я отримав зазначено, що користувачів цій заплутаній і тому я змінив всі посилання на "клас" у другому виданні "тип". Я використовував термінологію, що з тих пір, і це допомагає усунути багато плутанини. Тим не менш, все ще існує кричуща проблема. Синтаксис для визначення користувацьких типів збиває з пантелику і багатослівними. Спадкування між двома типами є багатоступінчастим процесом. Існує простий спосіб виклику методу в батьківському класі. Підсумок: це біль для створення і управління користувацькими типами. Якщо ви не вірите, що це проблема, просто подивіться на кількість бібліотек JavaScript, які ввели свій власний спосіб визначення користувацьких типів, спадкування, або як:
  • YUI - має Y.extend () для виконання спадщини. І додає суперкласу власності при використанні цього методу [2].
  • Prototype - має Class.create () і Object.extend () для роботи з об'єктами і «класи» [3].
  • Dojo - має dojo.declare () і dojo.extend () [4].
  • MooTools - має користувальницький тип, званий клас для визначення і розширення класів [5].
Це досить очевидно, що є проблема, коли так багато бібліотек JavaScript визначальні рішення. Визначення користувацьких типів є брудним і зовсім не інтуїтивно. Наявність розробникам потрібно щось краще, ніж поточний синтаксис. ECMAScript 6 класів насправді не більш ніж синтаксичний цукор на верхній частині моделі, які ви вже знайомі з. Розглянемо такий приклад: class MyCustomType { constructor(value) { this.property = value; } method() { return this.property; } } Це ECMAScript 6 клас визначення насправді desugars з попереднім прикладом у цій посаді. Об'єкт, створений за допомогою цього визначення класу працює точно так само, як об'єкт, створений за допомогою конструктора визначення з раніше. Єдина відмінність полягає в більш компактний синтаксис. Як щодо спадщини: class Animal { constructor(name) { this.name = name; } sayName() { console.log(this.name); } } class Dog extends Animal { constructor(name) { super(name); } bark() { console.log("Woof!"); } } Цей приклад desugars в попередньому прикладі успадкування. Визначення класу компактних і незграбним порядок спадкування багатоступенева була замінена простим розширює ключове слово. Ви також отримуєте вигоду від супер () всередині класу, тому вам не потрібно посилатися на супертіпа більш ніж в одному місці. Всі поточні ECMAScript 6 клас пропозицію просто новий синтаксис у верхній частині моделі, які ви вже знаєте, в JavaScript. Спадкування працює так само, як завжди (ланцюжки прототипів плюс виклику батьківського конструктора), методи додають до прототипів, і властивості, оголошені в конструкторі. Єдина реальна різниця менше набирати для Вас (не каламбур). Визначення класів тільки визначення типів з різним синтаксисом. Таким чином, хоча деякі з них в припадку, тому що ECMAScript 6, введення класів, майте на увазі, що це поняття класів є абстрактним. Це не принципово змінитися, як JavaScript працює, це не введення нової річчю. Класи просто синтаксичний цукор у верхній частині користувацьких типів ви працюєте з на деякий час. Це вирішує проблему, яка JavaScript була протягом тривалого часу, що є багатослівність і плутанини визначати свої власні типи. Я особисто хотів би використовувати ключове слово типу замість класу, але в кінці кінців, це всього лише питання семантики. Так само необхідно наявність класів? Ні, але наявність безумовно, потребує екологічно чистих способів визначення користувацьких типів. Просто так вийшло, спосіб зробити, який має назву «клас» в ECMAScript 6. І якщо це допомагає розробникам з інших мов зробити легше перехід в наявність, то це хороша річ. Література
  1. Maximally minimal classes (ECMA)
  2. YUI extend() (YUILibrary)
  3. Prototype Classes and Inheritance (Prototype)
  4. Creating and Enhancing Dojo Classes (SitePen)
  5. MooTools Class (MooTools)
Попередження: Будь погляди і думки, висловлені в цій статті, належать Миколі Zakas С і ні, в будь-якому випадку, відображають мій роботодавець, мої колеги, Wrox видання, O'Reilly Publishing, або кого-небудь ще. Я говорю тільки за себе, не для них. Обидва зауваження і зв'язується в даний час закриті.   Переведено з http://www.nczonline.net/blog/2012/10/16/does-javascript-need-classes/ На головну
JEWeell

Technical support by @ReuN

Contact Form | Privacy policy | Cookie policy