Так что же на самом деле имел в виду Алан Кей под термином «объектно-ориентированный»?

Как сообщается, Алан Кей является изобретателем термина «объектно-ориентированный». И его часто цитируют так, как будто он сказал, что то, что мы сегодня называем ОО, не имеет в виду.

Например, я только что нашел это в Google:

Я придумал термин «объектно-ориентированный» и могу сказать, что я не имел в виду C ++

- Алан Кей, OOPSLA '97

Я смутно помню , услышав что - то очень проницательный о том, что он сделал в виду. Что-то вроде «передачи сообщений».

Вы знаете, что он имел в виду? Не могли бы вы рассказать подробнее о том, что он имел в виду и чем он отличается от сегодняшнего общего ОО? Пожалуйста, поделитесь некоторыми ссылками, если у вас есть.

Благодарю.

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

Дата: среда, 23 июля 2003 г. 09:33:31 -0800 Кому: Стефану Раму [удален для конфиденциальности] От: Алану Кей [удален для конфиденциальности] Тема: Re: Разъяснение «объектно-ориентированного»

Привет стефан -

Извините за задержку, но я был в отпуске.

В 6:27 вечера +0200 17.07.03 Стефан Рам написал:

Уважаемый доктор Кей,

Я хотел бы иметь несколько авторитетных слов о термине «объектно-ориентированное программирование» для моей учебной страницы по этой теме. Единственными двумя источниками, которые я считаю «авторитетными», являются Международная организация по стандартам, которая определяет «объектно-ориентированный» в «ИСО / МЭК 2382-15», и вы, потому что, как говорится, вы придумали этот термин.

Я почти уверен, что сделал.

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

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

Когда и где был использован термин «объектно-ориентированный»?

В Юте, где-то после 66 ноября, когда под влиянием Sketchpad, Simula, дизайна для ARPAnet, Burroughs B5000 и моего опыта в биологии и математике, я подумал об архитектуре для программирования. Вероятно, это было в 1967 году, когда кто-то спросил меня, что я делаю, и я сказал: «Это объектно-ориентированное программирование».

Первоначальная концепция этого состояла из следующих частей.

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

• Я хотел избавиться от данных. B5000 почти сделал это благодаря своей невероятной архитектуре HW. Я понял, что метафора «клетка / весь компьютер» избавится от данных, и что «<-» будет просто еще одним символом сообщения (мне потребовалось довольно много времени, чтобы подумать об этом, потому что я действительно думал обо всех этих символах как об именах для функции и процедуры.

• Мои математические знания заставили меня осознать, что с каждым объектом может быть связано несколько алгебр, и их могут быть семейства, и это будет очень и очень полезно. Термин «полиморфизм» был введен гораздо позже (я думаю, Питер Вегнер), и он не совсем корректен, поскольку он действительно исходит из номенклатуры функций, и я хотел немного больше, чем функций. Я придумал термин «универсальность» для обозначения общего поведения в квазиалгебраической форме.

• Мне не понравилось, как Simula I или Simula 67 наследовали (хотя я думал, что Nygaard и Dahl были просто потрясающими мыслителями и дизайнерами). Поэтому я решил оставить наследование как встроенную функцию, пока не пойму ее лучше.

Мои оригинальные эксперименты с этой архитектурой были проведены с использованием модели, которую я адаптировал из «Обобщения Алгола» Ван Вейнгаартена и Вирта и Эйлера Вирта. Оба они были скорее похожи на LISP, но с более обычным читаемым синтаксисом. Я тогда не понимал идею монстра LISP о материальном метаязыке, но немного сблизился с идеями о расширяемых языках, основанных на различных источниках, включая IMP от Irons.

Вторая фаза этого состояла в том, чтобы наконец понять LISP и затем использовать это понимание, чтобы сделать намного более приятные и компактные, более мощные и более поздние связанные структуры. Тезис Дэйва Фишера был выполнен в стиле «Маккарти», и его идеи о расширяемых структурах управления оказались очень полезными. Другим большим влиянием в это время был ПЛАНЕР Карла Хьюитта (который так и не получил признания, которого заслуживает, учитывая, насколько хорошо и как раньше он смог предвидеть Пролог).

Оригинальный Smalltalk в Xerox PARC вышел из вышеперечисленного. На последующие Smalltalk жалуются в конце главы «История»: они отступили к Симуле и не заменили механизмы расширения более безопасными, которые были где-то настолько полезными.

Что для вас значит «объектно-ориентированное [программирование]»? (Вводное руководство не требуется, просто краткое объяснение [как, например, «программирование с наследованием, полиморфизмом и инкапсуляцией») в терминах других концепций для читателя, знакомого с ними, если это возможно. Также нет необходимости объяснять «объект» ", потому что у меня уже есть источники с вашим объяснением" объекта "из" Ранней истории Smalltalk ".)

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

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

[Кроме того] Одна из вещей, которые я должен был упомянуть, это то, что Симула был катализатором двух основных путей. Первым (просто случайно) был маршрут био / сети без данных, который я выбрал. Другой, который появился немного позже как объект исследования, был абстрактными типами данных, и это получило гораздо больше удовольствия.

Если мы посмотрим на всю историю, мы увидим, что прото-ООП началось с ADT, имело небольшую развилку в направлении того, что я назвал «объектами» - это привело к Smalltalk и т. Д., - но после небольшой развилки, Создание CS в значительной степени сделало ADT и хотело придерживаться парадигмы обработки данных. Исторически, стоит взглянуть на файловую систему USAF Burroughs 220 (которую я описал в истории Smalltalk), раннюю работу Дуга Росса в MIT (AED и ранее), в которой он выступал за встраивание указателей процедур в структуры данных, Sketchpad (который имел полный полиморфизм - где, например, одно и то же смещение в его структуре данных означало «отображение», и был бы указатель на соответствующую подпрограмму для типа объекта, который представляет структура, и т. д., и Burroughs B5000, чьи справочные таблицы программ были настоящими «большими объектами» и содержали указатели на «данные» и «процедуры», но часто могли делать правильные вещи, если пытались найти данные и нашли указатель на процедуру. И самой первой проблемой, которую я решил с моими ранними работами в Юте, было «исчезновение данных» с использованием только методов и объектов. В конце 60-х (я думаю) Боб Бальцер написал довольно изящную статью под названием «Программирование без данных», а вскоре после этого Джон Рейнольдс написал не менее изящную статью «Gedanken» (в 1970 году, я думаю), в которой он показал, что с помощью лямды правильные выражения позволят абстрагировать данные с помощью процедур. но часто может делать правильные вещи, если пытается найти данные и находит указатель на процедуру. И самой первой проблемой, которую я решил с моими ранними работами в Юте, было «исчезновение данных» с использованием только методов и объектов. В конце 60-х (я думаю) Боб Бальцер написал довольно изящную статью под названием «Программирование без данных», а вскоре после этого Джон Рейнольдс написал не менее изящную статью «Gedanken» (в 1970 году, я думаю), в которой он показал, что с помощью лямды правильные выражения позволят абстрагировать данные с помощью процедур. но часто может делать правильные вещи, если пытается найти данные и находит указатель на процедуру. И самой первой проблемой, которую я решил с моими ранними работами в Юте, было «исчезновение данных» с использованием только методов и объектов. В конце 60-х (я думаю) Боб Бальцер написал довольно изящную статью под названием «Программирование без данных», а вскоре после этого Джон Рейнольдс написал не менее изящную статью «Gedanken» (в 1970 году, я думаю), в которой он показал, что с помощью лямды правильные выражения позволят абстрагировать данные с помощью процедур.

Люди, которым нравились объекты как данные, были меньше по численности, включая меня, Карла Хьюитта, Дэйва Рида и некоторых других - в значительной степени вся эта группа была из сообщества ARPA и так или иначе была вовлечена в дизайн ARPAnet → Интернет, в котором основной единицей вычислений был целый компьютер. Но просто для того, чтобы показать, насколько упрямо может держаться идея, в течение семидесятых и восьмидесятых годов, было много людей, которые пытались обойтись с помощью «Удаленного вызова процедур» вместо того, чтобы думать об объектах и ​​сообщениях. Sic Transit Gloria Mundi.

Ура,

Алан Кей

Большая часть, если не все, что Алан Кей подразумевал под объектной ориентацией , воплощена в языке Smalltalk.

Кроме того, с http://en.wikipedia.org/wiki/Message_passing#Influences_on_other_programming_models :

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

Большая часть, если не все, что Алан Кей подразумевал под объектной ориентацией, воплощена в языке Smalltalk.

«Мы даже не реализовали всю идею в PARC. Многие из идей актеров Карла Хьюитта, которые были инициированы оригинальным Smalltalk, были больше в духе ООП, чем последующие Smalltalks. Значимые части Erlang больше похожи на настоящий язык ООП. текущий Smalltalk и, конечно, языки на основе C, которые были нарисованы с помощью «ООП-краски». "

Взято из комментария Алана Кея по адресу:

http://computinged.wordpress.com/2010/09/11/moti-asks-objects-never-well-hardly-ever/

Один из основных моментов, которые я извлек из изучения работ Алана Кея и других, таких как Джим Коплиен, заключается в том, что настоящее «объектно-ориентированное» программирование направлено на моделирование компьютеров и программного обеспечения с точки зрения ментальных моделей ЧЕЛОВЕКА / ПОЛЬЗОВАТЕЛЯ, а не на просто инструмент для программистов.

Насколько я понимаю, видение ООП Алана делало компьютер инструментом, позволяющим пользователю-человеку делать все, что он хочет: все возможности компьютера напрямую предоставляются конечному пользователю через интуитивно понятную интерактивную модель. Я должен иметь возможность просматривать и лепить объекты времени выполнения и взаимодействия ПРЯМО, а не только через код.

Вот пост о моих планах попробовать какую-то версию этого в JavaScript в качестве доказательства концепции: http://www.cemetech.net/forum/viewtopic.php?p=234494#234494

С точки зрения разработки / программирования программного обеспечения, Джим Коплиен говорит о том, как код может и ДОЛЖЕН быть похожим на его ментальную модель. То есть код читается почти так же, как и человек, описывающий его поведение. Это в значительной степени достигается путем мышления в терминах ОБЪЕКТОВ, а не в терминах КЛАССОВ и ВИДОВ. Поведение описывается на терминах РОЛ, играемых объектами, а не как часть определения ИДЕНТИЧНОСТИ объекта. Вы должны быть в состоянии смоделировать взаимодействия на терминах объектов, которые определяются ролей, которую они играют во взаимодействии. Вот как работают человеческие ментальные модели: официант, клиент, кассир, исходный счет, целевой счет ... Это РОЛИ, а не ТИПЫ, и вы хотите иметь возможность определять методы для "любого объекта, который играет эту роль в данный момент" »,