Почему многие языки динамического программирования с утиными типами используют подход на основе классов вместо ООП на основе прототипов?

Поскольку довольно много динамических языков программирования имеют функцию утилитной типизации , и они также могут открывать и изменять методы класса или экземпляра в любое время (например, Ruby и Python ), тогда…

Вопрос 1) Зачем нужен класс на динамическом языке? Почему язык спроектирован таким образом, чтобы использовать класс как своего рода «шаблон» вместо того, чтобы делать его как прототип и просто использовать объект?

Также JavaScript основан на прототипах, но CoffeeScript (расширенная версия JavaScript) выбирает путь на основе классов. И то же самое для Lua (на основе прототипов) и MoonScript (на основе классов). Кроме того, есть класс в ES 6. Итак ...

Вопрос 2) Предполагается ли, что если вы попытаетесь улучшить язык, основанный на прототипах, помимо прочего, вы должны изменить его на класс? Если нет, то почему это так устроено?

Вопрос 1) Зачем нужен класс на динамическом языке? Почему язык спроектирован таким образом, чтобы использовать класс как своего рода «шаблон» вместо того, чтобы делать это как прототип и просто использовать объект?

Самый первый язык ОО (хотя он не назывался "ОО"), Симула, не имел наследства. Наследование было добавлено в Simula-67, и оно было основано на классах.

Примерно в то же время Алан Кей начал работать над своей идеей новой парадигмы программирования, которую он позже назвал «объектно-ориентированная». Ему действительно нравилось наследование, и он хотел, чтобы оно было на его языке, но он также не любил занятия. Однако он не мог придумать способ получить наследование без классов, и поэтому он решил, что ему больше не нравятся классы, чем наследование, и разработал первую версию Smalltalk, Smalltalk-72 без классов и, следовательно, без наследования.

Пару месяцев спустя Дэн Ингаллс придумал дизайн классов, где сами классы были объектами, а именно экземплярами метаклассов. Алан Кей счел этот дизайн несколько менее ужасным, чем старые, поэтому Smalltalk-74 был разработан с классами и с наследованием на основе классов.

После Smalltalk-74 Алан Кей почувствовал, что Smalltalk движется в неправильном направлении и на самом деле не представляет, что такое ОО, и предложил команде отказаться от Smalltalk и начать все сначала, но за него проголосовали. Таким образом, последовали Smalltalk-76, Smalltalk-80 (первая версия Smalltalk, которая будет выпущена для исследователей) и, наконец, Smalltalk-80 V2.0 (первая версия, которая будет выпущена на коммерческой основе, и версия, которая стала основой для ANSI Smalltalk) ,

Поскольку Simula-67 и Smalltalk-80 считаются прародителями всех ОО-языков, почти все последующие языки слепо копировали дизайн классов и наследование на основе классов. Пару лет спустя, когда появились другие идеи, такие как наследование, основанное на миксинах вместо классов, и делегирование, основанное на объектах, а не наследование, основанное на классах, наследование на основе классов уже стало слишком укоренившимся.

Интересно, что нынешний язык Алана Кея основан на делегировании прототипов.

Многие программисты предпочитают работать с классами. Это очень простая для понимания концепция, которая является хорошей моделью человеческих мыслительных процессов о мире (то есть мы инстинктивно связываем реальные объекты с абстрактной группой предметов, к которой мы считаем их принадлежать, то есть с классом) , Кроме того, классы упрощают рассуждения о типах объектов: в языке на основе классов применение принципов, таких как подстановка Лискова, проще, чем в языке, где у нас просто есть объекты, которые могут иметь разные методы или тип которых может даже измениться во время выполнения. , как в случае с JavaScript.

Обратите внимание, что даже в JavaScript очень много кода просто использует прототип для эмуляции классов. Это в основном потому, что многие программисты предпочитают так думать.

Существует также другая причина, по которой предпочтительны языки на основе классов: их проще скомпилировать в эффективный код. Наиболее эффективные виртуальные машины JavaScript эффективно динамически создают классы для представления типов объектов JavaScript по мере изменения их методов и прототипов. Посмотрите это описание реализации V8 для обоснования того, почему это делается.

Я слышал, что в больших проектах, где команды людей работают вместе над одним и тем же кодом, эти гибкие языки (где вы можете изменять свойства и методы объекта во время выполнения) - это свободы, которые другие члены команды не хотят, чтобы вы иметь.

Они хотят знать, когда они имеют дело с объектом, что объект будет действовать точно так же, как говорит план, а не каким-то измененным способом, которым какой-то другой амбициозный разработчик решил изменить его, чтобы выполнить свою собственную задачу.

Итак, единственная причина, по которой я могу представить, что кому-то не нужны гибкие возможности, предлагаемые этими удивительными динамическими языками, заключается в том, что они хотят упростить командную разработку, отладку и автоматическое документирование.

Лично я разработал приложения в обеих методологиях, и с динамическими языками я справляюсь быстрее. Я не использую ни одну из этих платформ, предназначенных для того, чтобы снова превратить мой динамический язык в язык классов. Такие вещи являются регрессом на мой вкус.

Для меня ООП означает только обмен сообщениями, локальное хранение, защиту и сокрытие процесса состояния и крайнюю позднюю привязку всех вещей - Алан Кей

Так что он говорит здесь о том, что ОО - это создание черных ящиков, которые отвечают на сообщения. В некотором смысле, REST является конечной ОО-системой в том смысле, что она использует глаголы (т.е. сообщения) и ресурсы (то есть непрозрачный блок, содержащий некоторые данные).

Таким образом, вопрос о том, почему некоторые основаны на классах, а другие на прототипах, упускают из виду тот факт, что на самом деле это не имеет значения, они оба просто реализации. Система, которая использует исключительно обмен сообщениями вместо вызовов методов, является такой же ОО, как и два упомянутых вами экземпляра.