Является ли JavaScript объектно-ориентированным?
Было несколько вопросов о том, является ли JavaScript объектно-ориентированным языком. Даже высказывание «только потому, что в языке есть объекты, не делает его объектно-ориентированным».
Является ли JavaScript объектно-ориентированным языком?
Не думаю, что это субъективно. Это либо есть, либо нет, либо есть конкретная причина, по которой он находится посередине. Как вы думаете, почему это субъективно?
На этот вопрос было дано 11 ответов в течение 34 секунд после публикации - вау.
Поскольку определение «объектно-ориентированный» не указывает ряд критериев для определения точного ответа.
Я согласен со Скливвзом, это субъективно, поскольку не существует авторитета, определяющего, какие именно характеристики должен иметь язык, с прилагательным «объектно-ориентированный».
есть способ уточнить вопрос?
Интересно, что большинство людей, которые отвечают «нет, это не так», утверждают, что в JS отсутствует повторное использование кода посредством наследования, что, вероятно, является одной из функций наихудший традиционных языков объектно-ориентированного программирования, и без которой мы можем и должны обойтись.
Тем более - так мнение, а не ответ, но вот мои два цента. Конечно, JS может быть объектно-ориентированным, но ему не хватает пары вещей, которые, как мне кажется, очень характерны для объектно-ориентированных языков. 1. Классы. Они помогают вам оставаться организованными, заставляя инкапсулировать вашу программу. 2. Обязательные декларации. Конечно, это может показаться раздражающим, но опять же, это заставляет вас оставаться организованным.
Да! Так же, как скейтборды и одноколесные велосипеды можно назвать «транспортными средствами, ориентированными на путешествия».
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 27
Краткий ответ: да. Для дополнительной информации:
От Википедия:
JavaScript is heavily object-based. Objects are associative arrays, augmented with prototypes (see below). Object property names are associative array keys: obj.x = 10 and obj["x"] = 10 are equivalent, the dot notation being merely syntactic sugar. Properties and their values can be added, changed, or deleted at run-time. The properties of an object can also be enumerated via a for...in loop.
Также см. эта серия статей о ООП с Javascript.
Javascript - это многопарадигмальный язык, поддерживающий процедурные, объектно-ориентированные (основанные на прототипах) и функциональные стили программирования.
Вот статья, в котором обсуждается, как делать объектно-ориентированный объект в Javascript.
JavaScript - очень хороший язык для написания объектно-ориентированных веб-приложений. Он может поддерживать ООП, поскольку поддерживает наследование посредством прототипирования, а также свойств и методов. У вас может быть полиморфизм, инкапсуляция и множество парадигм подкласса.
Чтобы языки были объектно-ориентированными, не обязательно вести себя точно так же, как Java. Все в Javascript - это объект; сравните с C++ или более ранней версией Java, которые до некоторой степени считаются объектно-ориентированными, но все же основанными на примитивах. Полиморфизм не является проблемой в Javascript, поскольку он вообще не заботится о типах. Единственная основная функция объектно-ориентированного программирования, не поддерживаемая напрямую синтаксисом, - это наследование, но это может быть легко реализовано, однако программист хочет использовать прототипы: здесь - один из таких примеров.
Придирка: Javascript также имеет примитивные значения, и они не являются объектами. Неопределенный, нулевой, логический, числовой и строковый, чтобы быть точными.
Я знаю, что в Javascript есть примитивные типы, но я не считаю их таковыми в обычном смысле, потому что они по-прежнему похожи на объекты действовать (кроме тех, которые явно означают «ничего»). typeof ("foo") дает вам 'строку', а не 'объект', да, но строки по-прежнему имеют методы; "foo" .substr (1) работает.
Ха, я не хочу разжигать войны, просто сравнивая с языком, который почти повсеместно считается объектно-ориентированным. Возможно, мне стоит это немного прояснить.
Я удалил свой комментарий, так как он больше не актуален. Разойдитесь пожалуйста, здесь нечего смотреть :)
@InternetFriend - typeof (null) = 'object', boolean, number и string - все классы, расширяющие объект, undefined никогда не является значением, это по определению отсутствие значения и где это само определяется как свойство
@OP - JS поддерживает наследование в форме прототипирования
«Полиморфизм не является проблемой в Javascript». Это очень неправильно! myObj.talk () будет означать разные вещи в зависимости от того, что myObj имеет в своем слоте для разговора. Это не имеет ничего общего с динамической типизацией JS.
Я думал, что все в Javascript - это ассоциативный массив.
Клиентская библиотека Microsoft Ajax упрощает реализацию объектно-ориентированного подхода в javascript. Он поддерживает понимание и реализацию интерфейса.
Я думаю, что многие люди ответят на этот вопрос «нет», потому что JavaScript не реализует классы в традиционном объектно-ориентированном смысле. К сожалению (ИМХО), это появится в ECMAScript 4. А пока, viva la prototype! :-)
Я предполагаю, что это зависит от того, какую традицию ваш вкус ОО считает своей собственной.
Я бы сказал, что у него есть возможности казаться объектно ориентированным. Особенно, если вы воспользуетесь его способностью создавать методы для существующего объекта (анонимные методы на некоторых языках). Библиотеки клиентских скриптов, такие как jquery (jquery.com) или prototype (prototypejs.org), являются хорошими примерами библиотек, использующих это преимущество, что заставляет javascript вести себя очень похоже на объектно-ориентированную разработку.
Почему люди думают, что классическое ООП - единственная истинная форма ООП. фейспалм
когда появилась такая вещь, как классическое ООП. Тогда что нового ООП ... шучу под музыку Metallica, не имея ни малейшего представления, что происходит, но хорошо проводя время? .... извините .... я очень-очень привязан .... :)
Это, конечно, субъективный и академический вопрос. Некоторые люди спорят, должен ли объектно-ориентированный язык реализовывать классы и наследование, другие пишут программы, которые меняют вашу жизнь. ;-)
(Но на самом деле, почему объектно-ориентированный язык должен реализовывать классы? Я бы подумал, что объекты были ключевыми компонентами. Другое дело, как вы их создаете, а затем используете.)
В отличие от большинства объектно-ориентированных языков, JavaScript (во всяком случае, до ECMA 262 Edition 4) не имеет концепции классов, но имеет прототипы. Как таковой, действительно несколько субъективно, называть его объектно-ориентированным или нет.
@eliben: Википедия говорит, что объект-основан. Это не то же самое, что объектно-ориентированный. Фактически, их статья об объектно-ориентированных различает объектно-ориентированные языки и языки на основе прототипов, явно вызывая объектно-ориентированный JavaScript нет.
Однако, если вы читаете дополнительную статью об объектно-ориентированных языках, можно заметить, что Javascript является объектно-ориентированным языком, хотя и основан на прототипах. Единственный пример объектно-ориентированного языка - это устаревший VisualBasic.
Я думаю, что когда вы можете следовать тем же или подобным шаблонам проектирования, что и настоящий объектно-ориентированный язык, такой как Java / C#, вы можете в значительной степени назвать его языком объектно-ориентированного программирования. Некоторые аспекты, очевидно, отличаются, но вы все равно можете использовать хорошо зарекомендовавшие себя схемы объектно-ориентированного проектирования.
JavaScript является объектно-ориентированным, а не объектно-ориентированным. Разница в том, что объектно-ориентированные языки не поддерживают правильное наследование, тогда как объектно-ориентированные языки поддерживают.
Есть способ добиться «нормального» наследования в JavaScript (Ссылка здесь), но базовая модель основана на прототипировании.
Все в javascript - это объект: классы - это объекты, функции - это объекты, числа - это объекты, объекты - объекты. Он не так строг в отношении набора текста, как другие языки, но, безусловно, можно написать OOP JS.
В Javascript нет классов
Что бы вы вообще использовали в идентификаторе справа от нового ключевого слова?
Правда, в javascript нет классов, достаточно справедливо, но объекты, которые вы создаете, являются приблизительными классами, по крайней мере, в отношении того, как вы с ними взаимодействуете.
Классы - это бухгалтерская конструкция. Объект не обязательно имеет какое-либо отношение к объектам. ИМХО, что делает объект, это пропуск лямбды.
Hanselminutes серия 146 смотрит на OO Ajax. Это было хорошее шоу и определенно хорошее шоу, которое помогло сформировать мнение.
Честно говоря, это шоу увековечило несколько неверных характеристик JavaScript, и именно поэтому я задал здесь этот вопрос. Мне нужно было место, где я мог бы указать в следующий раз, когда кто-нибудь заявит, что JavaScript не является объектно-ориентированным.
Да, это так. Однако он не поддерживает все функции, которые можно было бы ожидать от объектно-ориентированного языка программирования, лишенного наследования и полиморфизма. Однако это не означает, что вы не можете смоделировать эти возможности с помощью системы прототипирования, доступной для языка.
IMO (и это только мнение) то ключевой характеристикой объектно-ориентированного языка будет то, что он будет поддерживать полиморфизм. Практически все динамические языки делают это.
Следующей характеристикой будет инкапсуляция, и это довольно легко сделать и в Javascript.
Однако, по мнению многих, именно наследование (в частности, наследование реализации) может нарушить баланс в отношении того, может ли язык называться объектно-ориентированным.
Javascript предоставляет довольно простые средства для наследования реализации через прототипирование, но это происходит за счет инкапсуляции.
Итак, если вашими критериями объектной ориентации является классическая тройка полиморфизма, инкапсуляции и наследования, то Javascript не подходит.
Редактировать: Возникает дополнительный вопрос: "Как прототипное наследование жертвует инкапсуляцией?" Рассмотрим этот пример непрототипного подхода:
function MyClass() {
var _value = 1;
this.getValue = function() { return _value; }
}
Атрибут _value инкапсулирован, его нельзя изменить напрямую внешним кодом. Мы могли бы добавить к классу мутатор, чтобы изменить его так, чтобы он полностью контролировался кодом, который является частью класса. Теперь рассмотрим прототипный подход к тому же классу:
function MyClass() {
var _value = 1;
}
MyClass.prototype.getValue = function() { return _value; }
Ну это сломано. Поскольку функция, назначенная getValue, больше не входит в область действия _value, она не может получить к ней доступ. Нам нужно было бы повысить _value до атрибута this, но это сделало бы его доступным вне контроля кода, написанного для класса, поэтому инкапсуляция нарушена.
Несмотря на это, я по-прежнему считаю, что Javascript является объектно-ориентированным. Почему? Поскольку, имея OOD, я могу реализовать его в Javascript.
Как прототипное наследование жертвует инкапсуляцией?
Инкапусация требует хранения личных данных в контексте выполнения, созданном при построении объекта. Члены, добавленные к прототипу, не имеют доступа к этому контексту выполнения и, следовательно, не могут получить доступ к инкапсулированным данным.
Приведенный пример также не компилируется на C#, поэтому можно ли сказать, что он не объектно-ориентированный? открытый класс MyClass: ParentClass {частное int _value = 1; } открытый класс ParentClass {общедоступный int GetValue () {return _value; }}
@liammclennan? Я не уверен, к чему вы клоните? C# явно объектно-ориентированный. Я не уверен, какая точка используется при попытке перенести код Javascript в моем примере на C#, который является неполным портом, потому что он не компилируется.
@AnthonyWJones liammclennan прав. Код, представленный в ответе, будет преобразован в общедоступный MyClass {private int _value = 1; общедоступный статический GetValue () {return _value; }} который не компилируется. Вы не можете получить доступ к переменной экземпляра (нестатической) из метода класса (статического). У Ruby есть похожее ограничение.
@Thedric: Я понимаю, почему он сломан в C#, он также сломан в Javascript, это точка в примере. Я до сих пор не понимаю, почему перенос на C# полезен для обсуждения, но речь идет именно о Javascript, а не о C# или Ruby. Кстати, порт, который у вас есть, не эквивалентен, вы даже не можете вызвать свой GetValue против примерMyClass в любом случае, в моем коде getValue не эквивалентен статическому методу, более близким эквивалентом будет метод расширения в C# .
Вы правы, что C# не нужен и что я упустил суть. Однако суть должна была заключаться в этом. Инкапсуляция не означает сокрытие информации. IH - это концепция, связанная с инкапсуляцией. А скрытие информации - это то, на что вы намекаете при редактировании. Инкапсуляция более концептуальна, чем это. Это относится к тому, что внешний мир использует для взаимодействия с объектом. Таким образом, вопрос Скотта Куна.
@Thedric: В текущем контексте я не вижу необходимости проводить такое различие. Да, «инкапсуляция» - это более широкий термин, но он применяется только к информации, содержащейся внутри объекта, что интересно с точки зрения объектно-ориентированного подхода, в конце концов, каждая функция, когда-либо написанная за всю историю, является упражнением в инкапсуляции логики, независимо от того, ОО-процедура или метод объекта.
Но согласно определению инкапсуляции, которое вы используете, любой язык, поддерживающий публичные поля, может подвергнуть сомнению их объектную ориентацию.
@Thedric: Нет, только потому, что язык может предоставляет общедоступное поле, не дисквалифицирует его при оценке большинства людей. Основная идея моего ответа заключается в том, что простой Javascript не поддерживает наследование реализации симулятивно обоих частных полей и. Для многих это было бы дисквалифицирующим ограничением, а не потому, что я лично разделяю эту точку зрения.
Отметим, что в этом отношении JavaScript не уникален. Python также не имеет механизма для принудительной инкапсуляции. Все члены объекта Python фактически являются общедоступными, а Python использует соглашения об именах только для обозначения того, что член должен рассматриваться как «частный». Но никто не сомневается, является ли Python объектно-ориентированным языком.
@Casebash: Я не уверен, в чем ваш вопрос?
@Anthony: Мой комментарий удален, я недостаточно внимательно прочитал ваш ответ
Более точное определение объектно-ориентированного подхода будет основано на «передаче сообщений»; в любом объектно-ориентированном языке основная методология проектирования - это «объекты, передающие сообщения другим объектам», а не «доступ к полям и их изменение». Вызов метода - одна из популярных форм передачи сообщений. Полиморфизм и наследование не являются неотъемлемым свойством объектно-ориентированного программирования, они необходимы только из-за ограничений, накладываемых статической типизацией; инкапсуляция присуща системе передачи сообщений (поскольку вы никогда не обращаетесь к переменным напрямую, вы просто отправляете сообщения другим объектам), но она не является основным направлением объектно-ориентированного программирования.
В JavaScript есть информация, скрытая с помощью привилегированных функций: crockford.com/javascript/private.html
@Amir: Да, это прекрасно работает, но вы не можете использовать прототипную форму наследования с таким подходом. Существуют и другие подходы к реализации наследования, в которых используется этот подход к закрытию, но следует задаться вопросом, пишет ли его разработчик объектно-ориентированную структуру, а не Javascript, являющийся объектно-ориентированным.
@Lie: Я согласен с тем, что наследование является более поздним дополнением к исходному корню передачи сообщений ранней объектно-ориентированной разработки. Несмотря на полиморфизм является, присущий более старому миру передачи сообщений, очень разные объекты могут принимать подмножество общих сообщений. Я также не согласен с тем, что инкапсуляция «является основным направлением объектно-ориентированного подхода», возможно, это было в прошлом, но ее полиморфная природа объектно-ориентированного программирования действительно имеет значение. Повторное использование кода вызов, который может быть применен к супертипу (или более позднему интерфейсу), сегодня каждый бит так же ценен (если не более ценен), как инкапсуляция.
@AnthonyWJones: Полиморфизм важен только в ООП, в котором используется статическая типизация. Понятие типов данных на самом деле не обязательно должно существовать как языковая конструкция языка ООП; Под типом можно неявно понимать любые сообщения, которые объект может разумно отправлять и / или получать. ООП сосредоточено вокруг концепции передачи сообщений. Я согласен, инкапсуляция никогда не была основным направлением объектно-ориентированного подхода, за исключением тех, кто недавно явно неправильно понимал конкретную реализацию ООП как само ООП.
@Lie: «тип можно неявно понимать как любые сообщения, которые объект может разумно отправлять и / или получать». На самом деле это самая суть полиморфизма, статическая типизация тут ни при чем. Объект можно рассматривать как объект типа, потому что он понимает определенный набор сообщений, он может понимать другие наборы сообщений, что фактически дает ему несколько типов, это полиморфный. Полиморфизм не ограничивается статической типизацией, его гораздо проще реализовать динамически, настолько легко, что вам не нужно думать, и концепция теряется, но на самом деле мы делаем это много.
Эээ ... function MyClass() { var _value = 1; MyClass.prototype.getValue = function() { return _value; } }
@eyelidlessness: Ваш код очень сломан, или вы пытались донести именно это? Попробуйте добавить метод incrementValue, а затем поиграйте с несколькими экземплярами MyClass, и вы поймете, что я имею в виду.
Можете быть более конкретными? Добавление incrementValue к prototype в теле конструктора так же, как было добавлено getValue, ведет себя так, как ожидалось ... каждый экземпляр начинается с _value == 1, а incrementValue увеличивает _value только для этого экземпляра, точно так же, как свойство private будет вести себя в классе. Какого поведения вы ожидаете? Что мне не хватает? jsfiddle.net/7ag7Z
@eyelidlessness: вам не хватает того факта, что существует только объект-прототип один. Следовательно, экземпляры всеMyClass будут использовать те же функции, что и последний создаваемый экземпляр. Если вы создаете два экземпляра, затем вызываете инкремент на обоих, а затем вызываете getValue на обоих, вы получите 3, возвращенные обоими. Функции, которые были созданы в первом экземпляре, отбрасываются и заменяются при создании второго экземпляра. Область выполнения первого больше не используется даже первым экземпляром, потому что функции, которые он предоставляет, теперь фактически созданы во втором экземпляре.
@ Энтони, ты прав. Это все еще разрешимо. Смотрите мою ревизию: jsfiddle.net/7ag7Z/1
@eyelidlessness: ваш код может работать, но это делает бессмысленным использование прототипа. Весь смысл прототипа состоит в том, чтобы позволить одному набору свойств / методов совместно использоваться несколькими экземплярами «класса». В вашем коде теперь есть отдельные функции для каждого экземпляра, возможно, вы использовали первый пример кода в моем ответе.
Javascript не является объектно-ориентированным языком, как обычно считается, в основном из-за отсутствия истинного наследования, типизация DUCK допускает полуистинную форму наследования / полиморфизма вместе с Object.prototype, допускающим совместное использование сложных функций. Однако, по сути, отсутствие наследования приводит к слабому полиморфизму, поскольку типизация DUCK будет настаивать на том, что какой-то объект с такими же именами атрибутов является экземпляром объекта, в качестве которого они не предназначены. Таким образом, добавление атрибутов к случайному объекту, так сказать, трансформирует основу их типа.
JavaScript является объектно-ориентированным, но не является объектно-ориентированным языком основанный на классе, таким как Java, C++, C# и т. д. Языки ООП на основе классов являются подмножеством более широкого семейства языков ООП, которые также включают языки на основе прототипов, такие как JavaScript и Self. .
Технически это язык-прототип, но на нем легко реализовать объектно-ориентированный подход.
Он объектно-ориентированный, но не основан на классах, он основан на прототипах.
И да и нет.
JavaScript - это, как выразился Дуглас Крокфорд, «самый непонятый язык программирования в мире». У него есть отличные статьи по JavaScript, который я настоятельно рекомендую прочитать о том, что такое JavaScript. Он имеет больше общего с LISP, чем C++.
Специально эта статья связана с этим вопросом: javascript.crockford.com/prototypal.html
JavaScript - это язык программирования на основе прототипов (вероятно, язык сценариев на основе прототипов является более правильным определением). Он использует клонирование, а не наследование. Язык программирования на основе прототипов - это стиль объектно-ориентированного программирования без классов. В то время как объектно-ориентированные языки программирования побуждают разработчиков сосредотачиваться на таксономии и отношениях, языки программирования на основе прототипов побуждают сосредоточиться сначала на поведении, а затем на классификации.
Термин «объектно-ориентированный» был введен Аланом Кей в 1967 году, который объяснил его в 2003 году как означающее
only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.(source)
В объектно-ориентированном программировании каждый объект может принимать сообщения, обрабатывать данные и отправлять сообщения другим объектам.
Объектно-ориентированный язык может включать такие функции, как инкапсуляция, модульность, полиморфизм и наследование, но это не является обязательным требованием. Объектно-ориентированные языки программирования, в которых используются классы, часто называют языками программирования на основе классов, но ни в коем случае не обязательно использовать классы, чтобы быть объектно-ориентированными.
JavaScript использует прототипы для определения свойств объекта, включая методы и наследование.
Вывод: JavaScript ЯВЛЯЕТСЯ объектно-ориентированным.
Я подозреваю, что лишь некоторые из нас достаточно взрослые, чтобы помнить это определение объектно-ориентированного. Я помню, как 20 лет назад я поставлял OOD с помощью VAX BASIC.
это является хороший поток. Вот некоторые ресурсы, которые мне нравятся. Большинство людей начинают с прототипа, jquery или одной из шести лучших библиотек (mootools, ExtJS, YUI), которые имеют разные объектные модели. Prototype пытается воспроизвести классический O-O, как думает большинство людей.
http://jquery.com/blog/2006/08/20/why-jquerys-philosophy-is-better/
Вот изображение прототипов и функций, на которые я часто ссылаюсь.
Объекты в JavaScript наследуются напрямую от объектов. Что может быть более объектно-ориентированным?
Я отвечаю на этот вопрос под другим углом.
Это вечная тема, и мы могли бы начать войну на многих форумах.
Когда люди утверждают, что JavaScript - это объектно-ориентированный язык программирования, потому что они могут использовать с ним объектно-ориентированный подход, я спрашиваю: почему C не является объектно-ориентированным языком программирования? Повторите, вы можете использовать OOD с C, и если вы сказали, что C - это объектно-ориентированный язык программирования, все скажут вам, что вы сошли с ума.
Мы могли бы разместить здесь много ссылок на эту тему в очень старых книгах и форумах, потому что эта тема старше Интернета :)
JavaScript не менялся уже много лет, но новые программисты хотят показать, что JavaScript - это объектно-ориентированный язык программирования. Почему? JavaScript - мощный язык, но не объектно-ориентированный язык программирования.
ОО-язык программирования должен иметь объекты, метод, свойство, классы, инкапсуляцию, агрегирование, наследование и полиморфизм. Вы можете реализовать все эти пункты, но в JavaScript их нет.
Очень наглядный пример: в главе 6 «Объектно-ориентированного JavaScript» опишите 10 способов реализовать «наследование». Сколько манер существует в Java? Один, а в C++? Один, а в Delphi (Object Pascal)? Один, а в Objective-C? Один.
Почему это другое? Потому что Java, C++, Delphi и Objective-C разработаны с учетом ООП, но не JavaScript.
Когда я был студентом (в 1993 году) в университете, у меня была типичная домашняя работа: реализовать программу, разработанную с использованием OOD (объектно-ориентированного проектирования), на языке, отличном от OO. В то время выбранным языком был C (а не C++). Целью этой практики было прояснить разницу между ООП и ООП, а также провести различие между ООП и языками, не являющимися ООП.
Во всяком случае, это свидетельство того, что не все люди имеют какое-то мнение по этой теме :)
В любом случае, на мой взгляд, JavaScript - это мощный язык и будущее на уровне клиента!
Ваша концепция ООП слишком узка и сформирована C++ и Java.
Миско Хевери сделал отличное вступительное слово в Google Tech Talk, в котором рассказал об объектах в Javascript. Я считаю, что это хорошая отправная точка для людей, которые либо задаются вопросом об использовании объектов в Javascript, либо хотят начать с ними работать:
Лично для меня главная привлекательность ООП-программирования - это возможность иметь автономные классы с неэкспонированной (закрытой) внутренней работой.
Что меня бесконечно смущает в Javascript, так это то, что вы даже не можете использовать имена функций, потому что вы рискуете получить то же имя функции где-то еще в любой из внешних библиотек, которые вы используете.
Несмотря на то, что некоторые очень умные люди нашли обходные пути для этого, не странно ли, что Javascript в чистом виде требует от вас создания кода, который очень нечитаем?
Прелесть ООП в том, что вы можете тратить время на размышления о логике своего приложения, не беспокоясь о синтаксисе.
Is JavaScript object-oriented?
Answer : Yes
У него есть объекты, которые могут содержать данные, и методы, которые работают с этими данными. Объекты могут содержать другие объекты.
- У него нет классов, но есть конструкторы, которые делают то же, что и классы, в том числе действуют как контейнеры для переменных и методов класса.
- У него нет наследования, ориентированного на классы, но у него есть наследование, ориентированное на прототип.
Двумя основными способами построения объектных систем являются наследование (is-a) и агрегирование (has-a). JavaScript делает и то, и другое, но его динамический характер позволяет ему преуспеть в агрегировании.
Некоторые утверждают, что JavaScript не является действительно объектно-ориентированным, потому что он не обеспечивает скрытие информации. То есть у объектов не может быть частных переменных и частных методов: все члены являются общедоступными.
Но оказывается, что Объекты JavaScript могут иметь частные переменные и приватные методы. (Щелкните здесь, чтобы узнать, как это сделать.) Конечно, немногие это понимают, потому что JavaScript - это самый неправильно понимаемый язык программирования в мире.
Некоторые утверждают, что JavaScript не является действительно объектно-ориентированным, потому что он не обеспечивает наследования. Но оказывается, что JavaScript поддерживает не только классическое наследование, но и другие шаблоны повторного использования кода.
я бы добавил тег "субъективный"