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, які ввели свій власний спосіб визначення користувацьких типів, спадкування, або як:
|
|
JEWeell
Technical support by @ReuN |
|