Комментарии 310
ООП — это архитектура приложения
Внезапно, нет. Это никак не вытекает из того, что вы выше цитируете из Кея.
Мне показалось что именно эта платформа подошла ближе всего к понятию ООП.
Вы, видимо, ничего не слышали про модель акторов.
Или взять актуальную в последнее время систему микросервисов, которые общаются посредством RESTfull API & Webhooks. Каждый такой веб-сервис является по своей сути объектом в понятии ООП как это видит автор.
Тоже нет. В RESTful API принципиально не должно быть внутреннего состояния, и там нет никаких сообщений.
Впрочем, главная ваша ошибка в том, что вы пытаетесь судить об ООП, как оно есть сейчас, по словам автора, который когда-то этот термин придумал, но на индустрию после этого не влиял. Вы не задумывались, что некоторые термины эволюционируют сами?
Люди начинают судить о том что ООП плохо или хорошо на основании некого своего или агрегированного понятия, не принимая во внимание суть понятия которое вкладывал в него автор.
Также мне не дает покоя мысль о том что единственная система которая первая подошла близко к сути этого понятия вдруг стала №1 в мире. Совпадение? :)
Люди начинают судить о том что ООП плохо или хорошо на основании некого своего или агрегированного понятия, не принимая во внимание суть понятия которое вкладывал в него автор.
Так я об этом и говорю: уже не так важно, что именно вкладывал автор, с тех пор индустрия изменилась, и понятие тоже изменилось вместе с индустрией. Можно обсуждать, плохо это или хорошо, но это уже так, и это уже данность.
Также мне не дает покоя мысль о том что единственная система которая первая подошла близко к сути этого понятия вдруг стала №1 в мире. Совпадение?
Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.
Во-вторых, она "первая подошла близко к сути этого понятия" тоже только по вашему мнению — вы проигнорировали мой вопрос про модель акторов.
Как сказал автор ООП «ошибка в формулировке привела к тому что программисты начали мыслить мелко». Я склонен ему верить. И развиваю его идею о том что объекты поняты обшибочно да и не важны. Вся соль и суть в способности компонентов обмениваться сообщениями. То на что почти никто не обращает внимание.
Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.
Так давайте уточним критерии. Их не много.
1. Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов. Другими словами более 25% Интернет адресов. Это достаточно объективный критерий с точки зрения одной из самых крупных систем в мире.
2. Количество специалистов и информационных материалов (в России этот показатель конечно пока под вопросом, но скоро думаю выровняется к мировому первенству)
3. Количество готовых компонентов
Их реально больше. Но для начала хватит 3-х. По этим критериям нет ни одной другой веб системы которая хоть как то могла бы конкурировать с WP.
Во-вторых, она «первая подошла близко к сути этого понятия» тоже только по вашему мнению — вы проигнорировали мой вопрос про модель акторов.
Критерии и цитаты на основании которых я сделал такой вывод описал в статье.
Не понятно каким образом сюда можно отнести модель акторов?
Модель акторов не применял. И плохо понимаю причем тут она [...] Вся соль и суть в способности компонентов обмениваться сообщениями.
При том, что в модели авторов происходит ровно то, что описано у Кея: независимые объекты (акторы) обмениваются сообщениями. Все.
Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов. Другими словами более 25% Интернет адресов. Это достаточно объективный критерий с точки зрения одной из самых крупных систем в мире.
Нет. Вы забываете про то, что есть не веб-системы (а уж количество и сложность вообще никак не коррелируют). Попробуйте сделать на WP систему управления станком с ЧПУ, что ли...
Количество специалистов и информационных материалов
Не имеет никакого отношения к качеству самой системы (даже если это утверждение верно, во что я не очень верю).
Количество готовых компонентов
Банальная ложь: скажем, для .net framework готовых компонентов заведомо больше.
Критерии и цитаты на основании которых я сделал такой вывод описал в статье.
Это только слова. Покажите конкретные примеры архитектуры и кода, которые подтвердят, что WP действительно устроен так, как вы ему приписываете.
Не понятно каким образом сюда можно отнести модель акторов?
Выше уже написано.
При том, что в модели авторов происходит ровно то, что описано у Кея: независимые объекты (акторы) обмениваются сообщениями. Все.
Это здорово. Вот только меня смущает тот факт что я этого не встречал в реальном мире. Как много систем использует эти механизмы?
Если они так редки то что можно сказать о их качестве и адекватности?
Нет. Вы забываете про то, что есть не веб-системы
Я про них не забыл. Просто убрал из внимания как мало используемые и слишком простые. Любая система которая находится вне веб зачастую очень простая и не может превращаться в достаточно сложную. А именно это ставил во главу угла Ален Кей.
Опять же это мой опыт. Я когда то занимался создание сложных систем для управления большими организациями. И все что было не веб — умирало рано или поздно просто потому что не могло выдержать расширения и масштабирования. Единственная область технологий которая доказала свою способсность масштабироваться и развиваться — это веб. Потому и рассматриваю только эту часть. Потому что все остальное не требовательно к ООП в той форме которую пытался описать автор. Другими словами там может работать любой тип ООП, даже тот который придуман в C++.
Банальная ложь: скажем, для .net framework готовых компонентов заведомо больше
А подтвердить? Или тут на хабре принято просто обвинять людей во лжи без оснований?
Для WP по последним данным готовых компонентов только в одном официальном каталоге около 46 000 https://wordpress.org/plugins/
А еще есть бесчисленное множество не официальных каталогов и просто компонентов которые лежат на GitHub.
Есть данные о числе компонентов под .net? Или ваши слова ничем не подтверждены и являются лишь вашими догадками?
Вот только меня смущает тот факт что я этого не встречал в реальном мире.
Ну так пойдите и познакомьтесь.
Как много систем использует эти механизмы?
Сколько-то.
Если они так редки то что можно сказать о их качестве и адекватности?
Вы ничего не знаете об их редкости. И, что характерно, редкость никак не связана с качеством и/или адекватностью. Систем управления ядерными реакторами меньше, чем сайтов, но это не значит, что они "менее адекватные".
Просто убрал из внимания как мало используемые и слишком простые.
Серьезно? Слишком простые? АБС банка — слишком простая? Биллинг сотового оператора — слишком простой? Система бронирования авиабилетов — слишком простая? Глобальный месседжнер, навроде WhatsApp — слишком простой?
(я пока даже не беру инфраструктурные вещи типа распределенной базы данных, которая тоже сложнее большей части веб-сайтов)
Я когда то занимался создание сложных систем для управления большими организациями.
И много вы знаете сложных систем для управления большими предприятиями, написанных на WP?
А еще вы путаете веб-сайты, по которым считается статистика использования, и системы с веб-интерфейсом, которые (а) зачастую вообще не видны из веба и (б) превосходят "обычный" веб-сайт по сложности на два порядка.
Для WP по последним данным готовых компонентов только в одном официальном каталоге около 46 000 https://wordpress.org/plugins/
А еще есть бесчисленное множество не официальных каталогов и просто компонентов которые лежат на GitHub.
Есть данные о числе компонентов под .net?
There are 60,966 packages. Это не считая того факта, что в .net каждый класс — это "компонент" в терминах обмена сообщениями.
Ну так пойдите и познакомьтесь.
Сколько-то.
Ты случаем не вегетарианец? Чето какой то напряженный. С таким уровнем аргументации боюсь мало смысла пытаться с тобой общаться. Ты дыши глубже если так нервничаешь и начинаешь так опускаться по мышлению. Либо надо прекращать это. Не дай бог клавиши сломаешь.
There are 60,966 packages
Ты почитай что там за компоненты. Это jQuery, Bootstrap, AngularJS. Я боюсь тебя огорчить но это не компоненты для .net. Это библиотеки для фронта.
Если собирать такие компоненты под WP то можно случайно за 100 000 перевалить. Давай играть честно. Или не играть тогда уж.
Вот аргументы и кончились. Обидно.
Так общайтесь на другом, кто ж вам мешает.
Ты же приводишь аргументы уровня «ну так пойди и познакомься», далее «сколько-то». Единственный числовой фактор который ты привел на проверку оказался лживым и имеющим кучу помех.
Вопрос не в том как я общаюсь. А в том как ты. Будь тут хоть один разумный аргумент, я бы продолжил. А так ну нафиг.
https://habrahabr.ru/company/mailru/blog/307168/#comment_9736410
Это здорово. Вот только меня смущает тот факт что я этого не встречал в реальном мире. Как много систем использует эти механизмы?
Достаточно. Посмотрите в сторону Akka или там Rx, на которых строятся большие масштабируемые системы (как пример тот же Яндекс) и не очень большие (тот же Rx, используется в Android-приложениях).
Кстати говоря, то что Вы описали, есть ничто иное, как микромодульная архитектура.
Нет. Вы забываете про то, что есть не веб-системы
Я про них не забыл. Просто убрал из внимания как мало используемые и слишком простые. Любая система которая находится вне веб зачастую очень простая и не может превращаться в достаточно сложную.
Давайте рассмотрим, например, такую не веб программы как операционные системы Windows и Linux. Можете привести мне в пример веб программы большей сложности?
1. Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов.
А почему вы сайты на вордпресе считаете за отдельный сайт, а странички в фейсбуке или вконтакте нет? Просто потому что у них домен второго уровня что ли?
WP — охватывает более 25% веб сайтов.
Вот у нас на 1-м домене: часть адресов отдаётся CMS-кой, часть адресов — api (реализованный на Spring), часть — SPA-админки, использующие это апи. По сложности, api и админки намного превосходят CMS-составляющую, однако, т.к. эти страницы недоступны для роботов, то в статистику попадёт только CMS. И таких примеров среди ИТ-компаний очень много. А если же посмотреть внимательнее, то на деле львиная доля от этих 25-ти процентов WP-сайтов по своей сути простые лендинги/бложики/новостные сайты.
Ну ок, WP тут на первом месте. Но это никак не подтверждает и не опровергает, что он хорошо подходит для чего-то более серьёзного, чем типовые сайты.
С другой стороны, сколько, например, онлайн-банков построены на WP? Сколько на WP написано enterprise-систем? Сколько проектов/сайтов/приложений гугла, яндекса или других крупных IT-компаний используют WP?
Выводы сделать нетрудно.
Так я об этом и говорю: уже не так важно, что именно вкладывал автор, с тех пор индустрия изменилась, и понятие тоже изменилось вместе с индустрией. Можно обсуждать, плохо это или хорошо, но это уже так, и это уже данность.
Разрешите выразить своё полное согласие!
Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.
Есть вот такая CMS — Drupal. Там тоже хуки и она постарше вордпресса наверное будет. Тем не менее популярности в ней меньше. Так что даже если вдруг WP действительно номер один — причина этого явно не только в хуках и всём таком.
Не существует общественного консенсуса о том что такое ООП
Есть-есть. Например, есть вполне общераспространеннное мнение, что ООП — это не ФП или не ПП. Используя этот набор отрицаниц, можно создать некий взгляд.
Согласитесь, было бы очень странно если бы вы встретились с Аланом Кеем и начали бы ему рассказывать о правильном взгляде на ООП, а он бы только и делал, что удивлялся сокрушаясь как он отстал от жизни.
Тем не менее, это именно то, что послужило поводом для его "разъяснений" о его понимании ООП — чье-то обсуждение о природе/определении.
И нет, я не вижу ничего странного в том, чтобы, встретившись с АК, рассказать, что нынче в мейнстриме называют ООП, и услышать его реакцию. Другое дело, что непонятно, зачем это надо.
Есть-есть. Например, есть вполне общераспространеннное мнение, что ООП — это не ФП или не ПП. Используя этот набор отрицаниц, можно создать некий взгляд.
Был бы консенсус, не было бы споров. Наиболее широко распространенное мнение — да, консенсус — нет.
И нет, я не вижу ничего странного в том, чтобы, встретившись с АК, рассказать, что нынче в мейнстриме называют ООП, и услышать его реакцию.
Рассказать Кею, что в мире делается и предложить ему скорректировать ему свою картину мира, это все-таки не одно и тоже.
Как я написал ниже, Drupal вот тоже модульный и на хуках. И чего-то такой популярности не получил.
суть понятия которое вкладывал в него автор
Алан просто придумал одно, а высказал — другое. Современное понятие ООП от этого не поменяется.
Алан просто придумал и сказал одно, а поняли и начали развивать другое. Вот так точнее.
На выходе имеем хитрый и запутанный омоним. Одно слова и два значения.
Это как слово «ножка» — может быть речь о части тела человека? а может быть о части мебели на которой сидят?
Слово одно — но получило множество значений.
Также и с ООП. Тот кто придумал это понятие думал об одном и это понятие также живет и развивается. Этот подход жив и многие его используют. Но называют его иначе или чаще всего вообще никак не называют.
Но авторы C++ назвали этим словом некий свой механизм, который ассоциируется с классами, инкапсуляцией и наследованием. Развивается параллельно и имеет мало пересечений с тем значением которое было изначально.
Суть и смысл статьи не в том чтобы пытаться менять то ООП которое «классы», а в том чтобы знать правду и что существует второе значение у ООП, которое имелось ввиду автором. Оба инструмента крайне эффективны и полезны если их знать, понимать и уметь применять. Это я говорю как человек которые применяет оба инструмента в работе каждый день. У них реально мало общего — разве что звучание, один автор и то что оба применяются в ИТ. Но по сути это два абсолютно разных принципа и инструмента.
Как то так.
Алан просто придумал и сказал одно
цитата из сообщения Алана:
I'm sorry that I long ago coined the term «objects» for this topic because it gets many people to focus on the lesser idea.
Нет, Алан именно неправильно выразился / «придумал неправильный термин».
а поняли и начали развивать другое.
Что сказал, то и начали развивать.
Суть и смысл статьи не в том чтобы...
Я понимаю, в чём суть статьи (и не спорю с этой сутью), но просто пытаюсь Вам сказать, что сейчас «обмен сообщениями» называется термином акторы, и что Алан «хотел придумать» именно их.
Я не против того что акторы имеют место быть и может быть соответствуют изначальному понятию ООП. Мне сложно об этом судить т.к. я не видел ни одной крупной и расширяемой системы которая построена на основе этих штуковин.
Но если будут примеры, то мне будет проще поверить в адекватность этой идеи.
Я не могу доказать обратное без личного опыта, но и без подтверждения с примерами этого утверждения не смогу воспринимать его всерьез. Возможно это так, а может быть и нет. Это все что я могу сказать по этому поводу :)
WhatsApp (Erlang)
Halo (Orleans)
Akka
А ещё какие-нибудь?.. (Возможно я просто пропустил..)
Wordpress, как таковой, создавался для домохозяек, в нём должна быть возможность сделать какое-либо действие в один клик (в частности, подключить какой-то модуль). Организовать такую систему взаимодействия между модулями проще всего на сообщениях.
Если бы WP был написан на другом принципе, то эта статья была бы именно про него.
И, как Вы сказали ранее,
Открываешь код и хочется рыдать. Но при этом если их включить то в целом система работает.
…
Пример привычного ООП:
В кругах биоинформатиков довольно популярен набор утилит picard tools. Достаточно успешный проект?
Кстати, не изучал подробно, но возможно Вы знаете, следуют ли веб-браузеры принципу ООП Алана?
…
Ну, про WhatsApp уже сказали…
Все что шло далее, наследовало именно это понятие.
Ну, правильно. C++ инкапсулировал ООП, а остальные уже наследовали, слегка полиморфя. :)
А как на счёт прототипов? :)
Это сложно. Реально сложно попытаться что-то представить выбросив нечто давно сидящее в голове.
Проблема не в том что ООП изменилось со времен C++. Проблема в том что ООП в C++ никогда не было. И то что мутировало в современное ООП — было чем то другим.
То что называлось как ООП — было не верно понятно изначально и в такой форме родилось и в такой форме развивалось.
Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием. И это то что сегодня понимается под ООП.
Но тот который когда то произнес это понятие и ввел его в обиход думал о абсолютно других вещах. Вот об этом статья.
И эти понятие не менее поразительны и полезны.
Представьте что кто то сказал слово «Хуркапука» и имел ввиду нечто похожее на мячик.
А кто то взял и сделал лампочку. И сказал что это Хуркапука. И далее все показали на нее пальцем и сказали что это Хуркапука. И Хуркапука развивалась так много лет и вот у нас уже супер современная Хуркапука. Которую кто то любит, а кто то нет. И когда показывают лампочку то все говорят «вот это Хуркапука».
Но суть в том что изначально то под это понятие ввели мячик. И мячик развивался все это время по своей линии эволюции. И он далеко не лампочка.
Вот об этом статья :)
И вот я пытаюсь сказать о том что Хуркапука изначально круглая и ей круто в ворота голы забивать и это имел ввиду автор этого понятия. А народ тут говорит что я дурак и Хуркапука это такая хрень которая светится и ворота ее бить глупо.
Вот так и живем ))
И кто тут дурак? Я как тот кто попытался воссоздать изначальное понятие и рассказать об этом и может быть плохо донес мысль. Или народ который не понял вообще о чем речь и пытается меня обвинить в глупости говоря что мячик мутировал в лампочку и это нормально?
Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием.
Почему вы в таком случае называете обмен сообщениями объектно-ориентированным программированием? Это можно назвать «сообщение-ориентированное программирование» или «коммуникативное программирование». Потому что там сообщениями обмениваются объекты? Ну так методы друг друга вызывают тоже объекты, а не классы.
Все программисты думают что C++ поддерживает ООП
Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП.
Вам говорят, что ООП это многозначное понятие. Вы же говорите, что никто не понимает, что такое ООП, что есть только одно значение, которое было изначально. Оба смысла этого термина произошли от слова «объект», но используются в немного разных контекстах. Не надо подменять одно другим, или говорить, что все, кто использует другое значение, дураки, которые ничего не понимают.
Проблема в том, что ООП — это способ программирования, а C++ — всего лишь универсальный язык программирования.
На С++ вполне можно писать ОО программы. Но их можно писать и на старом добром С, и на ассемблере.
А на С++ еще можно и функциональное программирование, только очень неудобно («шурупы гаечным ключом» :) ).
Вся суть ООП сводится к тому, что основой программы являются объекты, обладающие набором свойств и методов воздействия на них. А программа описывает взаимодействие между объектами.
Механизм получения свойств (прямое чтение, вызов метода, посылка сообщения и ожидание ответа) и исполнения метода (обычный вызов функции, посылка сообщения, инициация события в системе) — это уже всего лишь особенности реализации.
Все, что присутствует в «ООП языках» (классы, наследование, инкапсуляция, полиморфизм и т.п.), является всего лишь набором различных инструментов, облегчающим написание ОО программы, а не неотемлемой частью ООП.
Это холивар: Simula vs Smalltalk.
Все конечно прекрасно, но пара моментов зацепила.
Обмен посредством сообщений.
Чем это принципиально отличается от того, что объекты вызывают методы других объектов? Или сигналов\слотов Qt?
- Каждый компонент может быть отключен и заменен на лету.
Допустим, есть объект, который взаимодействует с другим объектом. Соединены они при помощи позднего связывания. Тут "на лету" второй объект отключают, а потом присоединяют другой. Такое легко реализовать в современных языках — на том же C++ это можно сделать через указатель на абстрактный класс родитель. Но ведь проблема в другом — необходимо обработать возможность отключения объекта (получаем NULL) в рантайме. И это уже задача разработчика объекта. Каким образом некое правильное понимание ООП решит эту проблему?
2. Это проблема C++ -вского взгляда на вещи. Как раз отличие функции-метода от сообщения.
Спасибо за разъяснение, действительно это так.
Отличается это тем, что мы не должны ничего знать об объекте, чтобы послать ему сообщение.
Я правильно понимаю, что хороший пример «как надо» это Objective-C в данном случае?
Только не очень понятно, что в этом хорошего. Сообщение послали, ошибки нет, что происходит — не понятно.
Только не очень понятно, что в этом хорошего. Сообщение послали, ошибки нет, что происходит — не понятно.
Ну почему "ошибки нет"? В "как надо" должны вернуть сообщение "не поняли ваше сообщение", а уж что вы с ним сделаете — дело ваше.
а уж что вы с ним сделаете — дело ваше.
Есть два варианта обработки ошибки в программе: тихо исправить и громко упасть. Можно считать, что в C++ второй случай реализован из коробки, и его не придётся писать самому.
Проблема (для тех, кто исповедует другую школу) в том, что в C++ надо приложить слишком много усилий, чтобы исправить.
Самая важная у Алана мысль другая (не могу найти точную цитату, кто помнит откуда — помогайте): она в том, что объект — это такой самостоятельный «виртуальный» компьютер с конкретным назначением. Тут он предвосхитил и DDD с его bounded context-ами, и микросервисы.
… и толку от этой мысли? Чем она отличается от "объект — это совокупность данных и поведения"?
Вы, к примеру, ко мне обращаетесь, говорите: давай, мол, накатим по 100 грамм! А я такой: спасибо, не пью. Это смоллток. А в парадигме C++ Вы говорите, что недопустимо существование такой Вселенной, в которой предлагают выпить непьющему, потому что это ошибка. Вот и разница.
Вы, к примеру, ко мне обращаетесь, говорите: давай, мол, накатим по 100 грамм! А я такой: спасибо, не пью. Это смоллток.
Не совсем. Не "спасибо, не пью", а "о чем вы, не понимаю вас".
недопустимо существование такой Вселенной, в которой предлагают выпить непьющему, потому что это ошибка
И таки для некоторых доменов такой сценарий более предпочтителен.
Насчет разницы между посылкой сообщения и вызовом метода вы, опять же, заблуждаетесь — она существует. Ее я объяснил ниже.
На нем вполне можно и «истинное ООП». Только работы и возможности ошибиться будет чутка больше, чем в «истинном ОО языке», в котором эту самую работу и возможность ошибиться мы просто перекладываем на разработчиков компилятора или интерпретатора этого языка.
А вы пробовали увидеть? :)
Практика — критерий истины. Обрыв либо есть, либо нет. Если он есть — так покажите его.
Кажется, Вы скатываетесь в языкосрач.
Я пытаюсь сказать, что «современное» понимание ООП проповедуется и в ВУЗах, и в книгах, и в языках. Ясно, что большинство считает именно это понимание правильным. Это понимание приводит к целому ряду проблем. Лозунг «ООП мертв» — яркое тому подтверждение. И если человек эти проблемы осознает, он может, увидев альтернативу, ее понять и оценить. Если же считать, что в мейнстриме все хорошо, то шансы сразу падают.
Лозунг "ООП мёртв" — нелеп, как нападки на "понимание ООП".
С пониманием ООП, конечно, есть проблемы. Но в целом, идея объекта, имеющего внутреннее состояние, и имеющего интерфейс взаимодействия — хороша и удобна. Каков характер интерфейса — сообщения или свойства с методами (впрочем, они взаимовыразимы) — вопрос не существенный.
внутреннее состояние + интерфейс взаимодействия
Всего-навсего более общий случай "объектов, обменивающихся сообщениями". Причём, не намного более общий.
паскалевский модуль вполне удовлетворяет этому определению
Так Вы, кажется жаловались, что "«современное» понимание ООП" — неправильное. Вот, извольте.
Чем модуль не объект? Скажем, в VB были классы, но не было наследования. А модуль практически не отличался от глобально объявленного экземпляра объекта.
Ключевые слова — «позднее связывания».
Если это ключевые слова, то название термина подкачало. Назовите парадигму, в которой "Ключевые слова — «позднее связывания»", адекватно ключевым словам. А парадигму, где ключевое слово "объект" — оставьте в покое.
Кстати, первое — это подмножество второго.
- Термин «object-oriented programming» придумал Alan Kay. Как автор он мог вложить в этот термин любой смысл. Он вложил следующий (о чем неоднократно разными способами разъяснял, и более того — реализовал, так что можно посмотреть и убедиться).
- Объекты в рамках ООП отличаются от любых других (даже одноименных) сущностей из других парадигм (или назовите как хотите) тем, что объекты взаимодействуют по средствам сообщений.
- Поскольку это их отличительная особенность, сообщения чем-то должны отличаться от общепринятого (до ООП) способа «общения» — вызова процедуры/функции.
- Отличие сообщения от вызова заключается в том, что во втором случае всегда управление передается в конкретный, заранее известный код, а объект при получении сообщения (именно в момент получения — это и есть позднее связывание) сам «решает», как именно прореагировать — какой код вызвать.
- Данная идея (ООП) именно в таком виде действительно очень неплохо работает (а должна еще лучше, ведь до сих пор полностью в абсолютно чистом виде так и не была реализована). Впрочем, это, конечно, спорный вопрос. Но вот то, что ее «современная версия» на самом деле рассыпается — это становится очевидным все большему количеству людей. Статьи с критикой ООП (а это всегда «современный ООП») появляются все чаще и далеко не всегда эта критика беспочвенна.
Сказанное не означает, что позднее связывание — это и есть ООП. Понятие существовало и было реализовано (например, в LISP) гораздо раньше. (Кстати, тот же Кэй очень любит LISP, и почему-то даже называет его чуть ли не объектным… впрочем, это надо уточнять, контекст и общую мысль.) ООП — это связка объект-сообщение. И именно связка: убери любое из этой пары — идея рассыпается. Почему это важно — отдельный и долгий разговор.
В дискуссиях на темы по типу «нам оно не надо — я щаслифф с двумя плюсами (кофием, диезами и т.д.)», «я так люблю тот ООП, который мне вдолбили, и ничего не хочу больше слушать» я участвовать не собираюсь. Почему — я уже объяснил.
Если же к изложенному будут вопросы/замечания по существу — разумеется, отвечу.
Объекты в рамках ООП отличаются от любых других (даже одноименных) сущностей из других парадигм (или назовите как хотите) тем, что объекты взаимодействуют по средствам сообщений.
И на основании чего вы делаете такой вывод?
Поскольку это их отличительная особенность, сообщения чем-то должны отличаться от общепринятого (до ООП) способа «общения» — вызова процедуры/функции.
Совершенно не обязательно. Например, "отличительная особенность" может быть в том, что общаются объекты, а не что-то другое.
Отличие сообщения от вызова заключается в том, что во втором случае всегда управление передается в конкретный, заранее известный код, а объект при получении сообщения (именно в момент получения — это и есть позднее связывание) сам «решает», как именно прореагировать — какой код вызвать.
То есть реализация "операции", в которой объект в момент "операции" решает, как прореагировать, является основанной на сообщениях, безотносительно того, как эта операция называется в ЯП?
И на основании чего вы делаете такой вывод?На основании слов Алана Кэя (книги, письма, интервью) и их реализации (Smalltalk).
Совершенно не обязательно. Например, «отличительная особенность» может быть в том, что общаются объекты, а не что-то другое.Вы не шутите?! Пункт первый: «объекты отличаются сообщениями». Пункт второй: «сообщения отличаются объектами». Я вас правильно понял?
То есть реализация «операции», в которой объект в момент «операции» решает, как прореагировать, является основанной на сообщениях, безотносительно того, как эта операция называется в ЯП?Я не понимаю, что вы хотите уточнить. На сообщениях основывается не реализация, а взаимодействие между объектами. Объект нужен для того, чтобы отвечать на сообщения. Все остальное — детали реализации.
На основании слов Алана Кэя (книги, письма, интервью) и их реализации (Smalltalk).
Можно привести конкретные слова Кэя с указанием источника? Желательно так, чтобы они друг другу не противоречили.
Пункт первый: «объекты отличаются сообщениями». Пункт второй: «сообщения отличаются объектами». Я вас правильно понял?
Нет, не правильно.
Я не понимаю, что вы хотите уточнить. На сообщениях основывается не реализация, а взаимодействие между объектами. Объект нужен для того, чтобы отвечать на сообщения.
Я хочу уточнить тот факт, что для определения того, является ли конкретный язык/реализация/парадигма объектно-ориентированными, нам важно не название того, как там сделана операция, а способ. Иными словами, не важно, называется ли "нечто" в конкретном ЯП сообщением или вызово важно, что оно (а) направлено к объекту и (б) поведение определяется в момент вызова. (Я просто не понимаю, как вы иначе будете определять, что есть вызов, а что есть сообщение)
Можно привести конкретные слова Кэя с указанием источника? Желательно так, чтобы они друг другу не противоречили.Можно.
Иными словами, не важно, называется ли «нечто» в конкретном ЯП сообщением или вызово важно, что оно (а) направлено к объекту и (б) поведение определяется в момент вызова.Примерно. Пункт (б) требует коррекции.
Термин «object-oriented programming» придумал Alan Kay. Как автор он мог вложить в этот термин любой смысл. Он вложил следующий (о чем неоднократно разными способами разъяснял, и более того — реализовал, так что можно посмотреть и убедиться).
Кстати, весьма любопытно. С Кэевским определением все совсем не так просто. Так на какое же именно определение (и основанное на каких источниках) опираетесь вы?
Ну то есть вы за определение считаете именно шесть пунктов из EHoS?
Как пример, можно взять пункт о классах. Положим (скорее всего, так и было, и тому есть косвенные свидетельства; но я не уверен, утверждать не буду — это не принципиально), изначально классы входили в определение ООП. Но затем появился Self — развивающий концепцию ООП, но при этом очевиднейшим образом остающийся объектным. Пункт про классы перекочевывает в «необязательные».
Мне — как еще один пример — кажется излишним пункт про наличие памяти у объектов. На мой взгляд, это некоторое дополнение, поясняющее концепцию. Вроде бы, на сегодняшний день не видно, как может быть иначе. Но это не повод сужать область определения без необходимости. Может быть (я фантазирую) что-то из ФП сможет таким образом попасть в разряд ООП (если получится идентифицировать объекты…). При этом, если каким-то чудесным образом появится концепция как делать объекты без этой самой внутренней памяти, и эта концепция будет идти в каких-то моментах вразрез с идеями ООП, то мне придется отказаться от этой гипотезы. А эту волшебную концепцию (или «парадигму» на ее основе) нужно будет называть иначе.
Так ООП определил автор.
Окей, это и запомним. Вот это определение:
- Everything is an object.
- Objects communicate by sending and receiving messages (in terms of objects).
- Objects have their own memory (in terms of objects).
- Every object is an instance of a class (which must be an object).
- The class holds the shared behavior for its instances (in the form of objects in a program list)
- To eval a program list, control is passed to the first object and the remainder is treated as its message.
Но изменение должно оставаться в рамках исходных идей (мы о них, кстати, еще даже не говорили).
А о них бесполезно говорить. Идеи сложно формализовать, нельзя дать объективное определение того, что в рамках, а что нет, и, что веселее всего, обращаясь к идеям, можно внезапно выяснить, что эти идеи были не про ООП.
Поэтому давайте оставаться в рамках определения.
Положим (скорее всего, так и было, и тому есть косвенные свидетельства; но я не уверен, утверждать не буду — это не принципиально), изначально классы входили в определение ООП.
Какое "положим", какие "косвенные свидетельства"? Пункты 4 и 5 выше явно говорят нам, что в определение-ООП-по-Кэю классы входят.
Но затем появился Self — развивающий концепцию ООП, но при этом очевиднейшим образом остающийся объектным. Пункт про классы перекочевывает в «необязательные».
И вот тут вы попадаете в логический парадокс. Если термин ООП придуман и определен Кэем, то язык, противоречащий этому определению, не может "очевиднейшим образом" быть объектным. Поэтому одно из двух: или определение Кэя некорректно (и тогда вся ваша риторика по "современный ООП" выдумана на пустом месте), или же нет ничего очевидного в том, что Self — ОО-язык.
Так вот, вернемся к определению. Поскольку это определение, то то, что под него попадает — ООП, то, что не попадает — не ООП. Давайте, для простоты, договоримся не учитывать 6 пункт, потому что это дизайн-ограничение для среды выполнения (и, будем честными, реализуется в любом современном языке с AST).
Из оставшихся пяти вопрос вызывает, очевидно, второй пункт: "objects communicate by sending and receiving messages". Что именно это означает? Какой тип коммуникации является отправкой/получением сообщений, а какой — нет? Можем ли мы использовать Smalltalk 80 как образец такой коммуникации?
И вот тут вы попадаете в логический парадокс.Никакого логического парадокса нет. В него пытаетесь завести вы:
А о них бесполезно говорить. Идеи сложно формализовать, нельзя дать объективное определениеС таким же успехом можно заявлять, что исходное определение — не определение. Математической точности нет (к сожалению или счастью). Но ООП родилось не просто так, а как решение (попытка решения) определенных проблем. И идеи, которые за ним стоят, — это подход к решению этих проблем.
Если чуть-чуть ограничить себя в попытках победить в споре любыми методами и поставить задачу понять, то можно найти время и прочитать в том же EHoS следующий абзац:
By this time most of Smalltalk's schemes had been sorted out into six main ideas that were in accord with the initial premises in designing the interpreter. The first three principles are what objects «are about»—how they are seen and used from «the outside.» These did not require any modification over the years. The last three—objects from the inside—were tinkered with in every version of Smalltalk (and in subsequent OOP designs).
Из оставшихся пяти вопрос вызывает, очевидно, второй пункт: «objects communicate by sending and receiving messages». Что именно это означает?Этот вопрос поставлен далее в том же абзаце. А ответ на него дан в следующем.
Можем ли мы использовать Smalltalk 80 как образец такой коммуникации?Smalltalk-80 — это продукт, который был создан в процессе и как результат практического воплощения обсуждаемых идей. Так что мы не только можем, мы должны использовать его в качестве источника. Я об этом уже неоднократно говорил. Более того, поскольку как вы изволили заметить «идеи сложно формализовать», именно их реализация должна стать главным критерием (с небольшой поправкой на несовершенство, присущее любому воплощению идеи в материальном мире). Но разбираться же в сути вопроса некогда — лучше попытаться поднять свою самооценку за счет софистики (в негативном смысле этого слова).
Поэтому одно из двух: или определение Кэя некорректно (и тогда вся ваша риторика по «современный ООП» выдумана на пустом месте), или же нет ничего очевидного в том, что Self — ОО-язык.Вы не хотите это слышать, но я повторю мысль: вся суть ООП заключена в связке объект-сообщение. Остальное — детали реализации. Я давал ссылку на подробное разъяснение Кэя по этому поводу, так что это не мои домыслы.
Self — является развитием (некоторые даже называют разновидностью) Smalltalk-а. Для людей, потрудившихся разобраться со Smalltalk-ом и хотя бы почитавших про Self, очевидно — что Self четко следует исходной конкцепции ООП и как раз развивает (а не перевирает и уродует) ее, пытаясь (весьма успешно) улучшить некоторые момент реализации.
можно найти время и прочитать в том же EHoS следующий абзац:
… из которого следует, что это определение — и есть идеи. Нет?
Так что мы не только можем, мы должны использовать его [Smalltalk-80] в качестве источника
Прекрасно. Разбирая реализацию сообщений в Smalltalk-80 можно выяснить следующее:
- сообщения определяются именем
- процесс отправки-получения сообщения синхронен
- процесс отправки-получения сообщения двухсторонний (т.е., "отправка сообщения" — это выражение, имеющее результат, и этот результат возвращается из вызванного кода)
- первичный выбор кода, вызываемого в ответ на сообщение, выполняется виртуальной машиной по имени сообщения (и адресату, конечно). Это происходит в момент отправки-получения, потому что раньше машина не обладает информацией, нужной для принятия решения.
- может быть объявлен код, который будет выполняться, если алгоритм выбора из предыдущего пункта не нашел код (метод
doesNotUnderstand)
Где я не прав/что важное я забыл?
вся суть ООП заключена в связке объект-сообщение. [...] Я давал ссылку на подробное разъяснение Кэя по этому поводу
Дайте, пожалуйста, эту ссылку еще раз, чтобы не получилось так, что мы с вами говорим о разных ссылках.
Там и про сообщения и про развитие заодно.
… из которого следует, что это определение — и есть идеи. Нет?Нет. Есть проблема. Есть подход к ее решению (то, что я назвал идеями). Про них — целая книга… и не только она. Есть реализация этих идей на «духовном» и «материальном» уровне: разработанная концепция ООП и Smalltalk.
Где я не прав/что важное я забыл?То, что сразу бросается в глаза:
сообщения определяются именемНе понимаю, что имеется ввиду. Сообщение — это объект(!), включающий в себя имя и набор параметров. Может быть два сообщения с одинаковыми именами, но с разными значениями параметров. Так что, скорее, нет.
первичный выбор кода, вызываемого в ответ на сообщение, выполняется виртуальной машиной по имени сообщения (и адресату, конечно).Вас интересуют нюансы реализации? Да, непосредственно передача сообщения объекту в Smalltalk-80 реализована в виртуалке — дань производительности и некоторым сложностям с реализацией. Но семантика (с точки зрения пользователя) проста: за обработку сообщения отвечает объект.
В Smalltalk-е есть еще целый ряд похожих отступлений от концепции по аналогичным мотивам. …А можно еще вспомнить, что уровнем ниже все это работает на процессоре и ни о каких объектах вообще речи нет.
В целом, зачем нужны все эти детали в нашем обсуждении — не ясно. Если только вы не продолжаете игры в софистику. И если ваш план состоит в том, чтобы «дискредитировать» мои слова, зафиксировав Smalltalk-овскую реализацию и объявив любую другую необъектной, то не стоит усилий — я на это уже ответил.
Если же есть настоящее желание понять, то гораздо важнее обсудить подход/идеи, приведшие к созданию ООП. Хотя там все еще менее однозначно и более спорно, чем с определением.
Alan Kay On Messaging
Я так и думал. Есть маленькая проблема: нигде в этом сообщении не сказано, что оно про ООП. Что, в общем, верно и для других поздних рассуждений Кэя — они про то, как он считает нужным проектировать системы, чтобы они были поддерживаемы и управляемы, но люди почему-то считают, что это продолжает относится к ООП.
[сообщения определяются именем]
Не понимаю, что имеется ввиду.
В виду имеется простая вещь: при выборе, какой кусок кода вызвать, система рассматривает только имя сообщения (и адресат), больше ничего.
Вас интересуют нюансы реализации?
Конечно. Мы же условились, что мы используем ее как образцовую.
Но семантика (с точки зрения пользователя) проста: за обработку сообщения отвечает объект.
За обработку — да. А за выбор, что обрабатывает — внезапно, не объект. Потому что, если в объекте нет соответствующих методов, он даже не получит управления.
В целом, зачем нужны все эти детали в нашем обсуждении — не ясно.
Чтобы создать определение того, что же такое "прием-передача сообщения".
Давайте, сравнения ради, посмотрим на "вызов метода" в каком-нибудь C#. Вот у нас есть obj.Write(smth). Тип obj на момент компиляции — IWriter, в рантайме этот объект получается динамической подгрузкой из другой сборки.
- сообщения определяются именем
Чек: в данном случае это Write. Свернуть все эти данные в один объект тоже несложно (и это регулярно делается в других контекстах).
- процесс отправки-получения сообщения синхронен
Чек.
- процесс отправки-получения сообщения двухсторонний (т.е., "отправка сообщения" — это выражение, имеющее результат, и этот результат возвращается из вызванного кода)
Чек (Write может возвращать число записанных байтов). void — это частный случай NullObject (хорошо видно в SOAP).
- первичный выбор кода, вызываемого в ответ на сообщение, выполняется виртуальной машиной по имени сообщения (и адресату, конечно). Это происходит в момент отправки-получения, потому что раньше машина не обладает информацией, нужной для принятия решения.
Чек: поскольку реальный тип obj неизвестен до момента выполнения, там будет инструкция callvirt, которая приведет к тому, что нужный метод будет найден в рантайме (по имени и дополнительной информации).
Остался один пункт:
- может быть объявлен код, который будет выполняться, если алгоритм выбора из предыдущего пункта не нашел код
Если мы хотим оставаться в рамках C#, то в этот момент нам понадобится, чтобы compile-time-тип obj был dynamic. После этого, если рантайм-имплементация будет поддерживать дополнительный интерфейс, это поведение тоже будет достигнуто (хвала DLR).
Если мы хотим поменьше прыгать, то в милом языке Boo есть замечательный интерфейс IQuackFoo, делающий все то же самое, но легче. Аналогично method_missing в Ruby, methodMissing в Groovy и так далее.
Итого, получается, что в C# (заодно и в Boo, да и вообще в CLI-языках) поведение методов эквивалентно обмену сообщениями в определении Кэя. Да, там есть и другие варианты поведения, но все они — это всего лишь оптимизация, основанная на том, что компилятор имеет больше информации, нежели виртуальная машина в Smalltalk, и может использовать ее для более раннего связывания.
Нет, не так?
Есть маленькая проблема: нигде в этом сообщении не сказано, что оно про ООП.Ну, да когда речь идет про OOPSLA, Smalltalk, Squeak в письме в группу того же Squeak — при чем здесь ООП?!
Мы условились использовать ее для иллюстрации идей, а не того, как должна быть реализована объектная система. Я на это ваше внимание уже обращал, даже вроде бы (лень перечитывать) неоднократно.Вас интересуют нюансы реализации?Конечно. Мы же условились, что мы используем ее как образцовую.
По поводу связывания по имени — не стоило стараться какими-то хитро-вывернутыми путями получать от меня подтверждение: даже если я это еще не писал здесь (вроде бы даже писал), все равно никакого секрета в этом нет. Другого способа пока как-то не изобрели, насколько я знаю.
За обработку — да. А за выбор, что обрабатывает — внезапно, не объект. Потому что, если в объекте нет соответствующих методов, он даже не получит управления.Объект не может отвечат за выбор «что обрабатывать» — что прислали, то и обрабатывает. И если нет соответствующих методов, то объект все равно получит сообщение — как аргумент в #doesNotUnderstand:.
Чтобы создать определение того, что же такое «прием-передача сообщения».Вам все еще недостаточно источников? Ну, посмотрите здесь. Там много всякого написано, из-за чего может разгореться ни один флейм, но про сообщения, вроде, адекватно.
Давайте, сравнения ради, посмотрим на «вызов метода» в каком-нибудь C#. <…>Зачем?! :D Вы затеяли весь этот некороткий обмен сообщениями ради того, чтобы поймать меня на противопоставлении «посылки сообщений» и «вызова метода»?! Вынужден разочаровать, я достаточно представляю, как реализованы «виртуальные методы» в C++ (5 лет разработки на нем), методы C# (всего пару лет), Java (даже не хочется считать) и т.д., чтобы не утверждать, что там нет посылки сообщений. Конечно есть, иначе сложно было бы называть их объектно-ориентированными. А вот называть посылку сообщения вызовом метода — некорректно. Когда это делают мои коллеги (иногда даже я сам) при обсуждении каких-нибудь повседневных программистких проблем, на это никто не обращает внимания. Но если так начинают высказываться участники дискуссии об ООП, это граничит с невежеством.
Потому что человек не понимает, чем ООП отличается от «остального». Разбиение системы на компоненты, объединение в компоненте кода с данными… что там еще? Все это было до. Не было наследования (хотя, как же! было, к примеру, в Simula-67…и это, заметьте, на тот момент почему-то не стало поводом для создания новой парадигмы), но классы (а следовательно, и наследование) не являются обязательным атрибутом объектной системы. Так что это тоже не является отличием. А что является?
Похоже, к данному моменту я таки исчерпал лимит терпения. Можете считать себя победившим в споре, если в этом состояла цель. На массу интересных вопросов мы так и не вышли, но я честно старался.
Ну, да когда речь идет про OOPSLA, Smalltalk, Squeak в письме в группу того же Squeak — при чем здесь ООП?!
При чем угодно или ни при чем вообще. Но скорее всего речь идет о дизайне языка, а не об ООП как о парадигме. Но, повторюсь, поскольку в оригинальном письме вся борода цитат вырезана, мы не знаем, на что отвечает Кэй.
Вам все еще недостаточно источников? Ну, посмотрите здесь
Угу. Вот только там столько разных вариантов, что понять, о каком именно говорит Кэй — нельзя. А между, скажем, синхронной и асинхронной передачей разница фундаментальная.
Зачем?
Чтобы найти отличия, если они есть.
Конечно есть [посылка сообщения в C++, C# и Java], иначе сложно было бы называть их объектно-ориентированными
Прекрасно, значит по этому пункту эти языки попадают под определение Кэя. Несложно увидеть, что, скажем, C# попадает и под остальные (кроме шестого, но про него я уже один раз написал). Так? Или есть возражения?
А что является?
Вот и мне интересно.
Я уже выразил свое разочарование данной беседой. Если есть что сказать по существу — говорите.
В C# далеко не все является объектом.
И что же не является объектом в C#? Иными словами, чему я не могу послать сообщение?
Ой ли?
Когда вы имеете дело с сообщением (например, внутри TryInvokeMember) вам ничего не мешает посылать сообщения сочетанию биндера и аргументов.
new Message(invokeMemberBinder, args)
Результат выражения — один объект. Ну и да, в языке, где любая коллекция и любой тупл — объект, любое сочетание объектов есть объект.
{
x= 101;
}
Код в {} является объектом?
А что там насчет указателей?
В те времена, когда я работал на C#, базовые типы, пока их не обернешь в объект, объектами не являлись? Что-то изменилось?
Console.WriteLine(5.CompareTo(3))
Всегда работало, кстати.
А что там насчет указателей?
А указатели — это небезопасный код, который является расширенными возможностями.
То есть, указатели — не объекты?
Взять необъектный базовый тип и создать над ним объект — не велика наука. Но это не делает исходное число объектом.
(Расскажите это Smalltalk с его реализацией SmallInteger)
С точки зрения пользователя, число имеет тип System.Int32, который унаследован от System.Object. В любом месте, где используется object, можно использовать число. По каким именно — поведенческим! — признакам вы отличаете "необъектный базовый" тип от всех остальных?
То есть, указатели — не объекты?
Указатели — это хак, который не входит в объектную парадигму C# (и CLI вообще).
int v = 101;
Какое сообщение я могу отправить v?
Любое, поддерживаемое типом System.Int32.
> int v = 101;
> Console.WriteLine(v.ToString("N"));
101,00Поразмыслив, я понял, что зря упираюсь. Допустим мне удасться найти какие-то моменты, не покрытые в виртуалке соответсвующим хуками. Или я смогу найти нестыковки в языке, допускающие использование не-объектов. Очевидно, все это не носит принципиального характера: архитектуру виртуалки можно пофиксить, в язык добавить еще пару тонн сахара и гордо заявить о «чистом объектном языке». От этого потягивает каким-то душком, но я готов заткнуть нос и согласиться. Что дальше?
Напомните, какие методы поддерживает null и покончим с этим.
Никакие, но это не значит, что ему нельзя послать сообщение.
Что дальше?
А дальше выясняется, что (как минимум некоторые; мы вот увидели на примере C#, но это не потому, что другие хуже, а потому, что я их плохо знаю) современные ОО-языки вполне удовлетворяют правилам Кэя. Возникает вопрос: а что же это за "современная версия ООП" "рассыпается"?
Никакие, но это не значит, что ему нельзя послать сообщение.Это как же?! Покажите, пожалуйста, пример посылки сообщения этому «объекту». И заодно (раз уж у нас ООП на классах) поясните, какого класса экземпляром он является.
Возникает вопрос: а что же это за «современная версия ООП» «рассыпается»?Что за современная версия — я уже не раз писал и здесь, и в комментах к других статьям по теме. Подозреваю, что с логично назревающим вопросом «как именно она рассыпается» такими темпами с вами мы будем разбираться еще полгода. Увольте.
Это как же?! Покажите, пожалуйста, пример посылки сообщения этому «объекту».
string q = null;
q.Substring(1);И заодно (раз уж у нас ООП на классах) поясните, какого класса экземпляром он является.
В моем примере — string.
Что за современная версия — я уже не раз писал и здесь
Ну тогда я думаю, вас не затруднит коротенько повторить.
Очень аргументировано, да. Впрочем, с "современным ООП" то же самое — я в этом посте не нашел ни одного данного вами объяснения ни о том, что это такое, ни о том, почему оно "рассыпается".
Плохо искали. Даже в этой ветке были отсылки. Только не я вводил это понятие.
Соответственно, если есть желание продолжать — вам и карты в руки. Ведь это же вы, если не ошибаюсь, говорили за индустрию, за развитие понятия ООП и т.п. (причем не раз и не только здесь)? С устаревшим мы, вроде как разобрались, верно? Самое время вам изложить продвинуто-современное.
Плохо искали. Даже в этой ветке были отсылки. Только не я вводил это понятие.
Вот именно, что не вводили — так что это очень напоминает straw man argument.
С устаревшим мы, вроде как разобрались, верно?
А я что-то говорил про устаревание?
Самое время вам изложить продвинуто-современное.
Внезапно (!) я считаю, что "продвинуто-современное" понятие ООП сводится к тому, что написано в википедии: объединение (семантически связанных) данных и поведения. Из этого весьма несложным образом вытекают инкапсуляция и полиморфизм. Все.
Вот именно, что не вводили — так что это очень напоминает straw man argument.Вводили другие, я указал на различие. Что-то вам где-то напоминает? Ну, ладно…
А я что-то говорил про устаревание?А как же? Не ваши слова про то, что было понятие, индустрия изменилась, понятие — тоже. Риторический вопрос: что стало с исходным понятием?
Внезапно (!) я считаю, что «продвинуто-современное» понятие ООП сводится к тому, что написано в википедии: объединение (семантически связанных) данных и поведения.То есть, абстрактный тип данных? Или в чем отличие?
Кстати, не совсем понятно, как это определение соотносится с теми 6-ю пунктами? Если про устаревание речи не было, то они должны быть эквивалентны, не так ли?
Из этого весьма несложным образом вытекают инкапсуляция и полиморфизм.Хотелось бы услышать, как из совокупления данных и поведения рождается для начала полиморфизм? Кстати, было бы неплохо уточнить, что это такое. И что такое инкапсуляция, если она «вытекает» из этого, а не является этим.
То есть, абстрактный тип данных? Или в чем отличие?
Зависит от того, как вы понимаете термин "поведение".
Кстати, не совсем понятно, как это определение соотносится с теми 6-ю пунктами?
Оно шире, чем те 6 пунктов.
Хотелось бы услышать, как из совокупления данных и поведения рождается для начала полиморфизм?
Полиморфизм — в данном случае — это возможность совершать одни и те же операции над разными объектами. Проистекает она как раз из того, что объект предоставляет операции наружу, и можно ими пользоваться вне зависимости от того, что внутри.
И что такое инкапсуляция, если она «вытекает» из этого, а не является этим.
Инкапсуляция — опять-таки, в данном контексте — это сокрытие информации о внутреннем устройстве объекта, заменяя ее внешним интерфейсом.
Оно шире, чем те 6 пунктов.Что именно добавлено? Или наоборот убрано? Вы ведь можете конкретизировать мысль, а то даже не ясно в каком смысле оно «шире»: там больше ограничений и, соответственно, меньшее количество систем подпадает под это определение? Или наоборот?
Полиморфизм — в данном случае — это возможность совершать одни и те же операции над разными объектами. Проистекает она как раз из того, что объект предоставляет операции наружу, и можно ими пользоваться вне зависимости от того, что внутриОперации над объектами? Что такое операции над объектами — не припомню, чтобы вы их упоминали…
И поясните процесс проистекания, а то я теряюсь в догадках. Вот создал я объект класса Integer, в котором есть операция умножения. А потом создал экземпляр класса String, где эта операция не объявлена. Теперь я могу второй объект умножать??
Инкапсуляция — опять-таки, в данном контексте — это сокрытие информации о внутреннем устройстве объекта, заменяя ее внешним интерфейсом.Поясните слово сокрытие? А то вот все говорят «сокрытие», а потом объявляют поля как public… И вот снова незнакомое слово — интерфейс. Что это? Меня терзают смутные сомнения: не надо ли добавить его в определение?
Зависит от того, как вы понимаете термин «поведение».То есть ваше понимание зависит от моего? Другими словами, своей позиции вы не имеете, а ваши предыдущие слова про согласие с современной трактовкой следует понимать как «я не знаю, но согласен с толпой», верно?
Вот тут есть рассуждение Уильяма Кука по поводу этих различий. Не буду врать, что я его уже прочитал и полностью понял, но хочу поделиться заранее.И это вроде как подтверждает мою догадку?
Что именно добавлено? Или наоборот убрано?
Убрано. Нет необходимости в классах, нет обязательных сообщений.
Операции над объектами? Что такое операции над объектами — не припомню, чтобы вы их упоминали…
Это то самое "поведение", которое было упомянуто изначально.
И поясните процесс проистекания, а то я теряюсь в догадках. Вот создал я объект класса Integer, в котором есть операция умножения. А потом создал экземпляр класса String, где эта операция не объявлена. Теперь я могу второй объект умножать??
Нет. Но если вы создали объект, описывающий целое число, и объявили на нем операцию умножения, а потом создали объект, описывающий дробное число, и объявили на нем операцию умножения, то третий объект, желающий сделать возведение в степень, может сделать это для обоих этих объектов.
Поясните слово сокрытие?
Трактуйте его дословно: сокрытие избыточной (нерелевантной) информации от потребителя.
А то вот все говорят «сокрытие», а потом объявляют поля как public…
Это проблема кривой реализации, от нее вы не денетесь никуда.
И вот снова незнакомое слово — интерфейс. Что это?
Правильнее было бы сказать "контракт" (в Майеровском смысле), совокупность договоренностей о поведении объекта.
Меня терзают смутные сомнения: не надо ли добавить его в определение?
Нет, не надо. Контракт всего лишь вырастает как дизайн-практика, он не является обязательным свойством объектно-ориентированного программирования (хотя, несомненно, любой объект обладает контрактом, другое дело, что если мы не формализуем это понятие, оно нам и не нужно).
То есть ваше понимание зависит от моего? Другими словами, своей позиции вы не имеете, а ваши предыдущие слова про согласие с современной трактовкой следует понимать как «я не знаю, но согласен с толпой», верно?
Нет, неверно. Я просто не настолько хорошо знаком с теорией ADT, чтобы аргументированно здесь отвечать.
И это вроде как подтверждает мою догадку?
Наоборот. Там написано следующее: "Objects and abstract data types are not the same thing, and neither one is a variation of the other." Мне пока не хватило усидчивости, чтобы проследить за всем рассуждением.
Убрано. Нет необходимости в классах, нет обязательных сообщений.Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
А сообщения мы убрали — зафиксировано.
Это то самое «поведение», которое было упомянуто изначально.Упомянуто — не значит определено. Что такое операция/поведение? Как этим пользоваться?
Трактуйте его дословно: сокрытие избыточной (нерелевантной) информации от потребителя.Я не понимаю. Кто является потребителем? Какая информация является для него избыточной (нерелевантной)? Кто это решает? Как осуществляется это самое сокрытие?
Это проблема кривой реализации, от нее вы не денетесь никуда.По слухам, в реализации акторной модели Erlang-а к данным объекта из других объектов на самом деле нет никакого доступа. Не уверен, что это так, но если да — ваша инкапсуляция ведь не об этом?
Правильнее было бы сказать «контракт» (в Майеровском смысле), совокупность договоренностей о поведении объекта.<…> оно нам и не нужноНу, хорошо — пусть контракт. Это понятие должно же войти в определение ООП, раз вы на него ссылаетесь? А если оно не нужно, почему вам пришлось его упоминать? Давайте тогда откатываться назад и еще раз: что такое инкапсуляция (без упоминаний интерфейсов/контрактов)?
«Objects and abstract data types are not the same thing, and neither one is a variation of the other.»Ну, а как же тут быть? Мы обсуждаем некий новый термин — ООП. Вы же не опровергаете необходимость его существования? Значит, должны понимать, что он добавляет к уже существующим? Отложим этот вопрос?
Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
Это, на самом деле, некие домыслы. Их можно "вычитать" из книжки, но напрямую это там не сказано.
Упомянуто — не значит определено. Что такое операция/поведение?
Операция/поведение — это, буквально, то, что понимается под этими словами. Что-то, что можно сделать с объектом (например, сохранить).
Как этим пользоваться?
Implementation defined. Где-то это методы, где-то это сообщения — это не принципиально.
Кто является потребителем?
Любой, кто пользуется объектом (находясь на том же уровне абстракции, конечно — поэтому среда выполнения не является потребителем).
Какая информация является для него избыточной (нерелевантной)?
Это определяется решаемой задачей.
Кто это решает?
Разработчик объекта.
Как осуществляется это самое сокрытие?
Implementation-defined.
По слухам, в реализации акторной модели Erlang-а к данным объекта из других объектов на самом деле нет никакого доступа.
Это не так. Если объект сам решит предоставить свои данные наружу, доступ к ним будет. Public field — это то же самое.
Это понятие должно же войти в определение ООП, раз вы на него ссылаетесь?
Нет, не должно.
А если оно не нужно, почему вам пришлось его упоминать?
Потому что разъяснения вполне могут опираться на понятия, существующие за пределами парадигмы.
Давайте тогда откатываться назад и еще раз: что такое инкапсуляция (без упоминаний интерфейсов/контрактов)?
Сокрытие избыточной информации.
Значит, должны понимать, что он добавляет к уже существующим?
Начнем с того, что спрашивать, что термин "(какое-то) программирование" добавляет к термину "(какой-то) тип" — достаточно нелепо, не так ли? Есть люди, которые считают, что объектно-ориентированное программирование можно называть программированием на ADT, есть люди, которые так не считают. Я отношусь ко вторым, потому что (а) я считаю, что ADT — термин из другого уровня абстракции и (б) я считаю, что понятие "поведения" в ADT отличается от понятия "поведение" в объектах; но, к сожалению, я не могу это отличие вербализовать и формализовать. Иными словами, мое мнение о том, что ADT не идентичны объектам интуитивно, и собственных аргументов в его пользу у меня нет — однако, я нашел статью, которая это мнение подтверждает (как, впрочем, и википедия).
Ну, куда уж прямее (и я уже указывал на это место): The first three principles are what objects «are about»—how they are seen and used from «the outside.» These did not require any modification over the years. The last three—objects from the inside—were tinkered with in every version of Smalltalk (and in subsequent OOP designs).Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).Это, на самом деле, некие домыслы. Их можно «вычитать» из книжки, но напрямую это там не сказано.
Неа. Там всего лишь сказано, что первые три принципа со временем менять не понадобилось, а с оставшимися тремя продолжали играть в каждой реализации.
The first three principles are what objects «are about»—how they are seen and used from «the outside.»
Нет, я не издеваюсь. Я же говорю — это фраза, в которой можно прочитать что угодно, было бы желание. Дословный перевод абзаца (чтобы был виден контекст):
К этому времени [~1972-1973] бОльшая часть схем Smalltalk была сведена к шести основным идеям, которые соответствовали основным посылкам в дизайне интерпретатора. Первые три принципа говорят, "что такое" объекты — как они воспринимаются и используются "снаружи". В последующие годы их менять не понадобилось. Последние три — объекты изнутри — подкручивались в каждой версии Smalltalk (и в последующих OOP-проектах).
Но самое важное, что это же не имеет значения: мы все равно перешли от Кэевского определения к "моему".
Первые три принципа говорят, «что такое» объектыИ как же вы «прочитаете» эту фразу?
Но самое важное, что это же не имеет значения: мы все равно перешли от Кэевского определения к «моему».Кто «мы» и что значит перешли? Перешли к обсуждению ваших попыток что-то сформулировать про ООП — да. Но от этого исходное определение не становится менее важным. Меня лично интересует соотношение идей, рожденных в 70-е, и «современное» их «развитие». Я вот никак не могу уловить, что же улучшилось.
И как же вы «прочитаете» эту фразу?
Дословно: в ней описывается, как объекты выглядят "снаружи", т.е., по воспринимаемому поведению.
Меня лично интересует соотношение идей, рожденных в 70-е, и «современное» их «развитие». Я вот никак не могу уловить, что же улучшилось.
А почему вы думаете, что развитие идеи — это обязательно ее улучшение? Это может быть уточнение, или обобщение, или создание методологии, или создание производных — и так до бесконечности.
Начнем с того, что спрашивать, что термин "(какое-то) программирование" добавляет к термину "(какой-то) тип" — достаточно нелепо, не так ли?Нелепо плодить синонимы. Если термин появился и был признан, значит он что-то добавил к тому набору терминов, которые были до него.
Но я так не понял, вы в состоянии дать «замкнутое» определение ООП? Такое, чтобы без отсылок к сущностям, которые не входят в определение, а определяются через третьи сущности, которые тоже не входят и т.д.? А то у вас получается «короткое определение», но куда ни ткни — они объясняются через какие-то новые понятия. Сформулируйте, пожалуйста, хотя бы на уровне тех 3+3 пунктов что же такое ООП, из которых будет понятно, чем оно отличается от не-ООП. А то по кругу ходить надоело уже.
Нелепо плодить синонимы.
Так это и не синонимы. Программирование (любое) не может быть синонимом типа (любого).
Но я так не понял, вы в состоянии дать «замкнутое» определение ООП? Такое, чтобы без отсылок к сущностям, которые не входят в определение, а определяются через третьи сущности, которые тоже не входят и т.д.?
Конечно, не в состоянии. И никто не в состоянии.
Сформулируйте, пожалуйста, хотя бы на уровне тех 3+3 пунктов что же такое ООП, из которых будет понятно, чем оно отличается от не-ООП. А то по кругу ходить надоело уже.
Я, вроде бы, уже сформулировал: объединение (семантически связанных) данных и поведения. В не-ООП (семантически связанные) данные и поведение находятся в разных сущностях; в ООП — в одной (эта сущность и называется объектом). В идеальной реализации объект устроен таким образом, что только он (=его разработчик) определяет, какие части его поведения и/или данных доступны его пользователям (другим объектам).
Так это и не синонимы. Программирование (любое) не может быть синонимом типа (любого).Если вы не в состоянии объяснить, чем термин A отличается от термина B, то эти термины — синонимы.
Возвращаясь к конкретике: в каком-нибудь до-объектном языке (ну, скажем, C) есть тип int; есть набор операций, которые вы можете выполнять над значениями этого типа. Чем это не объект по вашему определению?
Скорее всего, вы возразите, что тут данные и поведение находятся в разных сущностях. Я спрошу: в каких? И мы уйдем в долгий и нудный цикл софистики.
Но можно этого не делать, а вспомнить, что в том же «чистом»(необъектном) C (или таком же Pascal) можно создать модуль: сложить данные и процедуры вместе. Тут уже сомнение о их совместном расположении быть не может. Так что мы получили объект, соответствующий вашему определению. Нет?
Если вы не в состоянии объяснить, чем термин A отличается от термина B, то эти термины — синонимы.
Вам правда надо объяснять, чем тип отличается от программирования? Тип — это сущность, программирование — процесс.
Чем это не объект по вашему определению?
Вы сами ответили на этот вопрос.
Но можно этого не делать, а вспомнить, что в том же «чистом»(необъектном) C (или таком же Pascal) можно создать модуль: сложить данные и процедуры вместе. Тут уже сомнение о их совместном расположении быть не может. Так что мы получили объект, соответствующий вашему определению. Нет?
А это зависит от того, какие данные и какие процедуры мы сложили вместе. Предположим, нам надо (=у нас есть бизнес-задача) вести учет моих домашних финансов. У нас есть модуль "мои деньги", в котором определены процедуры "приход" (дата и сумма), "расход" (дата и сумма) и "баланс" (возвращает сумму). Если дизайн модуля таков, что все общение с ним происходит через эти процедуры, то да, мы — соласно моему определению — получили объект. Дальше, правда, у нас есть/могут быть проблемы. Например, не очень понятно, как, сохранив этот дизайн, получить учет раздельно моих финансов и семейных финансов. Или, скажем, не очень понятно — хотя вот тут это частично вызвано моим незнанием возможностей Паскаля/Си — насколько легко/сложно пользователю этого модуля обойти эти процедуры и начать напрямую оперировать данными объекта (в этот момент объект "лопнет").
То есть, абстрактный тип данных? Или в чем отличие?
Вот тут есть рассуждение Уильяма Кука по поводу этих различий. Не буду врать, что я его уже прочитал и полностью понял, но хочу поделиться заранее.
внутреннее состояние + интерфейс взаимодействия — это совсем не ООП. Это всего лишь характеристики единицы, с которой оперирует ООП, т.е. объекта.
То, что «паскалевский модуль вполне удовлетворяет», всего лишь означает, что паскалевский модуль может использоваться в качестве инструмента для описания поведения объекта, изменения его состояния и его реакций на внешний мир.
А ООП — это построение программы как описания взаимодействия таких объектов.
В отличие, например, от классического описания последовательности действий.
Все перечисленное — всего лишь инструменты для написания ОО программ. Инструменты не идеальные, но какие есть. И с их помощью вполне можно писать ОО программы.
Да, это не так удобно, как в некоторых других языках, больше возможностей для ошибок, но вполне возможно. В конце концов, ООП — всего лишь парадигма построения программы, а не конкретный набор инструментов. А инструменты можно и самому нарисовать.
И должен заметить, что идеального ОО языка просто не существует. У всех какие-то дополнительные заморочки, осложняющие построение модели мира из взаимодействующих объектов.
Так это и на существующих моделях можно реализовать.
Вот только он ведь всё равно не сможет отвечать пока отключен.
Или я что-то не так понял?
Когда передается сообщение, какой код будет выполнен — заранее неизвестно. Требуется «связать» сообщение с методом. За это отвечает объект, и конкретный код будет выполнен когда сообщение получит конкретный объект в конкретном состоянии. Поэтому тот же Кэй постоянно говорит о позднем связывании.
Когда «вызывается метод», вызывается конкретный код.
Кстати, нет. Позднее связывание на методах тоже встречается, причем больше, чем одного вида.
В мейнстримовых языках это дело хорошо законспирировано, что вводит многих в заблуждение. В Smaltlalk-е разница между сообщением и методом (оба, кстати, являются объектами и объектами разных классов) — максимально ясна и прозрачна.
Вы уверены, что ваше понимание — оно точно правильное, и другого быть не может? Потому как, опять-таки, вся индустрия давно под вызовом метода понимает именно то, что происходит сейчас, со всеми вариантами связывания.
Ну, расскажите свою версию, и мы убедимся, что она является частным случаем описанного процесса.
Мое понимание основывается на том, что изначально вкладывалось в термин object-oriented programming автором термина. То, что, как вы утверждаете от имени всей индустрии, «эволюционировало» (скорее, деградировало) в современное «понимание» этого термина, а) сложнее, б) является частным случаем исходного определения, в) привело к массе ошибочных выводов о «хорошем объектном дизайне» и в конечном итоге завело эту самую индустрию в очередной тупик с криками «ООП умерло! Нас обманули! Ай-да эволюционировать функциональное программирование!»
В мейнстримовых языках это дело хорошо законспирировано, что вводит многих в заблуждение.
Не замечал такого.
В Smaltlalk-е разница между сообщением и методом (оба, кстати, являются объектами и объектами разных классов) — максимально ясна и прозрачна.
А зачем плодить сущности? Всё ясно и прозрачно в мейнстримовых языках, не выдумывайте.
Сообщение же лишней сущностью не является, поскольку именно в ней заключен весь смысл понятия «объектно-ориентированное программирование». Что Алан Кэй и все еще пытается донести до «профессионалов» — спустя уже более 40 (±) лет с момента изобретения.
Если же это не так, и «вызов метода» является синонимом «передачи сообщения», то мы немедленно приходим к выводу, что «объектно-ориентированного программирования» не существует. Вызов метода уж точно аналогичен вызову процедуры, а значит все это просто-напросто «программирование на абстрактных типах данных» — незначительное усовершенствование процедурного стиля.
Исходное понятие ООП и современное понятие ООП — не одно и то же.
Выше я уже высказывался, что Алан создал не тот термин, от этого все беды.
- Точно воплатил, а не только высказал?
- Такая ли уж она была прекрасная, раз её реализовывать почти никто не захотел?
2. См. п.1 + Objective C + Ruby + еще несколько попыток натянуть новую идею на старый манекен. Да и кто вам мешает самостоятельно ее изучить, попробовать и решить для себя?
Да и кто вам мешает самостоятельно ее изучить, попробовать и решить для себя?
Отсутствие потребности. Я пишу на разных языках, от asm-а до js. И каждый раз приспосабливаюсь к языку. Это совсем не трудно, если не пренебрегать чтением спецификации. А абстрактный спор, что называть ООП, меня не настолько занимает, чтобы ради него осваивать ненужный мне язык.
Есть два подтипа ООП.
То за которое нам тут минусы понаставили называется «классно ориентированное». А то которое народу не понравилось называется «компонентно ориентированное».
В общем описали то что давно известно. Но то о чем 99% программистов не знают. И за это получили минуса ))
В той статье, которую вы привели типов ООП не два а три. Третий — прототипно ориентированное программирование, которое в javascript. Класс ориентированный подход и прототипно ориентированный подход это варианты реализации поддержки ООП в языке, а компонентный подход это подход к проектированию систем с использованием ООП.
Всё это действительно давно известно и об этом знают 99% программистов. Теперь вот знаете и вы :)
и да, я дописал апдейт к статье где указал что три.
КомпОП — это разновидность ООП. Еще точнее это и есть ООП в изначальной формулировке. То как это видел автор понятия.
КлассОП — это более популярная разновидность. Которая появилась через C++
Что такое КомпОП реально мало кто из программистов знает. Ну я штук 10 опросил. Ни один ничего внятного не сказал. Все про классы говорят. Ну и комменты в этой статье это явно доказывают. Всего 2 или 3 коммента в тему насчитал. Все остальное просто слюни и вода на тему «а мы думаем иначе».
Обратите внимание на то, что классовый и прототипный подход это реализации ООП. Оперирующие конкретными терминами которым соответствуют концепции в языке. Нельзя сделать класс в Ecma Script 5, потому, что там его нет.
Компонентный подход, с другой стороны, реализуется на том, что попадёт в руки. Например на С++.
Если вы считаете написанное в википедии источником истины, то так же обратите внимание, что в англоязычной википедии компонентный подход не является разновидностью ООП, а вот акторный подход, который вам так не понравился — является.
Ну и действительно, поправьте статью. Там как ничего не было про прототипное ООП, так ничего и нет.
— «NULL» (в Smalltalk-е его называют nil) является полноценным объектом, для которого можно определить требуемое поведение.
— Даже если требуемое поведение таки не определили, это не смертельно. В том же Smalltalk-е при обработке исключения не «разматывается» стек. Поэтому даже необработанное исключение не приводит к аварийному завершению программы. Получив окно с сообщением об ошибке, разработчик может открыть отладчик, найти причину ошибки, исправить ее и продолжить выполнение программы. В сети ходили видики, где подобным образом (не останавливая работу программу) отлаживают, например, веб-приложения и игру «Астероиды».
RESTful в его каноничной форме несколько противоречит другому:
«как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении»
С чтением еще ничего (структуру так или иначе знать надо). А вот запрос вида PATCH /user/ {email: «new@email.com»} вместо сообщения changeUserEmail — это уже завязка на внутренние свойства.
Вот всякие JSON-RPC/XML-RPC с методами, отражающими бизнес-действие — ровно оно.
Скажем RESTfull API JSON может быть написано на php, ruby или asp.net. Причем внутри он может быть написан на голых функциях без классов и наследования глупым джуниором с говнокодом и кучей ошибок. Но при этом если он отрабатывает все запросы ровно и без ошибок — значит все ок. Объект ведет себя правильно и ожидаемо — значит принцип ООП выполнен.
В плагинах WP тот же принцип. Их более 45 000 штук. Из них 80% написаны ужасно. Открываешь код и хочется рыдать. Но при этом если их включить то в целом система работает. Потому что выполнен базовый принцип ООП — продумана логика обмена сообщениями.
Это не защищает от ошибок на 100%. Если в логике допущены жесткие ошибки то система помрет как и любая другая. Но степень антихрупкости у таких систем сильно выше относительно тех в которых нет механики обмена сообщениями. И компоненты внутри могут быть ужасными, но если на межкомпонентном уровне они себя ведут адекватно, то система будет работать. Возможно в этом причина того что под WP так просто написать новый плагин.
Если говорить о С++ — то это «низкоуровневое ООП», или, если можно так сказать — ООП времени компиляции. Да, там вызовы методов вместо отправки сообщений и т.д., но без этого низкого уровня невозможен никакой высокий. Ведь процессору пофиг на ООП; процессор все что умеет — исполнять ассемблерные команды, и, так или иначе, только это и делает — но в потоке команд какие-то относятся непосредственно к решаемой задаче, а какие-то к обслуживанию интерпретатора скриптов, фреймворка и прочих высокоуровневых штук. Какой процент тех и других в среднестатистическом современном коде?
Нет, конечно есть например Objective C, в котором реализованы сообщения. Есть Qt с сигналами и слотами — тоже своеобразные сообщения. Да, там еще нельзя изымать объекты и вставлять их во время работы — но в общем это не так уж и сложно сделать. Главный вопрос — нужно ли это? И при построении архитектуры конкретного приложения как раз и определяется, на каком уровне достаточно старого доброго процедурного программирования, где нужно низкоуровневое ООП, а где — полноценное высокоуровневое, с полностью динамическими объектами и сообщениями.
Вероятно есть разные типы ООП. Метод классов как в C++ хорош для компиляций и высоких скоростей.
Метод обмена сообщениями хорош для систем с высоким уровнем сложности и необходимостью подключать и отключать компоненты налету. В крупных системах это часто нужная штука. Например у меня много опыта работы с магазинами, агрегаторами и системами управления бизнес-процессами. Всю систему не вырубить на долго. Но добавлять, изменять и отключать компоненты нужно очень часто, почти каждый день.
От куда вы взяли понятие о низком уровне ООП и высоком уровне ООП? Это кем то уже описано? Или личный опыт?
Есть Qt с сигналами и слотами — тоже своеобразные сообщения. Да, там еще нельзя изымать объекты и вставлять их во время работы — но в общем это не так уж и сложно сделать.
Connect/Disconnect в рантайме вполне себе работают из коробки.
Всякие COM-объекты тоже мыслились как чистое ООП в рантайме. Встраивание программ друг в друга, встраивание данных одной программы в данные другой и т.д.
Когда читал это абсолютно честно думал, что это про Windows с их API построеных на событиях и хуках…
Вот только в отличие от Windows в том же WP зачастую обмен сообщениями сделан глубже. Хотя могу ошибаться. Суть в том что один компонент WP может подменить собой часть другого компонента, какой то мелкий кусок или почти целиком. Например один компонент фомирует страницу по одному шаблону, а мне это не нравиться и я могу написать компонент, который перехватит сообщение и изменит его так что поменят как шаблон вывода, так и состав данных по своему усмотрению. Тем самым достигается возможность глубоких изменений системы на любом этапе жизни.
При этом зачастую если в итоге нужда в такой логике отпала, то мы отключаем компонент и возвращается оригинальная механика которая была до включения.
Windows приложения могут чуть чуть перекрашивать друг друга, но вот они не могут вмешиваться в ход работы друг друга достаточно легко. Либо я могу ошибаться и сейчас такая возможность уже есть.
В IT — объект это в первую очередь данные. Потому что все что есть в IT — это обработка данных.
И в IT данные не могут быть абстрактными — они состоят из конкретных битов/байтов и должны храниться в каком-то формате, и чтобы с этими данными работать, этот формат должен уметь разбирать некий код.
Из этого идет и вывод что такое ООП для ИТ — «Это когда мы берем некие данные, и создаем объект, в котором они хранятся. И внутри этого объекта храним также и методы, которые позволяют с этими данными манипулировать. И только эти методы должны точно знать формат данных.»
Всякие геттеры/сеттеры и вообще принцип, по которому обращаясь к данными внутри объекта мы лезем не в само поле с этими данными, а к методу, которые с ними оперирует — вот этот принцип нам позволяет ВЕСЬ код, который имеет четкое представление о том, в каком виде данные хранятся в объекте, содержать внутри этого же объекта, и назвать его методами.
Этот принцип позволил ООП парадигме удачно наложиться на то, что для создания крупного проекта, который не влазит в голову одного программиста, или влазит но очень долго, — разделить проект на достаточно независимые кусочки-объекты, которые можно раздеребанить на команду программистов, нарисовав UML схему. И в принципе все завертится.
Это касается и поддержки — достаточно не создавать суперклассы, чтобы можно было локализировать проблему в конкретном классе объекта, и не бегать по всему проекту в поисках, где что еще нужно поменять, и один человек сможет в этом классе разобраться за разумное время.
От ООП бОльшего как-бы и не ожидалось.
Функция конвертации данных из одного формата в другой к какому объекту должна относиться?
Или вам вдруг нужно хранить те же данные в разном виде в одном и том же объекте?
Одна функция выдает данные своего объекта
В каком формате?
В совместимом, очевидно :)
Формат данных — это поля, которые хранятся внутри объекта.
Если вам нужно получить эти данные — пишете метод внутри объекта, который вам их выдаст в нужном формате.
Нужны разные — пишете разные методы. И любой внешний объект может запросить данные через геттеры. Но то, как данные хранятся — знают только методы внутри объекта. Поэтому менять их внутренний формат (модернизировать, масштабировать) — несложно. Поменял поля, и подправил методы внутри этого же объекта. А то, что они возвращают наружу — остается как было, совместимость не теряется.
Что же вы хотите сделать — я пока не понимаю.
Есть 100500 различных форматов: DOM0, DOM1, DOM2, JSON, ProtoBuf, Tree…
Вам нужно произвольно конвертировать их друг в друга.
А теперь нужно добавить ещё один формат, например, YAML-OM, чтобы можно было конвертировать и в него и из него.
Через какой промежуточный формат вы предлагаете реализовать конвертер, из DOM0 в YAML-OM?
Демагогию разводить не надо. Если формат данных — это способ их сериализации (именно это Вы и перечислили), то они хранятся в строке либо массиве байтов. Т.е. элементарном типе. Это не объект. Повторяю ещё раз для маргиналов: в объектных языках для преобразования формата таких данных нужно либо использовать методы объекта-библиотеки, который сам данные не хранит, либо оборачивать элементарный тип в объект, и реализовывать преобразование формата уже в его методах.
Я перечислил объектные модели.
Как бы не так. DOM0, DOM1, DOM2 — это структура, состоящая из объектов. JSON — это формат сериализованных данных. ProtoBuf — двоичный формат данных.
Оба варианта уже рассмотрены выше.
Ок, DOM0, DOM1, DOM2, JSON-OM, ProtoBuf-OM, Tree-OM. Легче стало?
Да. Этот вариант я рассматривал первым. Сериализация, потом десериализация.
Сериализация во что?
В любой строковый или бинарный формат. XML, JSON, ProtoBuf, etc.
Ок, мы сериализовали DOM0 в XML. И что дальше? Как нам получить JSON?
А почему сразу не сериализовать DOM0 в JSON?
Функция конвертации данных из одного формата в другой к какому объекту должна относиться?
Рекурсия, однако :-)
И где же она?
Вам реально не очевиден ответ? Всё же уже разжевали, насколько только возможно.
DOM0 — объект. JSON — строка. Так к какому объекту относится метод сериализации?
JSON — объектная модель прежде всего, а потом уже способ её сериализации.
Вы определитесь с терминами. Что у Вас объект, а что у Вас строка? Выше Вы предложили другой термин, а теперь обратно? Демагогия, батенька.
Все варианты ответа на Ваш вопрос я уже назвал выше. Для любого мыслимого случая подойдёт один из названных вариантов. Не прикидывайтесь, что не врубаетесь.
Ок, DOM0, DOM1, DOM2, JSON-OM, ProtoBuf-OM, Tree-OM. Легче стало?
И снова рекурсия :-)
Ох… Ну где же рекурсия-то? В принятой терминологии JSON не тождественен JSON-OM.
DOM0 сериализуется в JSON, или в XML, или любой другой удобный формат. А он в свою очередь десериализуется в JSON-OM. К чему относятся функции — смотри выше.
Каким образом вы XML десериализуете в JSON?
Вы сами-то поняли что написали? Или это Вы опять уклоняетесь от введённой Вами же терминологии, не иначе с софистическими целями?
Каким образом вы XML десериализуете в JSON-OM?
Таким образом, которым Вам это нужно. Поскольку JSON-OM послабее, чем DOM, придётся ввести какие-то дополнительные соглашения. Какие — это дело разработчика. Вы же хотели преобразовать DOM0 в JSON-OM? Вероятно, Вы уже знаете, какие именно соглашения пригодны для Вашего случая, иначе бы не ставили вопрос о том, где размещать функцию.
Это должны быть две функции: метод исходного объекта, возвращающий сериализованные данные и конструктор нового объекта, десериализующий данные и использующий их для инициализации.
А в чём вообще трудность?
У вас есть JSON и XML. Во что вы предлагаете "сериализовать" JSON, чтобы конструктор XML смог это десериализовать?
а JSON это не тип данных, это формат упаковки данных для передачи куда-либо, а не хранения.
int, char, double — не типа данных, а формат упаковки битов.
Ну или покажите ссылку на rfc или IEEE, который подтверждает, что char, int, double это именно формат упаковки битов, а никак не типы данных, чтобы мы поняли что вы говорите про общепринятое толкование.
Тип, это вообще может быть «какой-то мутный типочек»?
А «данные» могут быть «ситуации»?
Если мы обсуждаем тип данных на хабре, в контексте ООП, давайте обсуждать хотя бы «типы данных в программировании», а не в физике или философии.
P.S. Любой спор легко разрешается, если люди пытаются понять друг друга, а не ловят за слово и занимаются софистикой.
Ответил выше.
… если уж совсем традиционно делать, то у вас есть конвертер "формат-объект". Т.е., объектное представление в памяти живет само по себе, и может быть [де]сериализовано в/из любого формата. Конвертеры живут вне объекта (чтобы не нарушать SRP) и традиционно называются [де]сериализатор или форматтер.
Давайте посмотрим правде в глаза — WP появился в нужное время в нужном месте и дал пользователям то, чего им не хватало, а именно возможность самостоятельно и быстро поднять нечто тривиальное. Типичный сайт на WP — бложек ценных мыслей и заметок (обычно в количестве двух или трех и 0-1 комментарий к ним. При этом, «модульность», расписанная вами в статье, как правило, ограничивалась идущим в комплекте спам-фильтром и прикручиванием какой-нибудь аналитики. Все. Это 99.99% применимости WP в реале.
Теперь, при чем тут ООП — вообще не понятно. Даже если WP был бы написан у ужасном функциональном стиле на каком-нибудь бг-мерзком ПХП, он все равно бы завоевал ту же самую популярность, ибо сила его именно в подаренных возможностях, которые он предоставил в нужное время огромной армии людей (каюсь, сам с ним баловался, а кто из нас не грешил с WP?).
Начиная хотя-бы с того, что очень маленький процент текущих программистов реально знает C++ на уровне достаточном для практического применения. В мире сейчас куда больше Java/C#/JS/PHP/итп программистов, которые про C++ слышали только разные страшилки, а сами C++ когда не писали со времен института.
Второй факт — C++ как-бы на месте не стоит, и актуальная тема должна была-бы называться что-то вроде «Все программисты думают что C++ поддерживает ФП, кроме авторов ФП» (впрочем тут проблема в том, что «авторов ФП» многих уже нет в живых). Конечно ФП возможностей в С++ реализована так-же далеко от идеала, но некоторфе ФП мезанизмы в нем есть.
В конечном счете — язык ориентированный на практическое применение не обязан сторого реализовывать ту или иную парадигму программирования. Язык должен просто выполнять возложенную на него задачу, и в своей области применения C++ с этим справляется лучше всех. Если требования применимости на практике требует отказаться от того или иного принципа — то глупо будет, в ушебр производительности и применимости, слепо следовать ООП принципам. В конечном счете — для «академической чистоты» есть свои языки. И для других практических областей — есть более подходящие языки. Никто не будет сейчас писать на C++ то, что можно сделать на C#/Java.
Но вот беда, я докопался до мыслей автора и теперь понимаю ООП иначе.
В 2011 году я добрался до предела сложности очередной большой и сложной системы. Она просто начала умирать под гнетом функционала и утопать в постоянно меняющихся требованиях. А затраты на ее обслуживание подскочили до небес. Использовал разные платформы, но всегда очень быстро упирался в предел гибкости. В какой то момент система становится на столько хрупкой что уже с трудом поддается изменениям.
И тогда абсолютно случайно наткнулся на WordPress. И обнаружил что там есть возможность играть компонентами. Добавлять их, отключать, менять их логику не трогая внутренности. И я долго не мог понять как эта способность системы называется. И нашел не так много систем с похожим поведением и механикой взаимодействия компонентов (Drupal, Backbone.js и т. д.). И эта особенность помогла преодолеть предел гибкости и позволила создать очень большую и эффективную систему управления относительно крупной федеральной компанией. Аналогов такой системы на рынке не просто найти.
И не так давно все встало по своим местам когда я наткнулся на цитаты Алена Кея. Оказалось что он тоже искал такие решения и исследовал эту специфику систем. И назвал это свойство ООП. Вот только история с C++ и дальнейшим ходом развития событий привела к тому что понятие ООП мутировало и сегодня понимается не так как задумал автор.
Статья лишь об этом. О том что у ООП есть две стороны: та что популярна и та что была задумана изначально. При этом мне лично и для моих задач более полезной и интересной оказалась та что первоначальная.
И об этом статья. Я не против того как ООП понимают большинство. Более того — я даже сам так программирую. Но хотел лишь сказать что есть и другая сторона — другое понимание этого понятия. То как это задумал автор этого понятия изначально.
Ну а то что большинство программистов оказались не способны это понять — это в общем то не особо удивило :)
А вы прямо залезли к людям в голову и убедились, что они не способны понять.
> То как это задумал автор этого понятия изначально.
Много людей тешат себя мыслью, что понимают что то лучше других. Это дает им ощущение уникальности множит ЧСВ.
По факту, если вы не видели сложных масштабируемых систем на C++-подобных языках, это не значит что их нет в природе. Просто вам не повезло. Проект на котором я сейчас работаю состоит из более чем 10 тысяч файлов исходного кода, содержит огромное, просто немыслимое, количество различной функциональности, много чего можно динамически подключить или отключить, и при этом все работает весьма неплохо, никаких проблем с поддержкой этого кода и давлением новой функциональности — не имеем. Написано правда в основном на C#, но ничего такого, что нельзя сделать на C++ там нет (разве что C# events нужно будет реализовать вручную).
Так что все возможно, главное нормальная архитектура
Как только создаются события (хуки, каналы сообщений) и компоненты достаточно гибко начинают обмениваться между собой этими сообщениями, то вот тут мы уже подходим к ООП в изначальном понятии или «ООП как задумывалось».
А пока у нас классы с инкапсуляцией и наследованием то это «ООП как получилось».
И если система эффективна, то она растет, развивается и становится популярной.
А если система хрупка и сложна, то она редка и значит что ее рассматривать не особо интересно. Гораздо интересней рассматривать проблему на примере эффективных и популярных механизмов, доказавших свою адекватность и полезность обществу.
А таковыми являются WP, Drupal, Backbone.js и т д. Только по этой причине я их привел в пример.
А в том как ООП было понято авторами C++ и пущено в массы этому моменту не уделено внимание. Все думают только о методах и свойствах класса с наследованием и инкапсуляцией.
В целом это также попадает в область ООП но является пылинкой от того что имел ввиду автор изначально.
Когда система начинает собираться из множества компонентов которые легко включать и отключать и которые могут менять поведение друг друга и всей системы в целом посредством обмена сообщениями — вот тогда система приближается к изначальному значению понятия ООП.
Так ок?
А можно, кстати, цитату из Кэя, где он говорит, что "легко включать и отключать" — это свойство ООП? Только именно из Кэя, с указанием контекста.
Вы видимо опять смогли залезть в головы людям…
Нет, не думают, у вас страенное представление о людях
И обнаружил что там есть возможность играть компонентами. Добавлять их, отключать, менять их логику не трогая внутренности. И я долго не мог понять как эта способность системы называется.
Настраиваемость. Внезапно, да?
Вот только он не обладает способностью к созданию больших и сложных систем посредством объектов (компонентов) которые можно легко менять, добавлять, дописывать и удалять и которые обмениваются между собой сообщениями.
Но это вообще не внезапно, нет. Ты очень умный.
И тем не менее это свойство системы называется именно настраиваемостью, и никакого отношения к ООП не имеет.
А про "больше и сложные системы блаблабла с обменом сообщениями" нам долго и упорно рассказывали в SOA, кстати. Там вообще все было строго по перечисленными вам Кэевским пунктам. Значит ли это, что SOA — до сих пор живущая в Кровавом Энтырпрайзе — это высшее воплощение ООП?
главное понять что есть две версии понятия ООП далекие друг от друга:
1. ООП где объекты это компоненты больших систем которые обмениваются сообщениями и то что имел ввиду Ален Кей
2. ООП где объекты это классы с свойствами и методами которые придумали авторы C++, назвали это ООП и пустили развитие понятия по параллельному пути эволюции далекому от того что имел ввиду автор
И тебе ближе версия №2. А мне ближе версия №1. И кто из нас прав?
Вот только в отличие от тебя я допускаю обе версии. А ты уперся в версию 2 и пытаешься доказать ее правильность.
… но нет. Я вообще считаю, что между этими "версиями" нет отличия, потому что сообщения конвертируются в методы и обратно, свойства — это те же методы, а данные — это неизбежное внутреннее состояние объекта.
При этом, что характерно, "что придумал Кэй" мне интересно исключительно с исторической точки зрения, потому что на современнный дизайн систем оно не влияет. Потому что сейчас, когда говорят о сообщениях, говорят именно "сообщения" (вместе с шинами и message passing), когда кому-то нужны сервисы — говорят о сервисах, а когда говорят ООП — имеют в виду объединение данных и поведения (обратите внимание, что это не противоречит определению Кэя). Таково современное терминологическое поле, и спорить с ним бессмысленно.
Ага, и трех китов впридачу. Помню, зашел разговор на тему кто такие растаманы. Ну я только начал про миграцию африканцев на ямайку и растафарианство в историческом контексте, как меня прервали кратким и емким «растаманы — это те, кто курит траву!» )) Автор молодец, хотя под платформой он конечно же описал Эрланг. Автор ООП еще больший молодец, несмотря на «невлияние на современный дизайн систем» (С), он и сейчас без дела не сидит, и если у него с соавторами хорошо выйдет, то потом море потребляторов будут этим пользоваться.
У этой системы компоненты обмениваются сообщениями друг с другом и таким образом позволяют менять поведение друг друга.
Система изначально содержит в себе каналы сообщений.
Я вот полез в доки на WordPress, и ничего такого там не нашел. Кто-нибудь может показать пример, о чем идет речь?
— для некоторых языков (тот же PHP, JS) это просто некий архитектурный синтаксический сахар. Возможность.
— для некоторых языков (С++?) это техническая возможность «обойти» статическую типизацию. Привет приведению типов!
У первой группы нет проблемы вызвать любой метод любого обьекта, у второй группы нет выбора. В итоге получается что бывает разный ООП, для разных целей и растет он из разных причин.
Судя по всему Ален Кей не называл ООП ни первое ни второй. Софистика…
Честно говоря, не понимаю какое отношение приведение типов имеет к ООП.
Что для большинства строго-типизированных языков — основа функционирования различных контейнеров и половины программных интерфейсов.
В том числе потому что эти «программные интерфейсы» на вход получают не реализации неких интерфейсов, а именно наследников базовых классов.
Этот момент сильно зависит от конкретного ЯП, зашит в стиль использования конкретного ЯП. Это норма, фактически словом ООП различные ЯП, архитектуры, школы и подходы и «продают» разные понятия. Насколько я понял — lair в начале этого топика примерно об этом и говорил.
И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что часто имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.
Действительно упс. В википедии не про то, что у вас в статье, а COM и CORBA. И вообще про подход к проектированию систем без использования наследования, дабы избежать проблемы хрупкого класса. Реализуется это всё на том же С++ и на той же Джаве без проблем.
А то что WP соответствует принципам архитектуры компонентов которые обмениваются через сообщения и соответствуют всем принципам ООП которые описал автор — да пофиг.
Не "пофиг", а "не доказано".
Допустим этому принципу соответствует и CORBA и WP. CORBA это С++. В котором классовый подход. То есть противопоставлять классовый подход и компонентный подход неправильно. Компонентный подход реализуется с помощью классового.
В WordPress механика обмена сообщениями между компонентами (плагинами) реализована посредством хуков. Хуки представляют из себя фильтры и реализованные на их базе экшины. И эта механика основана на функциях. Сам же компонент я могу писать через классы или через функции. Это зависит от моих задач и желаний. Если я пишу что-то простое то пишу функциями. Если что то сложное то использую классы. В первом случае можно сказать что компонентная структура работает целиком на функциях, во втором случае на классах. Это не зависит от понятия компоненто ориентированной разработки, а лишь от моего стиля написания кода.
Потому можно сказать что утверждение «Компонентный подход реализуется с помощью классового» где то может быть правдой, а где то бредом.
Но есть мнение что компонентный подход это следующий этап развития класс-ориентированного программирования или ООП как это чаще понимается. Но если включить мозг и изучить первоисточники, забив на школьные учебники то станет ясно что компонентное программирование это не следующий этап развития, а это вообще корень ООП в изначальном понимании которое было просто извращено программистами по ходу работы.
Оказывается все что я тут описал уже общеизвестно и даже есть в википедии [...] И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование
Нет там такого. Вот что написано про компоненто-ориентированное программирование:
Компонентное программирование — следующий этап развития ООП
[...]
Компонентно-ориентированное программирование — это своеобразная «надстройка» над ООП, набор правил и ограничений, направленных на построение крупных развивающихся программных систем с большим временем жизни.
А термина "классно-ориентированное" там нет, есть "класс-ориентированное", и оно противопоставляется прототипному (что достаточно логично).
Впрочем, как вам уже сказали, в английской википедии традиционно написано лучше:
Object-oriented programming that uses classes is sometimes called class-based programming, while prototype-based programming does not typically use classes
[...]
Programming paradigms
[...]
- Object-oriented
- Actor-based
- Class-based
- Concurrent
- Prototype-based
И, наконец, про компоненты:
Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.
[...]
Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. [...] Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated components
Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.
[...]
Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. [...] Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated components
Это хорошее утверждение. Им можно пользоваться в быту. Я с ним согласен.
Единственное что мне в нем не нравиться и что в быту я не говорю в слух, это то что CBD изначально имело имя OOP. Если брать первоисточник и мысль автора. Потом программисты взяли OOP превратили в Class-based, сказали что хай так будет. Просто я за историческую справедливость. И чтобы те кто хают ООП понимали что они хают не отличную идею, а то что из нее вышло благодаря извращению истории.
И конечно же в быту говоря ООП я всегда говорю про class-based, просто потому что бесполезно сопротивляться общепринятым идеям.
Но в уме я всегда понимаю что изначально ООП было хорошей идеей. А идиотизм с class-based возник лишь в ходе истории и слабых умов программистов. Одни умники извратили идею, а другие теперь ее хаят. Так и живем.
Если брать первоисточник и мысль автора.
Вот возьмите первоисточник и процитируйте ту мысль автора, согласно которой component-based development изначально называлось object-oriented programming.
Потом программисты взяли OOP превратили в Class-based [...] А идиотизм с class-based возник лишь в ходе истории и слабых умов программистов.
Вас не смущает, что в первом определении ООП, которое можно найти у Кэя, есть классы?
Если проблемы с этим то могу специально для тебя тут повторить 3-4 цитаты которые об этом говорят.
При этом я не заметил или не нашел цитат где Ален Кей говорит о том что в его идеи ООП должны быть классы. Есть ссылка?
Я взял и процитировал. Оформил в статью. Мы прямо сейчас ее комментируем.
Ни в одной приведенной цитате нет слова "компонент".
Если проблемы с этим то могу специально для тебя тут повторить 3-4 цитаты которые об этом говорят.
Будьте добры.
При этом я не заметил или не нашел цитат где Ален Кей говорит о том что в его идеи ООП должны быть классы. Есть ссылка?
Есть, конечно:
- Everything is an object
- Objects communicate by sending and receiving messages (in terms of objects)
- Objects have their own memory (in terms of objects)
- Every object is an instance of a class (which must be an object)
- The class holds the shared behavior for its instances (in the form of objects in a program list)
- To eval a program list, control is passed to the first object and the remainder is treated as its message
Пункты 4 и 5.
(что характерно, этот список уже появлялся в комментариях, и да, это самое близкое к формальному Кэевскому определению ООП, что можно найти в верифицируемых источниках)
Давай предположим что твои ссылки на цитаты верны и мои.
И из этой предпосылки попробуй ответить на вопросы, которые мне не под силу:
1.
Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями
Объект это компьютер в сети, которые обменивается сообщением с другим компьютером в сети. Это следует из определения. Причем тут класс?
Я могу объяснить причем тут класс, только уйдя от значения класса в контексте написания кода. У слова класс есть и другие значения.
При этом с позиции CBD это понятие легко объясняется.
2.
Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
Вот как ты добавишь или удалишь класс (в понятии class-based) в большой написанно системе за долю секунды? Тебе как минимум надо будет написать методы расширения этого класса или учесть исключения если ты что то удаляешь? И как ты заставишь классы обмениваться сообщениями?
Упс. А ты заметил в этой цитате слово «компонент»? Или я один его вижу?
Опять же если брать во внимание CBD и в качестве примера WP, то там плагины можно реально включать и отключать за долю секунды, меняя логику обмена сообщениями и поведение системы. Скажем было сообщение о списках главного меню в приложении, мы добавили плагин который добавляет новый раздел, он перехватывает сообщение и добавляет в него новый пункт. На лету. За доли секунды. Модуль сломался, мы просто отключили плагин снова за долю секунды и сообщение перестало перехватываться. Одно сообщение может перехватываться 10 модулями и каждый волен дописать в него свою часть. При этом компонент который изначально владеет этим сообщением вообще не в курсе кто там завтра захочет это сообщение поймать и поиграть с ним. Таким образом мы строили систему из 200 различных модулей которая управляла бизнес процессами в компании на 3000 сотрудников. Оооочень большая и сложная система; Модули включали и отключали за доли секунды. Вся система работала именно так как описывал Ален Кей. При этом где то код был написан как class-based, а где то просто функциями, а где то и прототипы были на JS. Там дофига чего было. Но в основе всего был поставлен CBD-принцип или ООП в понятиях Алена Кея.
Объект это компьютер в сети, которые обменивается сообщением с другим компьютером в сети. Это следует из определения.
Из какого определения?
Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
Вот как ты добавишь или удалишь класс (в понятии class-based) в большой написанно системе за долю секунды?
А зачем? Но вообще, конечно, с помощью загрузчика классов.
И как ты заставишь классы обмениваться сообщениями?
Сообщениями обмениваются не классы, а объекты.
Упс. А ты заметил в этой цитате слово «компонент»? Или я один его вижу?
А это цитата из Кэя? Можно первоисточник?
то там плагины можно реально включать и отключать за долю секунды
Готовые и написанные. Не вопрос, в любой нормальной плагинной системе то же самое. И да, это может быть одним из вариантов компонентной разработки, только при чем тут ООП?
меняя логику обмена сообщениями и поведение системы.
Давайте начнем с вопроса "где в WP сообщения".
Но в основе всего был поставлен CBD-принцип или ООП в понятиях Алена Кея.
Я уже привел определение "ООП в понятиях Кэя", которым я пользуюсь. Описанная вами система под него подходит? Или вы пользуетесь другим определением?
BTW, нигде в Кэевском описании (включая Alan Kay on messaging) нет ни слова про перехват сообщений: адресат сообщения всегда определен явно.
Из какого определения?
Из этого:
Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями
у тебя совсем плохо с мышлением?
А это цитата из Кэя? Можно первоисточник?
У меня ощущение что я общаюсь с пнем который научился печатать на клавиатуре.
В первом абзаце я написал что мы исходим из предположения что твои ссылки и мои верны.
Иначе я ровно также могу поставить под сомнение твою ссылку на какую то вики. Ровно также как ты ставишь под сомнение мои ссылки на какие то другие сайты. Перевeду для тех у кого проблемы с умом: любая цитата на сайте не первоисточник, тк первоисточник это живое общение с автором или на худой конец видео с его словами.
Из этого "Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями"
Это не определение. Это рассказ Кэя о том, как он пришел к своему видению.
В первом абзаце я написал что мы исходим из предположения что твои ссылки и мои верны.
Ссылку-то дайте. Пока что я вижу, что эта фраза ("Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.") — это элемент авторского текста в посте. Никакой ссылки на первоисточник там нет.
Иначе я ровно также могу поставить под сомнение твою ссылку на какую то вики.
Дать библиографическую ссылку на Early History of Smalltalk с номером страницы? Мне же не сложно.
То что написано в статье — это лишь вырезки из тех страниц разбавленные выводами к которым пришел после размышлений и анализа своего опыта.
Можно сказать иначе: вся статья это лишь попытка обратить внимание на то что сказано в других источниках ссылки на которые указаны в статье. Все что нужно — просто прочитать статью и ткнуть по ссылкам. Доверять им или нет — не так уж важно. Это личное дело каждого. Я доверяю.
Ссылку на книгу конечно можно дать. Вот только надо учитывать что это все равно не первоисточник. Я писал статьи в журналы и видел как редакторы журналов правят тексты изменяя смысл с ног на голову. Потому почитать полезно, но верить или нет все равно удел личного решения. В этом отношении было бы клево конечно пообщаться с автором в живую :)
В статье всего две ссылки и сказано что размышление основана на тех данных которые указаны в них.
Ни по одной из этих ссылок в цитатах Кэя тоже нет слов "компонент".
Ссылку на книгу конечно можно дать.
Alan C. Kay, The Early History of Smalltalk — ACM SIGPLAN Notices Volume 28, No. 3, March 1993 Pages 69-95. Конкретные шесть пунктов находятся на 78 странице.
Внимательное изучение своих же ссылок дает ссылку на виде http://www.tele-task.de/archive/video/html5/14029/ с выступлением автора.
Вероятно это выжимки из видео https://habrahabr.ru/company/hexlet/blog/303754/
Но могу ошибаться.
Мой английский не так хорош. Если есть кто то свободно владеющий, было бы круто посмотреть и рассудить :) Подтвердить выжимку или опровергнуть.
И цитаты судя по всему от туда.
… в этом письме тоже нет ни одного слова "компонент". Цитата про "я думал об объектах как" — действительно есть, но я с этой цитатой и не спорил никогда, просто она — не определение.
Раннее (70-ых годов) определение я уже привел, оно содержит 6 пунктов (и сильно привязано к Smalltalk). Позднее (2003-его) года определение есть в посте и по ссылке, и оно сводится к
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things
Это определение, действительно, не требует классов, но надо понимать, когда оно возникло.
Получается что не найдя подтверждений своим идеям и не сумев логически разрешить противоречия идей с цитатами
Э, что? Простите, а какая (моя) идея какой цитате противоречит?
Пока что я вижу строго обратное: цитаты из Кэя никак не соотносятся с панегирками в адрес WP. И, аналогично, никак не соотносятся с определением компонентной разработки.
Например твоя идея о том что в ООП объекты описаны классами или чтобы создать объект нужно написать класс.
А у меня есть такая идея? Странно, я ее нигде не озвучивал.
(Зато, наоборот, требование, что каждый объект принадлежит к классу, есть в работе Кэя)
Цитата говорит о том что объекты это компьютеры в сети.
Нет. Цитата говорит, что Кэй думал об объектах как о чем-то похожем на компьютеры в сети: "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages".
Ну ка напиши как мне класс который создаст компьютер в сети
"Ну ка напиши как мне объект который создаст компьютер в сети"
Я никогда не говорил что объекты должны быть написаны. Потому извини, но я не готов писать тебе компьютеры. То как я понимаю объекты далеко в принципе от программирования в общем виде и оооооооооочень редко может принимать форму кода. Примерно в 1% случаев от бесконечности.
Потому извини, не уверен что могу его написать.
А вот те кто молится богу class based OOP явно уверены что объект это экземпляр класса который написан кодом. И я думал что ты из этого лагеря. Но может быть нет? Надо понять твоё определение объекта и станет ясно проблема в голове или у нас новый тип ООП тут появился.
Что в твоём понимании объект?
Я надеюсь, речь идет применительно к программированию? Тогда — это набор данных и/или операций, обычно — в правильном дизайне — семантически связанных.
Я правильно понял что ты можешь создать объект не применяя классы например в php?
Потому что я могу. Из твоего определения создать объект в php без класса. И это означает что либо мы начинаем мыслить рядом, либо ты просто пытаешься придумать свой тип ООП. Потому давай сузим область вопроса до php. Как ты создашь объект в php? Какие способы там тебе известны?
Я правильно понял что ты можешь создать объект не применяя классы например в php? [...] Как ты создашь объект в php? Какие способы там тебе известны?
Не знаю, никогда не писал на php.
В общем твоего определения хватит.
Попа в том что объектом в больших системах может быть не только код, методы и данные. В том числе могут быть машины. Например станок для заточки шестеренок или лампочка с управлением по bluetooth. Это объект. Он может предавать и получать данные. В этом суть. Именно потому автор говорил о похожести на клетки или компьютеры. Компьютер также является объектом и может обмениваться сообщениями в рамках tcp ip сети. Почему автор и приводит TCP систему в качестве примера близкого к идеалу ООП.
Но я понимаю что для не окрепших умов эти понятия слишком далеки от шаблонов и мозг не способен их понять. Возможно на это уйдут годы. А может быть и одной жизни не хватит. Тут кому как повезёт.
объектом в больших системах может быть не только код, методы и данные В том числе могут быть машины. Например станок для заточки шестеренок или лампочка с управлением по bluetooth. Это объект.
Это не объект в терминах программирования. В объектах в терминах программирования могут быть только данные и код (хотя одно можно рассматривать как частный случай другого, в любую сторону).
я конкретно веду речь про ООП от первых слов статьи и до сюда. И привёл уже кучу цитат одного из отцов ООП. Вот он говорит что объект больше похож на клетки и компьютеры. А то что понимают программисты это ковыряние в носу и чесание пуза на мелководье. Вместо того что бы нырнуть в глубь реально интересных и масштабных идей. Ну да ладно. Вам решать где плавать и в каких терминах :)
и кто же определил эти термины?
Узус. Практика использования, иными словами.
Вот он говорит что объект больше похож на клетки и компьютеры.
Нет, он этого не говорит. Сколько еще раз надо привести цитату дословно? "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"
А главное, из того, что он думает об объектах как о чем-то похожем на компьютеры, никак не вытекает, что компьютеры — это объекты; скорее наоборот, если мы говорим о чем-то как о похожем, значит, оно не идентично.
Я бы настоятельно посоветовал всем считающими себя программистами просто ознакомится с текстом книги ради того, чтобы понимать, откуда растут все современные языки ООП. Чтобы отличать базовые концепты в чистом виде от «карго-культов», от выпестованной в религиозных войнах шелухи и от «синтаксического сахара», которым они обильно посыпаны, но который не привносит никакой новизны по сравнению с объектно-ориентированным программированием образца 1967 года.
Ну, а С++ — язык, реализующий несколько парадигм.
А почему вы рассматриваете ООП на базе SmallTalk-80, а не Simula-67? По Симуле даже есть книжка на русском языке.
Я могу предложить две взаимосвязанных причины и одну связанную с ними гипотезу:
- Потому, что термин «объектно-ориентированный» был придуман Аланом Кеем в начале 70-х и в контексте разработки именно Smalltalk. (Какой именно это был на тот момент Smalltalk: -72 или -76 или (что вряд ли) -80 — я точно не знаю.) И это не просто формальный факт, здесь есть важный нюанс: создатели «Smalltalk-OOP» предложили и популизировали именно новый подход к разработке (кто-то скажет парадигму), включающий в себя набор принципов, идей, практик и т.д. Создатели Simula, если и имели ввиду что-то подобное, то это не приобрело такую широкую известность и не оказало непосредственного влияния на развитие программирования как научной(? м.б. инженерной,) дисциплины. Это нисколько не умоляет заслуг авторов Simula-67, продемонстрировавших миру, что даже сложные концепции (конкретно — поддержка инструментария для дискретного имитационного моделирования) могут добавляться в языки без изменения его синтаксиса (по сути, встраиваемые DSL). И, разумеется, Кей занимался изучением Simula и почерпнул оттуда какие-то идеи. Но не только оттуда и, если вы говорите о Simula-67 как о первом объектно-ориентированном языке, то добавьте в список первых еще несколько, упомянутых в History of Smalltalk. Включая, кстати, lisp :)
- Потому, что «центральным концептом ООП было и остается наследование реализации». Это если речь идет о Simula-ООП. Центральным же концептом Smalltalk-ООП является связка объект-сообщение, с упором на последнее. Собственно, это развитие темы об ООП как о «парадигме»: Наследование реализации лишь некоторый отдельный инструмент, который иногда удобен, но иногда и больно бьет по рукам. Для ООП это не есть самый принципиальный момент. Концепция обмена сообщениями между независимыми сущностями дает иное мировоззрение и имеет на несколько порядков более серьезные и интересные последствия. Можно долго спорить, хорошее это мировоззрение или плохое, но то, что это именно взгляд на программирование под иным, существенно отличным от других, углом оспаривать сложно.
- Потому, что есть неподтвержденная гипотеза о том, что как раз позднего связывания (что является непосредственной реализацией понятия «сообщение») в Simula-67 изначально не было и его добавили позже. Я когда-то находил и пытался изучать старые мануалы, там эта тема раскрыта довольно туманно. Для себя я так и не смог понять, были в конце 60-х – начале 70-х «виртуальные методы» в Simula-67 или нет. Если были, этот язык можно признать первым объектно-ориентированным языком с поправкой на то, что самого термина «объектно-ориентированный» тогда еще не было. Если полноценного позднего связывания там не было, тогда авторы изобрели объекты как экземпляры классов, объединяющие процедуры и функции, и показали, что этот механизм удобен при решении ряда задач. Результат очень значимый (действительно очень!), но все таки не тянет на термин объектно-ориентированное программирование.
Кстати, «язык» программрования называется Smalltalk, а не SmallTalk.
Вы упомянутую книжку про Симулу просмотрели? У меня создалось впечатление, что нет, возможно ошибочное.
Прежде всего, вы смешиваете концептуальный уровень ООП «все есть объекты, объекты взаимодействуют посылкой сообщений» и уровень логический, где объекты классифицируются, а передача сообщений обретает конкретный механизм реализации.
В Симуле объект — центральное понятие. Но Симула — это логический уровень, реализация. Поэтому там есть и классы (параграф 1.1), и посылка сообщений (параграф 1.6) и иерархическая реализация наследования (параграфы 1.3-1.4).
Из этого не следует, что Симула «круче» Смоллтока. Из этого вообще ничего не следует, кроме факта: к 1967 году у программистов уже была не только концепция ООП, но и первая промышленная реализация языка и среды.
Оба языка/среды появились в тех областях, где ООП показывает максимальную эффективность: имитационное моделирование и графические интерфейсы — строительство искусственных миров.
ООП система — это любой из диалектов Smalltalk. К ним относятся:
- Dolphin Smalltalk
- Visual Smalltalk
- Squeak
- IBM Smalltalk/V
- И другие
Даже язык Java в является ООП системой.
Возвращаясь к принципа ООП, изначально которые были заложены Аланом Кеем. Они заключались в том, что программная система подобна живому организму, состоящая из живых клеток, которые пересылают между собой сообщения для взаимодействия. В качестве реализации системы с подобной архитектурой выступают принципы ООП, которые позволяют реализовать выше сказанное.
Другим наиболее важным принципом являлось рекурсивность системы: мета класс -> класс -> инстанция.
Как было сказано в комментариях, действительно, заложенные изначально принципы впоследствии эволюционировали вместе с рынком и индустрией, и сейчас мы имеем то, что имеем.
Вообще говорить о том, что лучше и хуже не совсем корректно — это приводит к холиварам и как правило спорщики не будут относиться непредвзято.
Вы упомянутую книжку про Симулу просмотрели? У меня создалось впечатление, что нет, возможно ошибочное.В начале 90-х – начале 2000-х плотно занимался имитационным моделированием дискретных систем, в том числе и в основном подходом, унаследованным от Simula, так что и эту книгу, и множество других источников я, разумеется, не только смотрел, но и плотно изучал в то время.
Прежде всего, вы смешиваете концептуальный уровень ООП «все есть объекты, объекты взаимодействуют посылкой сообщений» и уровень логический, где объекты классифицируются, а передача сообщений обретает конкретный механизм реализации.Я не очень горю желанием разводить очередную дискуссию не понятно о чем, извините. Был конкретный вопрос, мне показалось я могу дать на него вполне конкретный ответ. А обсуждать деление ООП на «концептуальный» и «логический» уровни — наверное, это для что-то слишком мудреное для меня.
Если же речь про реализацию,
Из этого не следует, что Симула «круче» Смоллтока. Из этого вообще ничего не следует, кроме факта: к 1967 году у программистов уже была не только концепция ООП, но и первая промышленная реализация языка и среды.то повторю свою мысль: есть подозрение, что была реализация концепции чего-то, а вот этого чего-то (самой концепции) еще не было. Если я ошибаюсь и вы готовы показать источники, опровергающие данное «подозрение», я с удовольствием от него откажусь — для меня абсолютно непринципиально кто был первым, меня интересует идея и ее практический смысл.
Поясню. Начинать «познавать» ООП я начал давно — в студенческие годы — через C++ (можно обозначить это дело как «мейнстримовое ООП»). На этом пути встретился со множеством проблем, которые для себя разрешить удовлетворительно не мог. Несколько лет разрабатывая имитационные модели и инструментарий для их создания (в том же C++) на основе подходов Simula-67, в плане понимания ООП я не открыл для себя на тот момент ничего нового. А вот познакомившись через пару лет с тем же Smalltalk-ом, я вдруг увидел, как часть этих проблем проблем была элегантно разрешена, а другая просто-напросто «испарилась» (в более чистой и простой концепции они просто не возникают). Мне очень не хочется «бросать тень» на Simula-67 и связывать их с тем ООП, который нынче принимают за таковой, — его сделали то ли реально гении, обогнавшие свое время, то ли мы, их потомки, банальные бездари, извратившие и перевравшие их идеи. Поэтому я больше склоняюсь к приведенной выше интерпретации: решая конкретную задачу (добавления инструментария для моделирования параллельных процессов в существующий язык программирования) сделали гениальная открытие; но во всей полноте раскрыть смысл этого открытия по тем или иным причинам (возможно, как раз потому, что работали на конкретным, относительно «узкоспециализированными» задачами) не смогли; Кэй со своей командой, которые решали гораздо более абстрактную и фантастическую задачу, обобщили ряд «назревших» к тому времени идей и продуктов и сформулировали действительно новую парадигму программирования.
Так и с ООП. На логическом уровне посылка объекту сообщения может быть реализована и как в Смоллтоке — что надо, то и шлю, а если объект не умеет обрабатывать сообщение, то получаю отказ. Чистая незамутненная динамика. А может быть зафиксированной жесткой статикой вызовом метода. И то и другое — объектный подход, каждая реализация которого имеют свои плюсы и минусы.
Как минимум, не то, что этим термином обозначал автор термина.
Подмножество того, что этим термином обозначал автор термина.
ООП требует динамических вызовов.
Из чего Вы делаете такой вывод?
Иначе ассемблер — тоже «подмножество» и тоже ООП.
Тот же вопрос.
Вот пример ролевого подхода к реализации ООП
www.arbinada.com/ru/node/8
Посылка сообщения предполагает свободу получателя при ответе на это сообщение.
С чего Вы это взяли?
Все программисты думают что C++ поддерживает ООП, кроме автора ООП