Алан Кэй не изобретал объекты

Автор оригинала: Hillel Wayne
  • Перевод

Люди продолжают утверждать, что современные объектно-ориентированные языки, на самом деле "не совсем объектно-ориентированные", поскольку они не соответствуют определению ООП Алана Кэя. На мой взгляд, в этом есть смысл, хотя я и не согласен с выводом. В последнее время мне встречаются люди, которые говорят о том, что именно Кэй изобрёл объекты. Фактически это неверно.


Алан Кэй не изобретал объекты. Они были в Simula, которую приводит в качестве основного источника вдохновения руководство к Smalltalk-72 (с. 117). В выпуске известного журнала Byte за 1981 год, который популяризировал Smalltalk и ООП, говорится, что "основная идея объектов, сообщений и классов пришла из SIMULA". В нем сказано, что Simula позволяет пользователям создавать "объектно-ориентированные системы", что, возможно, слишком, но тем не менее. Команда Smalltalk хорошо знала систему объектов в Simula и черпала вдохновение из неё.


Одной из причин, почему такой миф всё ещё жив, послужило то, что сказал сам Кэй в 1998 году:


Просто напоминаю, что на последней OOPSLA я постарался донести до всех, что Smalltalk — это не только НЕ синтаксис или библиотека классов, но даже не классы. Мне очень жаль, что ранее я ввел термин "объекты" для этой темы, поскольку это заставляет многих людей сосредоточиться на меньшей идее.

И далее в этом интервью он продолжает:


Я имею в виду, что я изобрел термин "объекты". Поскольку мы делали объекты первыми, не было других объектов, чтобы радикализировать это.

Позднее он перестал это утверждать, но люди до сих пор продолжают использовать ту цитату как факт.


Алан Кэй изобрел термин "Объектно-ориентированное программирование"


Это абсолютная правда.


ООП было в классах и объектах


В последнее время многие продолжают утверждать, что ООП на самом деле — не в классах и объектах, и что на самом деле наиболее важными являются сообщения. В посте 1998 года, после того, как Кэй сказал, как он сожалеет об "объектах", он также говорит, что "бо́льшая идея — это обмен сообщениями". Далее он пишет:


ООП для меня это только сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего. Это можно сделать в Smalltalk и в LISP. Вероятно, существует другие системы, где это возможно, но мне о них не известно.

В раннем ООП сообщения во многом считались важными, прежде всего для обслуживания объектов. Вот как Дон Ингаллс объясняет ООП в своем введении в Smalltalk-76:


Smalltalk скорее ориентирован на объекты, а не на функции, и это часто путает людей, имеющих опыт в computer science. Например, вычислить <someobject>+4 означает отправить +4 объекту как сообщение. Основное отличие состоит в том, что всем управляет объект, а не +. Если <someobject> является целым числом 3, то результатом будет целое число 7. Однако, если <someobject> был строкой 'Meta', результатом может быть Meta4. Таким образом, смысловая нагрузка идёт вместе с объектами системы, а код остается абстрактной формой, просто направляя поток сообщений.

В книге "Microelectronics and the Personal Computer" Кэй говорит о системе "сообщение-действие", в которой "каждое действие принадлежит семье", и говорит о расширении деятельности в "точки зрения" объектных отношений как будущей границы. В руководстве к Smalltalk-72 он пишет (с. 18):


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

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


Smalltalk был первым настоящим объектно-ориентированным языком


ACM вручила Премью Тьюринга Далю и Нюгору, и назвала их "соавторами ООП". Также журнал Byte пишет, что Simula была объектно-ориентированной, а в статье "The Computer Revolution hasn’t happened yet" Кэй называет Sketchpad "очень объектно-ориентированным". На мой взгляд, это не признаёт заслуг Smalltalk в должной степени. В отличие от других систем, в Smalltalk:


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

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


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


У Smalltalk был окружающий контекст


Люди не изобретают инструменты спонтанно. У них есть конкретные ситуации и задачи, и они пытаются найти решение этих задач. Новшества в Smalltalk и ООП — не исключение.


Алан Кэй интересовался темой персональных компьютеров. Его работы над FLEX, Dynabook и Smalltalk строятся вокруг этого. По его мнению, ПК должен был быть полностью под контролем пользователя; всё, от логики ядра системы до графического рендеринга, — можно было бы настраивать и исследовать во время работы. Передача сообщений и позднее связывание решают ряд задач. Если ребенок устанавливает новую игру, нужно ли перекомпилировать всю ОС, чтобы использовать новую программу? Нет: сделайте так, чтобы можно было отправить произвольное сообщение любому объекту и положиться на обработку протокола во время работы, чтобы выполнить задачу.(*) Если человек нарушает логику работы звуковой системы, должна ли вся ОС упасть? Конечно, нет, поэтому разрешите объектам самим решать, как обрабатывать сообщения. Объекты хорошо себя здесь проявляют.


Оле Даль и Кирстен Нюгор пытались решить совершенно другую задачу. Их интересовала симуляция. Одно из исследований в руководстве по Simula — моделирование распространения инфекции среди фиксированной популяции. Система полностью закрыта: у вас есть фиксированный набор кода, вы запускаете симуляцию и получаете результат. Для них передача сообщений бесполезна. Но возможности определять симуляции в терминах других симуляций, специализировать сущности и моделировать время как объект первого класса невероятно полезны. Объекты также хорошо себя здесь проявляют .


Так кто же использовал объекты "правильно"? Это неразумный вопрос. Они делали разные вещи, поскольку у них были разные задачи. Наша современная идея ООП — это синтез всех их идей, а также идей Адель Голдберг, Барбары Лисков, Дэвида Парнаса, Бертрана Мейера, Гюля Ага и многих других. Но никто из них не может утверждать, что же такое "ООП". Понятия развиваются, как и задачи.


tl;dr


Интервью, взятые более 30 лет назад, не являются хорошими первоисточниками.




* Возможно, это делает Powershell духовным преемником Smalltalk.

Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 11

    +3
    Мне его другая фраза больше запомнилась:

    “I invented the term ‘object oriented’, and C++ was not what I had in mind”. Dr. Alan Kay.
      0
      «Не было», «Можно было», «Методы и реализации были» звучат странно. Оно и сейчас так. Instantiations (VA Smalltalk), Cincom (VisualWorks, ObjectStudio), GemTalk (GemStone/S) всё ещё живы.
        0
        ООП для меня это только сообщения, локальное удержание и защита, скрытие состояния и позднее связывание всего

        Мне кажется, как раз к лучшему, что его идею перевернули иначе. Я не думаю, что без наследования и полиморфизма было бы возможным вывести софт на новый уровень сложности в 1990-е.
          0

          Let the holy war begin!

            +1

            Полиморфизм его идеей подразумевается by design. Вот наследование в Smalltalk возможно было деталью реализации для DRY

              +1
              Self и JavaScript показывают, что в наследовании нет необходимости. Если из Smalltalk'а убрать явное наследование, много не поменяется — как я понимаю, отсюда и Self.
                +1
                Что в наследовании нет необходимости — показывал VB6.0. А JS показывает, что нет необходимости в классах (и то они оказались полезны).
                  –1
                  Я к JavaScript отношусь достаточно скептично. Он вообще является инструментом, который случайно оказался в нужном месте. Он больше показывает, что даже язык, при создании которого не думали ни про эффективность, ни про контроль ошибок разработчика, ни про продуктивность, а лишь про то, как можно было бы быстро на коленке что-то написать, может стать инструментом для разработки крупных проектов.
                    +1

                    В JavaScript наследование было изначально. Прототипное. Недвно добавили сахар для возможности его использования как классового.

                  0
                  Большие вопросы скорее вызывает то что Smalltalk не пошел в mainstream.
                  Его модель с передачей сообщений очень масштабируема не только в смысле параллельных вычислений, но и программирования для распределенных систем.
                  Даже самые примитивные операции выполняются только на сообщениях, и эта точка потенциального взрыва использования языка если думать про параллелизацию и distributed computing (микросервисы и вот это вот все).
                  И тем не менее, Smalltalk почти умер (несколько десятков энтузиастов и группа Pharo это не жизнь языка программирования), в чем же причины?
                    0
                    А есть ли будущее у технологии, если пойти дальше Smalltalk, и заменить модель сообщений запрос/ответ на чистую асинхронку и акторное программирование? Думаю такой язык был бы крайне интересен для современных задач по облачному программированию, GRID, микросервисов и т.п., если реализовать его как расширение для mainstream технологий поверх той же JVM.

                    Сейчас идет большой хайп про IoT, а как бы это не область где такой язык принципиально необходим, в виде полноценного LLVM-кросскомпилятора для встраиваемых систем. Go делает слишком жирные бинарники, минимум на порядок толще чем это оправдано на железе типа RT5350. И решилась бы проблема с интероперабельностью межде системами разных архитектур — сейчас передача данных по MQTT вызывает головную боль с выбором методов сериализации, пакеты длиной от 50 байт (LoRa), на принимающей стороне IoT платформ зоопарк библиотек и протоколов декодирования.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое