Из какого классического первоисточника это определение? Я встречал его во многих источниках — интересно какой был первый ;)
Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в The Early History Of Smalltalk, но скорее всего она и раньше публиковалась в статьях на эту тему.
В принципе я не против содержательной философии, но тут она явно избыточна и только наводит тумана.
Давайте я вам расшифрую, "Everything is an object" означает только одно: никакой код, из написанного вами, не может выполняться вне объекта. Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
Иногда отрисовка «кнопочек», т.е. элементов контроля GUI это логика предметной области: нпр., клетки периодической таблицы (не обязательно прямоугольные).
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете? В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев. Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. А не в том, что кружочки никогда не понадобятся. Может и понадобятся пару раз за 10 лет… Кто вас знает, может вам даже кролики, унаследованные от Animal, понадобятся для периодической таблицы. Вот только в ежедневной работе программисты другими вещами занимаются.
Термин «извращение» не мат. термин
В контексте данной дискуссии этот термин используется лишь для сокращения "делать простые вещи сложным и нестабильным способом", в простонародье "через задницу", например: имея 2 руки, управлять трекпадом ногой.
Кстати, каким боком цитата про то, что 17 лет назад в .NET включили средства для работы с COM+, доказывает актуальность CORBA в наши дни?
Т.е. никакой из существующих ЯП такой механизм не использует?
Использует (напр. Erlang, Elixir, LFE и т.д.), но не буду же я вас через комментарии новому ЯП учить. Это к вашему изначальному непониманию чем сообщения удобнее методов отношения не имеет.
sendMsgAsync посылает сообщение определенному объекту (объектам) или всем объектам в инете?
Разумеется конкретному, я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
Каждый объкт, принявший сообщение, дожен на него реагировать или игнорировать? Т.е. должен тратить время на каждое сообщение?
И что?
Должен быть единый список сообщений, понятный всем объектам?
Нет.
Какой формат сообщения? (сколько в нем полей, символов, целых и нецелых чисел и т.д.)
Любой. Any Data.
Если сообщения в инете, то они должны шифроваться для безопасности?
Да, такая опция есть. Однако, даже если объекты на разных машинах, они не обязательно выставляются в инет, есть локальные сети в пределах одного ДЦ для этого.
Есть много статей на подобные узко-специальные темы, почему я должен был не упустить и упомянуть именно эту?
Потому что она на тему ООП. И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk и c Erlang/Elixir. А до тех пор вы будете не в теме. То, что вам на текущем этапе знакомо это не ООП, это попытка добавить часть идей ООП в Pascal.
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
Everything is an object.
Objects communicate by sending and receiving messages (in terms of objects).
Objects have their own memory (in terms of objects).
Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
Рисование графических примитивов очень важная практическая цель любого универсального программирования, нпр., для GUI
Да что вы говорите… и что же в GUI есть кроме прямоугольников, которые по-хорошему рендерит ОС (мы же хотим нативный look-n-feel, не так ли), используя процедурный код?
Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.
Чем это отличается от передачи событий ОС, нпр., Виндов ХР? Для обменов клиент-сервер обычно применяют технологии типа COM и, даже, CORBA.
Мы тут ООП обсуждаем, а не Виндов ХР. Вы предлагаете обмен сообщениями между объектами вести не средствами ЯП, а средствами ОС? Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа COM и CORBA (неужели это кто-то до сих пор использует?). Они все нафиг не нужны, когда у вас есть ООП на базе классического определения.
Если у вас есть ООП — у вас уже есть клиент-серверное программирование. Если его нет, то у вас нет и ООП. Вот цитата с OOPSLA 1997:
"So this is an early insight that objects basically are like servers. This notion of polymorphism, which used to be called generic procedures is a way of thinking about classes of these servers. Everybody knows about that."
Только задумайтесь, 22 года назад все знали, что объекты должны играть роль минисерверов. А сейчас приходится это разжёвывать.
Какой это ЯП? Что означает в ":ok" двоеточие? что значат фигурные скобки в "{:ok, event} = sendMsg(eventEnricher, event)"?
Можете считать это псевдокодом. Вчитайтесь в суть, а не в синтаксис. Фигурные скобки — это кортеж. :ok — статус, проверяемый через pattern-matching. Если будет не :ok, то дальше код не пойдёт.
P.S. Почитайте статью, которую вы упустили из виду.
Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.
Было сказано, но не мной )
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
Возьмем класс TRect из моего примера.
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Пока преимуществ не видно?
Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.
Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.
Потому что это специализация по сфере деятельности. Невозможно одинаково хорошо владеть и веб-разработкой, и мобильной, и разработкой под встраиваемые устройства, и т.д. Но даже внутри одной специализации вам всё равно необходимо знать несколько языков.
Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.
Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".
Ага, даже интересно посмотреть на такого кадра, который возьмёт на позицию мидла человека с резюме "в течение года учил Python на курсах".
Я понимаю, что пост — реклама Geekbrains, но нельзя же настолько топорно впаривать.
Вот ещё фееричный пассаж:
В базовой конфигурации Python лежит около 70 функций и несколько десятков зарезервированных слов, но даже крутой программист не обязательно использует их все. То есть, чтобы выучить сотню слов и понять, что они делают, можно потратить одну-три недели при желании и активной работе
Это из серии: в русском языке всего 33 буквы, то есть чтобы их выучить достаточно потратить один-три дня. Про то, что это никак не связано с умением выражать свои мысли на языке и вообще неважно сколько там функций и зарезервированных слов, почему-то умолчали.
Мы запускаем цикл статей в которых подробно расскажем о каждой профессии через опыт людей. В первом выпуске обсуждаем Python-разработчиков.
Кхм, а ничего, что не существует такой профессии?
Профессия называется инженер-программист. А инженер-программист, владеющий только одним языком программирования, — это примерно как столяр, который только одним видом пилы умеет пользоваться.
То что есть — какое-то адово убожество в 2Мп максимум, непригодное ни для чего.
Хм, я сначала вам не поверил… а потом поискал и убедился :-(
А ведь 10 лет назад были с 3.2Мп и вполне прилично снимали, на Sony Ericsson например. И даже какие-то модели с 8Мп были. Странно, зачем было делать деградацию камер на обычных телефонах?
Теперь нам приходится смириться с фактом, что свет, по-видимому, состоит из квантов, и кванты являются одновременно как частицами, так и волнами.
Не только свет, но и вообще всё состоит из волн, вся Вселенная — большая интерференционная картина. А представление в виде частиц — это просто следствие эффекта наблюдателя. Точно так же как в компьютере всё состоит из нулей и единиц, а то что мы на этой странице видим какие-то комментарии и форму ответа — не более чем эффект наблюдателя.
В этой цитате речь идёт только про синтаксис. На него в принципе без разницы. А в цитате выше речь была про то, что изменился механизм отправки сообщений и механизм приёма сообщений.
Хотя насчёт "too much freedom" я тоже не согласен. Когда получатель письма диктует отправителю в каком формате надо это письмо писать, это уже и не письмо, а заполнение анкеты. Так что ввод синтаксических ограничений тоже можно поставить в минус Smalltalk, но это не главное.
Так в этом то и вопрос, остались ли они сообщениями или стали замаскированными вызовами методов? Всё говорит в пользу второго. Но Вы упрямитесь и не хотите это признавать и готовы спорить хоть лично с Кэем, но почему-то тут, а не на Quora, где у него был бы шанс вам ответить.
Это не аналог исключений. Это основа для любой отказоустойчивой распределенной системы, обязательная часть её штатной работы (см. принцип Let It Crash).
Если бы этого не было, если бы пришлось думать о таких случаях как о чём-то исключительном, то систему пришлось бы назвать слишком сложной, более того она бы реально была бы крайне сложной.
Но именно общение акторов через честную передачу сообщений позволяет системе оставаться относительно простой. Поэтому ваши аргументы, что что-то подобное можно накостылить какими-то воркэраундами тут и не принимают. Нельзя ключевой аспект языка реализовывать через воркэраунды, он должен быть неотъемлемой частью.
Он говорит про 71–72 гг, какие еще слова он должен использовать?!? Прошу прощения, но это уже чушь какая.
Если бы сообщения в Smalltalk остались такими же по сей день, то ему не пришлось бы рассказывать про 72 год. Или он смог бы написать: "From the earliest versions of Smalltalk and till now a message send is ..." и так далее в Present Simple. Не согласны?
Точнее, он определил диапазон:
223/71 < π < 22/7
Если для него взять среднее, то получится 3.1418511
В статье же есть намёк на методику расчёта. Получается от $100 млн.
Тот, кто ввёл термин ООП (Алан Кэй), тот и был первым, очевидно же. Цитату можно найти в The Early History Of Smalltalk, но скорее всего она и раньше публиковалась в статьях на эту тему.
Давайте я вам расшифрую, "Everything is an object" означает только одно: никакой код, из написанного вами, не может выполняться вне объекта. Другими словами, если вы пользуетесь вещественными числами внутри метода, то это ok. Если вне, то у вас не ООП.
Непрямоугольные клетки периодической таблицы? Вы меня троллить начинаете? В любом случае, это всё крайне редкие кейсы, которые встречаются может в 0.001% случаев. Мой пойнт был в том, что обучать людей на оторванных от промышленной разработки примерах — это своего рода диверсия. А не в том, что кружочки никогда не понадобятся. Может и понадобятся пару раз за 10 лет… Кто вас знает, может вам даже кролики, унаследованные от Animal, понадобятся для периодической таблицы. Вот только в ежедневной работе программисты другими вещами занимаются.
В контексте данной дискуссии этот термин используется лишь для сокращения "делать простые вещи сложным и нестабильным способом", в простонародье "через задницу", например: имея 2 руки, управлять трекпадом ногой.
Кстати, каким боком цитата про то, что 17 лет назад в .NET включили средства для работы с COM+, доказывает актуальность CORBA в наши дни?
Использует (напр. Erlang, Elixir, LFE и т.д.), но не буду же я вас через комментарии новому ЯП учить. Это к вашему изначальному непониманию чем сообщения удобнее методов отношения не имеет.
Разумеется конкретному, я ж взял синтаксис из вашего собственного примера. Первый аргумент — это и есть объект-получатель.
И что?
Нет.
Любой. Any Data.
Да, такая опция есть. Однако, даже если объекты на разных машинах, они не обязательно выставляются в инет, есть локальные сети в пределах одного ДЦ для этого.
Потому что она на тему ООП. И если вам интересна эта тема, то вам придётся ознакомиться и со Smalltalk и c Erlang/Elixir. А до тех пор вы будете не в теме. То, что вам на текущем этапе знакомо это не ООП, это попытка добавить часть идей ООП в Pascal.
Давайте без испорченных телефонов, сразу к первоисточникам. Вот классическое определение ООП:
Как видите, тут нет никакого требования чтобы сообщения были объектами. Детали реализации Smalltalk — это детали реализации конкретного языка, они к сути вопроса отношения не имеют.
Да что вы говорите… и что же в GUI есть кроме прямоугольников, которые по-хорошему рендерит ОС (мы же хотим нативный look-n-feel, не так ли), используя процедурный код?
Да и если вы не разработчик GUI framework, то это вообще вас не касается. Вы ООП для бизнес-логики используете, а не для отрисовки кнопочек.
Мы тут ООП обсуждаем, а не Виндов ХР. Вы предлагаете обмен сообщениями между объектами вести не средствами ЯП, а средствами ОС? Ну и я же написал, что я в курсе наличия извращений разных сортов, в том числе типа COM и CORBA (неужели это кто-то до сих пор использует?). Они все нафиг не нужны, когда у вас есть ООП на базе классического определения.
Если у вас есть ООП — у вас уже есть клиент-серверное программирование. Если его нет, то у вас нет и ООП. Вот цитата с OOPSLA 1997:
"So this is an early insight that objects basically are like servers. This notion of polymorphism, which used to be called generic procedures is a way of thinking about classes of these servers. Everybody knows about that."
Только задумайтесь, 22 года назад все знали, что объекты должны играть роль минисерверов. А сейчас приходится это разжёвывать.
Много чего есть… Можете ознакомиться: https://en.wikipedia.org/wiki/Programming_paradigm
Но если хотите предметно поговорить про ООП, то сначала ознакомьтесь с этой частью:
Actor-based OOP (ближе всего к классическому ООП)
Можете считать это псевдокодом. Вчитайтесь в суть, а не в синтаксис. Фигурные скобки — это кортеж. :ok — статус, проверяемый через pattern-matching. Если будет не :ok, то дальше код не пойдёт.
P.S. Почитайте статью, которую вы упустили из виду.
Я думаю, VolCh справедливо имеет в виду, что основной этап создания объекта — это аллокация памяти для него. В большинстве ЯП этот этап скрыт и не прописывается в конструкторе.
И тем не менее, ни одна из этих профессий не ограничивается знанием Python.
Было сказано, но не мной )
Я не согласен, что сообщения должны быть объекты (такого требования нет в определении ООП), скорее наоборот они обязаны не быть объектами.
Эх, когда ж уже из разговоров про ООП уйдут эти прямоугольники, круги и животные? А авторов, которые такие примеры в книгах используют, разместят на большую доску позора. Всё это настолько безумно далеко от практических целей ООП, что дальше некуда. И на этих вырожденных и абсолютно бесполезных примерах любые преимущества (даже ООП vs ПП) высосаны из пальца.
Давайте возьмёт лучше пример поближе к реальности. Допустим, к вам в систему приходят какие-то эвенты (обычная структура данных типа ассоциативного массива) от пользователей. Что вам нужно с этим сделать?
Очевидно прокинуть эвент для обработки ряду объектов.
Пока преимуществ не видно?
Но давайте представим, что этим объектам не обязательно находится на одном сервере. В случае, с вызовом метода — это невозможно, все объекты должны быть в памяти процесса, чтобы можно было вызвать их методы. Для передачи сообщений такого ограничения нет, и все 4 объекта из примера могут находиться на разных серверах (масштабируемость из коробки).
Теперь представьте, что с объектом logger что-то случилось, например упал с ошибкой. Достаточное ли это условие, чтобы похерить всю обработку эвента? В большинстве систем обработка эвента гораздо важнее его логирования. Но чтобы обеспечить пропуск опциональных шагов, вам придётся каждый из их завернуть в try (мда, ппц как удобно). В случае с сообщениями, вы можете легко сделать sendMsgAsync и не ждать возврата результата, когда он не важен. Бонусом, вы получаете возможность все опциональные действия выполнять в отдельном потоке. А что будет с нашим упавшим из-за какого-то хитрого эвента логгером? А он зареспаунится с исходного состояния, без необходимости восстанавливать что-то после сбоя, без необходимости перемешивать обработку ошибок с бизнес-логикой и т.д.
Я в курсе сколько костылей напридумано, чтобы получить похожие результаты в ООП с вызовом методов. Однако для этого достаточно перейти на передачу сообщений между объектами.
Да вроде Embarcadero ещё жива, и буквально полгода назад свежий релиз Delphi был.
Lazarus опять же есть. Так что поучиться есть на чём.
Потому что это специализация по сфере деятельности. Невозможно одинаково хорошо владеть и веб-разработкой, и мобильной, и разработкой под встраиваемые устройства, и т.д. Но даже внутри одной специализации вам всё равно необходимо знать несколько языков.
Сообщение — это вообще данные, причём тут конструкторы/деструкторы?
А лучше тем, что объекты, общающиеся передачей сообщений, не связаны жёстко друг с другом, соответственно на порядки проще становится писать надёжные и масштабируемые системы.
Ну, я не стал в очередной раз по бедной букве Ё проходиться )))
Не удобнее, а проще в реализации с приемлемой скоростью. Впрочем, с тех пор уже столько лет утекло, что теперь единственным аргументом за вызов метода остался "привычнее".
Ага, даже интересно посмотреть на такого кадра, который возьмёт на позицию мидла человека с резюме "в течение года учил Python на курсах".
Я понимаю, что пост — реклама Geekbrains, но нельзя же настолько топорно впаривать.
Вот ещё фееричный пассаж:
Это из серии: в русском языке всего 33 буквы, то есть чтобы их выучить достаточно потратить один-три дня. Про то, что это никак не связано с умением выражать свои мысли на языке и вообще неважно сколько там функций и зарезервированных слов, почему-то умолчали.
Кхм, а ничего, что не существует такой профессии?
Профессия называется инженер-программист. А инженер-программист, владеющий только одним языком программирования, — это примерно как столяр, который только одним видом пилы умеет пользоваться.
Хм, я сначала вам не поверил… а потом поискал и убедился :-(
А ведь 10 лет назад были с 3.2Мп и вполне прилично снимали, на Sony Ericsson например. И даже какие-то модели с 8Мп были. Странно, зачем было делать деградацию камер на обычных телефонах?
Не только свет, но и вообще всё состоит из волн, вся Вселенная — большая интерференционная картина. А представление в виде частиц — это просто следствие эффекта наблюдателя. Точно так же как в компьютере всё состоит из нулей и единиц, а то что мы на этой странице видим какие-то комментарии и форму ответа — не более чем эффект наблюдателя.
В этой цитате речь идёт только про синтаксис. На него в принципе без разницы. А в цитате выше речь была про то, что изменился механизм отправки сообщений и механизм приёма сообщений.
Хотя насчёт "too much freedom" я тоже не согласен. Когда получатель письма диктует отправителю в каком формате надо это письмо писать, это уже и не письмо, а заполнение анкеты. Так что ввод синтаксических ограничений тоже можно поставить в минус Smalltalk, но это не главное.
Так в этом то и вопрос, остались ли они сообщениями или стали замаскированными вызовами методов? Всё говорит в пользу второго. Но Вы упрямитесь и не хотите это признавать и готовы спорить хоть лично с Кэем, но почему-то тут, а не на Quora, где у него был бы шанс вам ответить.
Это не аналог исключений. Это основа для любой отказоустойчивой распределенной системы, обязательная часть её штатной работы (см. принцип Let It Crash).
Если бы этого не было, если бы пришлось думать о таких случаях как о чём-то исключительном, то систему пришлось бы назвать слишком сложной, более того она бы реально была бы крайне сложной.
Но именно общение акторов через честную передачу сообщений позволяет системе оставаться относительно простой. Поэтому ваши аргументы, что что-то подобное можно накостылить какими-то воркэраундами тут и не принимают. Нельзя ключевой аспект языка реализовывать через воркэраунды, он должен быть неотъемлемой частью.
Если бы сообщения в Smalltalk остались такими же по сей день, то ему не пришлось бы рассказывать про 72 год. Или он смог бы написать: "From the earliest versions of Smalltalk and till now a message send is ..." и так далее в Present Simple. Не согласны?