Все программисты думают что C++ поддерживает ООП, кроме автора ООП

    В последнее время заметил статьи на тему «ООП крут vs процедурное программирование плохо» и «ООП плохо vs процедурное программирование круто» и «ООП и процедурное плохо vs будущее за XYZ принципами», где XYZ какое-то модно новое понятие.

    image

    Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП. Но может быть я ошибаюсь? Давайте посмотрим…

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

    Давайте разберем формулировку ООП


    ООП = объектно-ориентированное программирование. Другими словами программирование которое основано на создании неких объектов. И кто-то решил что речь идет о классах. Но кто это решил? Когда? И почему?

    Со студенческих скамей можно поднять историю и выяснить что один из первых кто реализовал принципы ООП и запустил их в массы является C++.

    Все что шло далее, наследовало именно это понятие. Вс` бы ничего, но есть одна проблема. Все думают что C++ поддерживает и ассоциируется с ООП, кроме автора понятия ООП.

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

    — Ален Кей

    Еще много интересных его цитат по ссылкам:

    1. Интересная статья на Хабре тут

    2. Подборка из 15 цитат часть из которых весьма интересна тут

    Часть из этих цитат будут использованы далее для переворачивания сознания.

    Если C++ это не тот ООП который имел ввиду автор, то какой тот?


    Автор утверждает что речь идет о чем то похожем на SmallTalk. И рекомендует всем изучать LISP. Но много ли из читателей знакомы с этими языками? Если есть те кто глубоко знаком с этими языками и опытом решения реальных прикладных задач, то буду очень рад за комментарии к этой статье.

    Но мое внимание зацепилось еще за ряд его цитат по теме:

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

    2. «Ключ к тому, чтобы делать большие и расширяющиеся системы, заключается в том, чтобы придумывать, как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении».

    3. «Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями».

    4. «Одна из ключевых идей — делать системы, которые бы продолжали работать во время тестирования и, в особенности, во время внесения изменений. Даже большие изменения должны быть инкрементарными и тратить не больше секунды перед вступлением в силу».

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

    И ещё серия для дожатия мысли:
    Мне жаль, что давным давно я использовал термин «объект» для этой темы, потому что из-за этого многие люди фокусируются на меньшей из идей. Большая идея, которой не хватает современным статически-типизированным ОО-языкам: Большая идея это «сообщения». Ключ к созданию хороших масштабируемых систем это проработка механизмов общения модулей, а не проработка их внутренних свойств и поведения.

    В этих цитатах я бы отметил следующие особенности:

    1. Речь не идет о языках программирования, а о подходе.
    2. Фокус не на объектах, да и объекты это не то что общепринято
    3. Объекты — это модули или компоненты системы (может быть даже отдельные компьютеры и серверы)
    4. Суть не в самих объектах, а в способности этих клеток общаться между друг другом посредством сообщений

    И вот мы плотно подошли к тому чтобы перевернуть суть понятия ООП.

    ООП — это архитектура приложения


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

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

    У этой платформы есть ряд соответствий понятию ООП в версии автора:

    1. У этой системы компоненты обмениваются сообщениями друг с другом и таким образом позволяют менять поведение друг друга. Один компонент может изменить поведение других компонентов. (соответствие цитате №1).

    2. У этой платформы вся суть в том что модули могут взаимодействовать друг с другом. При этом внутри сам модуль может быть написан ужасно кривыми руками глупого джуниора (соответствие цитате №2). И у этой платформы количество модулей самое большое в мире относительно других платформ. Вероятно как раз по той причине что в этой платформе этот принцип сделан лучше чем где-либо.

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

    4. При этом каждый компонент достаточно автономный и часто может быть отключен и отремонтирован без остановки всей системы. (соответствие цитате №4). Он может обновляться за несколько секунд на лету. Внутри системы может быть более 100 таких компонентов, каждый из которых обновляется отдельной командой разработчиков.

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

    Мне показалось что именно эта платформа подошла ближе всего к понятию ООП. Вероятно по этой причина эта платформа захватила рынок. Стала №1 в мире по ряду показателей. Более 25% сайтов в мире и в РФ работает на этой платформе. Это абсолютный мировой рекорд. Думаю многие уже догадались о чем речь :) Это WordPress.

    Думаю что в мире есть и другие платформы, которые сумели реализовать принципы ООП близко к тому как это видел автор концепции. Но судя по доле рынка у WP с этим явно наметились успехи. php — это лишь язык программирования. Сам по себе он не дает ООП. ООП образуется только через прослойку, которая дает необходимые методы для взаимодействия компонентов (или объектов в понятии автора концепции)

    Еще одна платформа в которой как мне показалось есть эти особенности это Backbone.js. JavaScript как и php не дает нужных методов для ООП, но Backbone.js уже дает. И позволяет создавать объекты и обеспечивать эффективный обмен сообщениями между ними.

    Или взять актуальную в последнее время систему микросервисов, которые общаются посредством RESTfull API & Webhooks. Каждый такой веб-сервис является по своей сути объектом в понятии ООП как это видит автор.

    Резюме


    Это не попытка навязать свою точку зрения. Это попытка понять кто и как видит эту идеологию. Я люблю ООП в том виде как это принято в php. Использую классы. При этом я не против процедурного программирования и считаю что это хорошо для многих задач. Уважаю подход с REST API и вебхуками. Но каждый метод я не считаю абсолютной истиной и ценю когда каждый инструмент применяется по назначению.

    Еще больше мне нравится система хуков в WordPress, которая позволяет создавать действительно сложные системы с сотнями компонентов, каждый из которых может быть добавлен или удален на любом этапе развития системы. Таким образом нам удавалось создавать очень сложные системы для управления бизнес-процессами или агрегаторы с организацией множества процессов и людей. Очень сложные, аналогов которым сложно найти на рынке. И судя по цитатам автора концепции ООП, то механизм хуков и фильтров WordPress сильно ближе к изначальному понятию ООП чем то что принято писать как классы в php и C++.

    Кто что думает на этот счет? Кому это понимание ООП близко? Почему? Кто считает это бредом? Почему? Поговорите со мной...:)

    Upd. 20160811


    Упс. Оказывается все что я тут описал уже общеизвестно и даже есть в википедии — пруф.
    И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что обычно имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.

    В статье я ошибся сказав что 99% программистов не знают что такое ООП. В комментариях ошиблись те кто решил что эта идея бред. Как-то так.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 310

      +9
      ООП — это архитектура приложения

      Внезапно, нет. Это никак не вытекает из того, что вы выше цитируете из Кея.


      Мне показалось что именно эта платформа подошла ближе всего к понятию ООП.

      Вы, видимо, ничего не слышали про модель акторов.


      Или взять актуальную в последнее время систему микросервисов, которые общаются посредством RESTfull API & Webhooks. Каждый такой веб-сервис является по своей сути объектом в понятии ООП как это видит автор.

      Тоже нет. В RESTful API принципиально не должно быть внутреннего состояния, и там нет никаких сообщений.


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

        –5
        Задумывался. Но это не отменяет суть проблемы.
        Люди начинают судить о том что ООП плохо или хорошо на основании некого своего или агрегированного понятия, не принимая во внимание суть понятия которое вкладывал в него автор.
        Также мне не дает покоя мысль о том что единственная система которая первая подошла близко к сути этого понятия вдруг стала №1 в мире. Совпадение? :)
          +6
          Люди начинают судить о том что ООП плохо или хорошо на основании некого своего или агрегированного понятия, не принимая во внимание суть понятия которое вкладывал в него автор.

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


          Также мне не дает покоя мысль о том что единственная система которая первая подошла близко к сути этого понятия вдруг стала №1 в мире. Совпадение?

          Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.
          Во-вторых, она "первая подошла близко к сути этого понятия" тоже только по вашему мнению — вы проигнорировали мой вопрос про модель акторов.

            –6
            Модель акторов не применял. И плохо понимаю причем тут она.
            Как сказал автор ООП «ошибка в формулировке привела к тому что программисты начали мыслить мелко». Я склонен ему верить. И развиваю его идею о том что объекты поняты обшибочно да и не важны. Вся соль и суть в способности компонентов обмениваться сообщениями. То на что почти никто не обращает внимание.

            Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.

            Так давайте уточним критерии. Их не много.
            1. Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов. Другими словами более 25% Интернет адресов. Это достаточно объективный критерий с точки зрения одной из самых крупных систем в мире.
            2. Количество специалистов и информационных материалов (в России этот показатель конечно пока под вопросом, но скоро думаю выровняется к мировому первенству)
            3. Количество готовых компонентов

            Их реально больше. Но для начала хватит 3-х. По этим критериям нет ни одной другой веб системы которая хоть как то могла бы конкурировать с WP.

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

            Критерии и цитаты на основании которых я сделал такой вывод описал в статье.
            Не понятно каким образом сюда можно отнести модель акторов?
              +3
              Модель акторов не применял. И плохо понимаю причем тут она [...] Вся соль и суть в способности компонентов обмениваться сообщениями.

              При том, что в модели авторов происходит ровно то, что описано у Кея: независимые объекты (акторы) обмениваются сообщениями. Все.


              Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов. Другими словами более 25% Интернет адресов. Это достаточно объективный критерий с точки зрения одной из самых крупных систем в мире.

              Нет. Вы забываете про то, что есть не веб-системы (а уж количество и сложность вообще никак не коррелируют). Попробуйте сделать на WP систему управления станком с ЧПУ, что ли...


              Количество специалистов и информационных материалов

              Не имеет никакого отношения к качеству самой системы (даже если это утверждение верно, во что я не очень верю).


              Количество готовых компонентов

              Банальная ложь: скажем, для .net framework готовых компонентов заведомо больше.


              Критерии и цитаты на основании которых я сделал такой вывод описал в статье.

              Это только слова. Покажите конкретные примеры архитектуры и кода, которые подтвердят, что WP действительно устроен так, как вы ему приписываете.


              Не понятно каким образом сюда можно отнести модель акторов?

              Выше уже написано.

                –14
                При том, что в модели авторов происходит ровно то, что описано у Кея: независимые объекты (акторы) обмениваются сообщениями. Все.

                Это здорово. Вот только меня смущает тот факт что я этого не встречал в реальном мире. Как много систем использует эти механизмы?
                Если они так редки то что можно сказать о их качестве и адекватности?

                Нет. Вы забываете про то, что есть не веб-системы

                Я про них не забыл. Просто убрал из внимания как мало используемые и слишком простые. Любая система которая находится вне веб зачастую очень простая и не может превращаться в достаточно сложную. А именно это ставил во главу угла Ален Кей.
                Опять же это мой опыт. Я когда то занимался создание сложных систем для управления большими организациями. И все что было не веб — умирало рано или поздно просто потому что не могло выдержать расширения и масштабирования. Единственная область технологий которая доказала свою способсность масштабироваться и развиваться — это веб. Потому и рассматриваю только эту часть. Потому что все остальное не требовательно к ООП в той форме которую пытался описать автор. Другими словами там может работать любой тип ООП, даже тот который придуман в C++.

                Банальная ложь: скажем, для .net framework готовых компонентов заведомо больше

                А подтвердить? Или тут на хабре принято просто обвинять людей во лжи без оснований?
                Для WP по последним данным готовых компонентов только в одном официальном каталоге около 46 000 https://wordpress.org/plugins/
                А еще есть бесчисленное множество не официальных каталогов и просто компонентов которые лежат на GitHub.
                Есть данные о числе компонентов под .net? Или ваши слова ничем не подтверждены и являются лишь вашими догадками?
                  +7
                  Вот только меня смущает тот факт что я этого не встречал в реальном мире.

                  Ну так пойдите и познакомьтесь.


                  Как много систем использует эти механизмы?

                  Сколько-то.


                  Если они так редки то что можно сказать о их качестве и адекватности?

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


                  Просто убрал из внимания как мало используемые и слишком простые.

                  Серьезно? Слишком простые? АБС банка — слишком простая? Биллинг сотового оператора — слишком простой? Система бронирования авиабилетов — слишком простая? Глобальный месседжнер, навроде WhatsApp — слишком простой?


                  (я пока даже не беру инфраструктурные вещи типа распределенной базы данных, которая тоже сложнее большей части веб-сайтов)


                  Я когда то занимался создание сложных систем для управления большими организациями.

                  И много вы знаете сложных систем для управления большими предприятиями, написанных на WP?


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


                  Для WP по последним данным готовых компонентов только в одном официальном каталоге около 46 000 https://wordpress.org/plugins/
                  А еще есть бесчисленное множество не официальных каталогов и просто компонентов которые лежат на GitHub.
                  Есть данные о числе компонентов под .net?

                  There are 60,966 packages. Это не считая того факта, что в .net каждый класс — это "компонент" в терминах обмена сообщениями.

                    –16
                    Ну так пойдите и познакомьтесь.

                    Сколько-то.

                    Ты случаем не вегетарианец? Чето какой то напряженный. С таким уровнем аргументации боюсь мало смысла пытаться с тобой общаться. Ты дыши глубже если так нервничаешь и начинаешь так опускаться по мышлению. Либо надо прекращать это. Не дай бог клавиши сломаешь.

                    There are 60,966 packages

                    Ты почитай что там за компоненты. Это jQuery, Bootstrap, AngularJS. Я боюсь тебя огорчить но это не компоненты для .net. Это библиотеки для фронта.
                    Если собирать такие компоненты под WP то можно случайно за 100 000 перевалить. Давай играть честно. Или не играть тогда уж.
                      +9

                      Вот аргументы и кончились. Обидно.

                        –8
                        Аргументы не кончились. Кончилось желание общаться на подобном уровне аргументации как у тебя.
                          +6

                          Так общайтесь на другом, кто ж вам мешает.

                            –6
                            Я привожу цифры, факты, максимально конкретные и чистые.
                            Ты же приводишь аргументы уровня «ну так пойди и познакомься», далее «сколько-то». Единственный числовой фактор который ты привел на проверку оказался лживым и имеющим кучу помех.
                            Вопрос не в том как я общаюсь. А в том как ты. Будь тут хоть один разумный аргумент, я бы продолжил. А так ну нафиг.
                              +5
                              Я привожу цифры, факты, максимально конкретные и чистые.

                              Единственный конкретный факт — это количество плагинов. И о чем оно говорит?

                              0
                              Да бросьте Вы. Собеседник не ведает, что творит.
                          0
                          Вспомнилось (:

                          https://habrahabr.ru/company/mailru/blog/307168/#comment_9736410
                        +1
                        Это здорово. Вот только меня смущает тот факт что я этого не встречал в реальном мире. Как много систем использует эти механизмы?

                        Достаточно. Посмотрите в сторону Akka или там Rx, на которых строятся большие масштабируемые системы (как пример тот же Яндекс) и не очень большие (тот же Rx, используется в Android-приложениях).

                        Кстати говоря, то что Вы описали, есть ничто иное, как микромодульная архитектура.
                          +2
                          Нет. Вы забываете про то, что есть не веб-системы

                          Я про них не забыл. Просто убрал из внимания как мало используемые и слишком простые. Любая система которая находится вне веб зачастую очень простая и не может превращаться в достаточно сложную.

                          Давайте рассмотрим, например, такую не веб программы как операционные системы Windows и Linux. Можете привести мне в пример веб программы большей сложности?
                        +2
                        1. Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов.


                        А почему вы сайты на вордпресе считаете за отдельный сайт, а странички в фейсбуке или вконтакте нет? Просто потому что у них домен второго уровня что ли?
                          +7
                          WP — охватывает более 25% веб сайтов.

                          Вот у нас на 1-м домене: часть адресов отдаётся CMS-кой, часть адресов — api (реализованный на Spring), часть — SPA-админки, использующие это апи. По сложности, api и админки намного превосходят CMS-составляющую, однако, т.к. эти страницы недоступны для роботов, то в статистику попадёт только CMS. И таких примеров среди ИТ-компаний очень много. А если же посмотреть внимательнее, то на деле львиная доля от этих 25-ти процентов WP-сайтов по своей сути простые лендинги/бложики/новостные сайты.
                          Ну ок, WP тут на первом месте. Но это никак не подтверждает и не опровергает, что он хорошо подходит для чего-то более серьёзного, чем типовые сайты.
                          С другой стороны, сколько, например, онлайн-банков построены на WP? Сколько на WP написано enterprise-систем? Сколько проектов/сайтов/приложений гугла, яндекса или других крупных IT-компаний используют WP?
                          Выводы сделать нетрудно.

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

                          Разрешите выразить своё полное согласие!


                          Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.

                          Есть вот такая CMS — Drupal. Там тоже хуки и она постарше вордпресса наверное будет. Тем не менее популярности в ней меньше. Так что даже если вдруг WP действительно номер один — причина этого явно не только в хуках и всём таком.

                            –1
                            Не существует общественного консенсуса о том что такое ООП. Согласитесь, было бы очень странно если бы вы встретились с Аланом Кеем и начали бы ему рассказывать о правильном взгляде на ООП, а он бы только и делал, что удивлялся сокрушаясь как он отстал от жизни.
                              +1
                              Не существует общественного консенсуса о том что такое ООП

                              Есть-есть. Например, есть вполне общераспространеннное мнение, что ООП — это не ФП или не ПП. Используя этот набор отрицаниц, можно создать некий взгляд.


                              Согласитесь, было бы очень странно если бы вы встретились с Аланом Кеем и начали бы ему рассказывать о правильном взгляде на ООП, а он бы только и делал, что удивлялся сокрушаясь как он отстал от жизни.

                              Тем не менее, это именно то, что послужило поводом для его "разъяснений" о его понимании ООП — чье-то обсуждение о природе/определении.


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

                                0
                                Есть-есть. Например, есть вполне общераспространеннное мнение, что ООП — это не ФП или не ПП. Используя этот набор отрицаниц, можно создать некий взгляд.

                                Был бы консенсус, не было бы споров. Наиболее широко распространенное мнение — да, консенсус — нет.
                                И нет, я не вижу ничего странного в том, чтобы, встретившись с АК, рассказать, что нынче в мейнстриме называют ООП, и услышать его реакцию.

                                Рассказать Кею, что в мире делается и предложить ему скорректировать ему свою картину мира, это все-таки не одно и тоже.
                                  0
                                  Рассказать Кею, что в мире делается и предложить ему скорректировать ему свою картину мира, это все-таки не одно и тоже.

                                  А кто-то где-то предлагал?

                                    0
                                    Я об этом спрашивал в первом сообщении
                                      0

                                      Ну то есть вы и предлагали. Не, мне это не интересно, спасибо.

                            0

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

                              +2
                              суть понятия которое вкладывал в него автор


                              Алан просто придумал одно, а высказал — другое. Современное понятие ООП от этого не поменяется.
                                –2
                                Не то.
                                Алан просто придумал и сказал одно, а поняли и начали развивать другое. Вот так точнее.
                                На выходе имеем хитрый и запутанный омоним. Одно слова и два значения.
                                Это как слово «ножка» — может быть речь о части тела человека? а может быть о части мебели на которой сидят?
                                Слово одно — но получило множество значений.
                                Также и с ООП. Тот кто придумал это понятие думал об одном и это понятие также живет и развивается. Этот подход жив и многие его используют. Но называют его иначе или чаще всего вообще никак не называют.
                                Но авторы C++ назвали этим словом некий свой механизм, который ассоциируется с классами, инкапсуляцией и наследованием. Развивается параллельно и имеет мало пересечений с тем значением которое было изначально.

                                Суть и смысл статьи не в том чтобы пытаться менять то ООП которое «классы», а в том чтобы знать правду и что существует второе значение у ООП, которое имелось ввиду автором. Оба инструмента крайне эффективны и полезны если их знать, понимать и уметь применять. Это я говорю как человек которые применяет оба инструмента в работе каждый день. У них реально мало общего — разве что звучание, один автор и то что оба применяются в ИТ. Но по сути это два абсолютно разных принципа и инструмента.
                                Как то так.
                                  +2
                                  Алан просто придумал и сказал одно

                                  цитата из сообщения Алана:
                                  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.

                                  Нет, Алан именно неправильно выразился / «придумал неправильный термин».

                                  а поняли и начали развивать другое.

                                  Что сказал, то и начали развивать.

                                  Суть и смысл статьи не в том чтобы...

                                  Я понимаю, в чём суть статьи (и не спорю с этой сутью), но просто пытаюсь Вам сказать, что сейчас «обмен сообщениями» называется термином акторы, и что Алан «хотел придумать» именно их.
                                    –3
                                    Те системы которые мне известны, которые стали популярны и захватили рынок доказав свою эффективность соответствуют принципу ООП в понятиях Алена Кея не содержат в себе вещей называемых термином «акторы».

                                    Я не против того что акторы имеют место быть и может быть соответствуют изначальному понятию ООП. Мне сложно об этом судить т.к. я не видел ни одной крупной и расширяемой системы которая построена на основе этих штуковин.
                                    Но если будут примеры, то мне будет проще поверить в адекватность этой идеи.
                                    Я не могу доказать обратное без личного опыта, но и без подтверждения с примерами этого утверждения не смогу воспринимать его всерьез. Возможно это так, а может быть и нет. Это все что я могу сказать по этому поводу :)
                                      +1

                                      WhatsApp (Erlang)
                                      Halo (Orleans)
                                      Akka

                                        0
                                        Не знаю на сколько это будет актуально и интересно, но Orleans все же не совсем Акторы. Тут есть интересное сравнение за авторством бывшего лида Акковской команды — https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md, не уверен, что есть на русском
                                          0

                                          Для целей этой дискусии модель "виртуальных акторов" Orleans вполне совпадает с "чистой" моделью акторов в Акке. Нас же интересует изоляция и message passing (пусть даже последний в Orleans и скрыт кодогенерацией, которой MS славен во всех подобных сценариях, сколько я его помню).

                                        +2
                                        Честно прочитав все комментарии, заметил, что Вы часто ссылаетесь на «системы, которые Вам известны», в основном эти системы — система WP.

                                        А ещё какие-нибудь?.. (Возможно я просто пропустил..)

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

                                        Если бы WP был написан на другом принципе, то эта статья была бы именно про него.

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




                                        Пример привычного ООП:
                                        В кругах биоинформатиков довольно популярен набор утилит picard tools. Достаточно успешный проект?

                                        Кстати, не изучал подробно, но возможно Вы знаете, следуют ли веб-браузеры принципу ООП Алана?



                                        Ну, про WhatsApp уже сказали…
                              +1
                              Все что шло далее, наследовало именно это понятие.


                              Ну, правильно. C++ инкапсулировал ООП, а остальные уже наследовали, слегка полиморфя. :)
                                +1

                                А как на счёт прототипов? :)

                                  –5
                                  Идея на столько глубоко засела в уме, что никак не выходит и эта мысль продиктована через ее призму.
                                  Это сложно. Реально сложно попытаться что-то представить выбросив нечто давно сидящее в голове.
                                  Проблема не в том что ООП изменилось со времен C++. Проблема в том что ООП в C++ никогда не было. И то что мутировало в современное ООП — было чем то другим.
                                  То что называлось как ООП — было не верно понятно изначально и в такой форме родилось и в такой форме развивалось.
                                  Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием. И это то что сегодня понимается под ООП.
                                  Но тот который когда то произнес это понятие и ввел его в обиход думал о абсолютно других вещах. Вот об этом статья.
                                  И эти понятие не менее поразительны и полезны.

                                  Представьте что кто то сказал слово «Хуркапука» и имел ввиду нечто похожее на мячик.
                                  А кто то взял и сделал лампочку. И сказал что это Хуркапука. И далее все показали на нее пальцем и сказали что это Хуркапука. И Хуркапука развивалась так много лет и вот у нас уже супер современная Хуркапука. Которую кто то любит, а кто то нет. И когда показывают лампочку то все говорят «вот это Хуркапука».

                                  Но суть в том что изначально то под это понятие ввели мячик. И мячик развивался все это время по своей линии эволюции. И он далеко не лампочка.

                                  Вот об этом статья :)

                                  И вот я пытаюсь сказать о том что Хуркапука изначально круглая и ей круто в ворота голы забивать и это имел ввиду автор этого понятия. А народ тут говорит что я дурак и Хуркапука это такая хрень которая светится и ворота ее бить глупо.
                                  Вот так и живем ))
                                  И кто тут дурак? Я как тот кто попытался воссоздать изначальное понятие и рассказать об этом и может быть плохо донес мысль. Или народ который не понял вообще о чем речь и пытается меня обвинить в глупости говоря что мячик мутировал в лампочку и это нормально?
                                    +2
                                    Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием.

                                    Почему вы в таком случае называете обмен сообщениями объектно-ориентированным программированием? Это можно назвать «сообщение-ориентированное программирование» или «коммуникативное программирование». Потому что там сообщениями обмениваются объекты? Ну так методы друг друга вызывают тоже объекты, а не классы.

                                    Все программисты думают что C++ поддерживает ООП
                                    Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП.

                                    Вам говорят, что ООП это многозначное понятие. Вы же говорите, что никто не понимает, что такое ООП, что есть только одно значение, которое было изначально. Оба смысла этого термина произошли от слова «объект», но используются в немного разных контекстах. Не надо подменять одно другим, или говорить, что все, кто использует другое значение, дураки, которые ничего не понимают.
                                      –1
                                      Вы наивный человек, если надеетесь донести мысль которую до вас не смогли донести несколько поколений гораздо более подготовленных евангелистов.
                                        +2
                                        > Проблема в том что ООП в C++ никогда не было.

                                        Проблема в том, что ООП — это способ программирования, а C++ — всего лишь универсальный язык программирования.
                                        На С++ вполне можно писать ОО программы. Но их можно писать и на старом добром С, и на ассемблере.
                                        А на С++ еще можно и функциональное программирование, только очень неудобно («шурупы гаечным ключом» :) ).

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

                                        Все, что присутствует в «ООП языках» (классы, наследование, инкапсуляция, полиморфизм и т.п.), является всего лишь набором различных инструментов, облегчающим написание ОО программы, а не неотемлемой частью ООП.
                                      +8

                                      Это холивар: Simula vs Smalltalk.

                                        +6

                                        Все конечно прекрасно, но пара моментов зацепила.


                                        1. Обмен посредством сообщений.
                                          Чем это принципиально отличается от того, что объекты вызывают методы других объектов? Или сигналов\слотов Qt?


                                        2. Каждый компонент может быть отключен и заменен на лету.
                                          Допустим, есть объект, который взаимодействует с другим объектом. Соединены они при помощи позднего связывания. Тут "на лету" второй объект отключают, а потом присоединяют другой. Такое легко реализовать в современных языках — на том же C++ это можно сделать через указатель на абстрактный класс родитель. Но ведь проблема в другом — необходимо обработать возможность отключения объекта (получаем NULL) в рантайме. И это уже задача разработчика объекта. Каким образом некое правильное понимание ООП решит эту проблему?
                                          0
                                          1. Отличается это тем, что мы не должны ничего знать об объекте, чтобы послать ему сообщение. В частности, он может вообще не реализовывать обработку этого сообщения. А в C++ вызов несуществующего метода — это ошибка. В широком смысле, эта особенность C++ нарушает принцип инкапсуляции.

                                          2. Это проблема C++ -вского взгляда на вещи. Как раз отличие функции-метода от сообщения.
                                            0

                                            Спасибо за разъяснение, действительно это так.

                                              +4
                                              Отличается это тем, что мы не должны ничего знать об объекте, чтобы послать ему сообщение.

                                              Я правильно понимаю, что хороший пример «как надо» это Objective-C в данном случае?
                                              Только не очень понятно, что в этом хорошего. Сообщение послали, ошибки нет, что происходит — не понятно.
                                                +1
                                                Только не очень понятно, что в этом хорошего. Сообщение послали, ошибки нет, что происходит — не понятно.

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

                                                  +2
                                                  а уж что вы с ним сделаете — дело ваше.

                                                  Есть два варианта обработки ошибки в программе: тихо исправить и громко упасть. Можно считать, что в C++ второй случай реализован из коробки, и его не придётся писать самому.

                                                    +2

                                                    Проблема (для тех, кто исповедует другую школу) в том, что в C++ надо приложить слишком много усилий, чтобы исправить.

                                                      +3
                                                      Да это все незначительная техническая деталь, и еще неизвестно что лучше: разработчики на Objective C тоже могут много рассказать о том, как их программа тихо себе работала с нулл-объектом из-за опечатки, которые остались незамеченными из-за редкого кейса.

                                                      Самая важная у Алана мысль другая (не могу найти точную цитату, кто помнит откуда — помогайте): она в том, что объект — это такой самостоятельный «виртуальный» компьютер с конкретным назначением. Тут он предвосхитил и DDD с его bounded context-ами, и микросервисы.
                                                        0

                                                        … и толку от этой мысли? Чем она отличается от "объект — это совокупность данных и поведения"?

                                                          0
                                                          Если с высоты опыта вот так рассуждать — то ничем. Но если вспомнить себя давным-давно, к мысли «объект — это совокупность данных и поведения» надо приложить SOLID, DDD и лет 5 опыта, и все равно временами косячим, а тут сразу понятно. (там в оригинале лучше было, но что-то не могу вспомнить и нагуглить).
                                                            0

                                                            Кому сразу понятно-то? Человеку без опыта проектирования?

                                                    0
                                                    C# dynamic?
                                                      0

                                                      Ну да, но дорого же.

                                                  +3
                                                  Вызов несуществующего метода (точнее, в случае Smalltalk, попытка отослать сообщение, которое объект не умеет обрабатывать) — это ошибка и в Smalltalk (исключение MessageNotUnderstood). Тут вся разница только в том, что в С++ это ошибка обнаружит себя на этапе компиляции (из-за статической типизации), а в Smalltalk придётся довольствоваться исключением времени исполнения. А разницы между вызовом метода и посылкой сообщения не существует. Это суть есть одно и тоже, терминология просто различная.
                                                    0
                                                    Разница в том, что это исключение можно обработать.
                                                      0
                                                      Ошибку компиляции тоже можно «обработать»: добавить метод или исправить тип объекта на правильный. Что такого особенно полезного можно сделать во время выполнения, обработав исключение, чего нельзя сделать при компиляции, обнаружив ошибку?
                                                        0
                                                        Да что угодно, например, проигнорировать исключение.

                                                        Вы, к примеру, ко мне обращаетесь, говорите: давай, мол, накатим по 100 грамм! А я такой: спасибо, не пью. Это смоллток. А в парадигме C++ Вы говорите, что недопустимо существование такой Вселенной, в которой предлагают выпить непьющему, потому что это ошибка. Вот и разница.
                                                          +1
                                                          Вы, к примеру, ко мне обращаетесь, говорите: давай, мол, накатим по 100 грамм! А я такой: спасибо, не пью. Это смоллток.

                                                          Не совсем. Не "спасибо, не пью", а "о чем вы, не понимаю вас".


                                                          недопустимо существование такой Вселенной, в которой предлагают выпить непьющему, потому что это ошибка

                                                          И таки для некоторых доменов такой сценарий более предпочтителен.

                                                            0
                                                            Понятно было, что будет какая-нибудь чушь… В «парадигме С++», чтобы это не значило, можно с тем же успехом «послать сообщение» предложитьВыпить, на которое получатель реагировал бы, исходя из его текущего состояния и каких-то сведений о сути предложения. Использовать для эмуляции подобной логики исключения — это как раз плохой тон, так как ничего исключительнего в отказе на предложение нет. Это одно из ожидаемых поведений получателя.
                                                        0
                                                        Простите, но вы вводите людей в заблуждение. В Smalltalk-е, если сообщение не удается связать с методом, получателю будет передано сообщение doesNotUnderstand:. В Object (или ProtoObject) соответствующий метод действительно выкидывает MNU, но никто не мешает это поведение переопределить, реагируя иным способом — например, реализуя Proxy или Mock-и.

                                                        Насчет разницы между посылкой сообщения и вызовом метода вы, опять же, заблуждаетесь — она существует. Ее я объяснил ниже.
                                                          0
                                                          Ну да, речь шла о поведении по-умолчанию. Я в курсе, что можно переопределить это поведение, но вопрос тот же: чего такого полезного можно добиться этим способом, чего нельзя сделать в ООП «в стиле С++»? Максимум, это упрощает реализацию некоторых шаблонов (Proxy, например), но ничего принципиально нереализуемого на ООП «в стиле С++» не добавляет.
                                                            +1
                                                            Ни один язык ничего принципиально нереализуемого не добавляет к машине Тьюринга. На этом развитие программирования можно считать завершенным?

                                                            А добиться этим способом (и в более общем виде: «правильным» ООП) можно одной вещи: простоты.

                                                        0
                                                        Не вижу проблемы в С++.
                                                        На нем вполне можно и «истинное ООП». Только работы и возможности ошибиться будет чутка больше, чем в «истинном ОО языке», в котором эту самую работу и возможность ошибиться мы просто перекладываем на разработчиков компилятора или интерпретатора этого языка.
                                                          –2
                                                          «Не вижу проблемы!» — сказал слепой, направляясь к обрыву.

                                                          А вы пробовали увидеть? :)
                                                            0

                                                            Практика — критерий истины. Обрыв либо есть, либо нет. Если он есть — так покажите его.

                                                              –3
                                                              К сожалению, никто не сможет (добровольно) слепому что-либо показать. Вместо бесплодных пререканий тут лучше просто загрузите Pharo или какую-нибудь другую современную реализацию Smalltalk-а да сравните. Впрочем, если в мейнстриме все устраивает, вряд ли поможет — скорее всего, надо разочароваться в привычной парадигме, чтобы понять/принять другую.
                                                                0

                                                                Кажется, Вы скатываетесь в языкосрач.

                                                                  –1
                                                                  Отнюдь! Я нисколько не хотел никого задеть.
                                                                  Я пытаюсь сказать, что «современное» понимание ООП проповедуется и в ВУЗах, и в книгах, и в языках. Ясно, что большинство считает именно это понимание правильным. Это понимание приводит к целому ряду проблем. Лозунг «ООП мертв» — яркое тому подтверждение. И если человек эти проблемы осознает, он может, увидев альтернативу, ее понять и оценить. Если же считать, что в мейнстриме все хорошо, то шансы сразу падают.
                                                                    0

                                                                    Лозунг "ООП мёртв" — нелеп, как нападки на "понимание ООП".
                                                                    С пониманием ООП, конечно, есть проблемы. Но в целом, идея объекта, имеющего внутреннее состояние, и имеющего интерфейс взаимодействия — хороша и удобна. Каков характер интерфейса — сообщения или свойства с методами (впрочем, они взаимовыразимы) — вопрос не существенный.

                                                                      –1
                                                                      Все ясно. Можно заходить на очередной круг с вопросом о том, что внутреннее состояние + интерфейс взаимодействия — это не ООП (хотя бы потому, что какой-нибудь паскалевский модуль вполне удовлетворяет этому определению)… Но зачем, если все хорошо. Проблем нет, индустрия прекрасна! Наслаждайтесь! :)
                                                                        0
                                                                        внутреннее состояние + интерфейс взаимодействия

                                                                        Всего-навсего более общий случай "объектов, обменивающихся сообщениями". Причём, не намного более общий.


                                                                        паскалевский модуль вполне удовлетворяет этому определению

                                                                        Так Вы, кажется жаловались, что "«современное» понимание ООП" — неправильное. Вот, извольте.


                                                                        Чем модуль не объект? Скажем, в VB были классы, но не было наследования. А модуль практически не отличался от глобально объявленного экземпляра объекта.

                                                                          –2
                                                                          Я вам уже все объяснил. Перечитайте мои комментарии, либо (лучше) почитайте того же Кэя. Ключевые слова — «позднее связывания».
                                                                            0
                                                                            Ключевые слова — «позднее связывания».

                                                                            Если это ключевые слова, то название термина подкачало. Назовите парадигму, в которой "Ключевые слова — «позднее связывания»", адекватно ключевым словам. А парадигму, где ключевое слово "объект" — оставьте в покое.
                                                                            Кстати, первое — это подмножество второго.

                                                                              0
                                                                              Это точно. Если программирование объектно-ориентированное, то ключевой единицей является объект, а не какое-то там связывание. Связывание, каким бы оно ни было — это в контексте объектов всего лишь иструмент.
                                                                                –4
                                                                                Я сначала-то подумал, что это такой троллинг. Но появились поклонники, и оказалось, что это почти диагноз. Я изложу свою точку зрения еще раз — по пунктам — и больше здесь не повторяю:

                                                                                • Термин «object-oriented programming» придумал Alan Kay. Как автор он мог вложить в этот термин любой смысл. Он вложил следующий (о чем неоднократно разными способами разъяснял, и более того — реализовал, так что можно посмотреть и убедиться).
                                                                                • Объекты в рамках ООП отличаются от любых других (даже одноименных) сущностей из других парадигм (или назовите как хотите) тем, что объекты взаимодействуют по средствам сообщений.
                                                                                • Поскольку это их отличительная особенность, сообщения чем-то должны отличаться от общепринятого (до ООП) способа «общения» — вызова процедуры/функции.
                                                                                • Отличие сообщения от вызова заключается в том, что во втором случае всегда управление передается в конкретный, заранее известный код, а объект при получении сообщения (именно в момент получения — это и есть позднее связывание) сам «решает», как именно прореагировать — какой код вызвать.
                                                                                • Данная идея (ООП) именно в таком виде действительно очень неплохо работает (а должна еще лучше, ведь до сих пор полностью в абсолютно чистом виде так и не была реализована). Впрочем, это, конечно, спорный вопрос. Но вот то, что ее «современная версия» на самом деле рассыпается — это становится очевидным все большему количеству людей. Статьи с критикой ООП (а это всегда «современный ООП») появляются все чаще и далеко не всегда эта критика беспочвенна.

                                                                                Сказанное не означает, что позднее связывание — это и есть ООП. Понятие существовало и было реализовано (например, в LISP) гораздо раньше. (Кстати, тот же Кэй очень любит LISP, и почему-то даже называет его чуть ли не объектным… впрочем, это надо уточнять, контекст и общую мысль.) ООП — это связка объект-сообщение. И именно связка: убери любое из этой пары — идея рассыпается. Почему это важно — отдельный и долгий разговор.

                                                                                В дискуссиях на темы по типу «нам оно не надо — я щаслифф с двумя плюсами (кофием, диезами и т.д.)», «я так люблю тот ООП, который мне вдолбили, и ничего не хочу больше слушать» я участвовать не собираюсь. Почему — я уже объяснил.
                                                                                Если же к изложенному будут вопросы/замечания по существу — разумеется, отвечу.
                                                                                  0
                                                                                  Объекты в рамках ООП отличаются от любых других (даже одноименных) сущностей из других парадигм (или назовите как хотите) тем, что объекты взаимодействуют по средствам сообщений.

                                                                                  И на основании чего вы делаете такой вывод?


                                                                                  Поскольку это их отличительная особенность, сообщения чем-то должны отличаться от общепринятого (до ООП) способа «общения» — вызова процедуры/функции.

                                                                                  Совершенно не обязательно. Например, "отличительная особенность" может быть в том, что общаются объекты, а не что-то другое.


                                                                                  Отличие сообщения от вызова заключается в том, что во втором случае всегда управление передается в конкретный, заранее известный код, а объект при получении сообщения (именно в момент получения — это и есть позднее связывание) сам «решает», как именно прореагировать — какой код вызвать.

                                                                                  То есть реализация "операции", в которой объект в момент "операции" решает, как прореагировать, является основанной на сообщениях, безотносительно того, как эта операция называется в ЯП?

                                                                                    0
                                                                                    И на основании чего вы делаете такой вывод?
                                                                                    На основании слов Алана Кэя (книги, письма, интервью) и их реализации (Smalltalk).

                                                                                    Совершенно не обязательно. Например, «отличительная особенность» может быть в том, что общаются объекты, а не что-то другое.
                                                                                    Вы не шутите?! Пункт первый: «объекты отличаются сообщениями». Пункт второй: «сообщения отличаются объектами». Я вас правильно понял?

                                                                                    То есть реализация «операции», в которой объект в момент «операции» решает, как прореагировать, является основанной на сообщениях, безотносительно того, как эта операция называется в ЯП?
                                                                                    Я не понимаю, что вы хотите уточнить. На сообщениях основывается не реализация, а взаимодействие между объектами. Объект нужен для того, чтобы отвечать на сообщения. Все остальное — детали реализации.
                                                                                    0
                                                                                    Забыл упомянуть еще одну важую вещь: первым пунктом Кэй в своем определении говорит «все является объектом». То есть, сообщение — тоже объект.
                                                                                      0
                                                                                      На основании слов Алана Кэя (книги, письма, интервью) и их реализации (Smalltalk).

                                                                                      Можно привести конкретные слова Кэя с указанием источника? Желательно так, чтобы они друг другу не противоречили.


                                                                                      Пункт первый: «объекты отличаются сообщениями». Пункт второй: «сообщения отличаются объектами». Я вас правильно понял?

                                                                                      Нет, не правильно.


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

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

                                                                                        –2
                                                                                        Отвечу в вашем стиле.

                                                                                        Можно привести конкретные слова Кэя с указанием источника? Желательно так, чтобы они друг другу не противоречили.
                                                                                        Можно.

                                                                                        Иными словами, не важно, называется ли «нечто» в конкретном ЯП сообщением или вызово важно, что оно (а) направлено к объекту и (б) поведение определяется в момент вызова.
                                                                                        Примерно. Пункт (б) требует коррекции.
                                                                                      0
                                                                                      Термин «object-oriented programming» придумал Alan Kay. Как автор он мог вложить в этот термин любой смысл. Он вложил следующий (о чем неоднократно разными способами разъяснял, и более того — реализовал, так что можно посмотреть и убедиться).

                                                                                      Кстати, весьма любопытно. С Кэевским определением все совсем не так просто. Так на какое же именно определение (и основанное на каких источниках) опираетесь вы?

                                                                                        0
                                                                                        В очередной раз перечитал статью — что именно не просто? Я знаю только один референс, который может претендовать на роль определения — в Early History Of Smalltalk (см., например, здесь). Возражения о том, что это относится исключительно к Smalltalk-у несостоятельны, поскольку а) там явно сказано, что «The first three principles are what objects „are about“ и б) Smalltalk создавался как реализация тех самых идей — соответственно в нем и воплощены они в исходном виде. (Вопрос о том, что на самом деле было три весьма разных Smalltalk-а, ничего не добавит — обнародован был Smalltalk-80, именно он стал реализацией. Хотя в Smalltalk-72 были, похоже, еще более кардинальные идеи). Кроме того, Кэй несколько раз пояснял свою идею в интервью и в письмах. Но это именно дополнения, на роль четких определений они не тянут. Кстати, вот одно из самых длинных и подробно разъясняющих главное: Alan Kay On Messaging
                                                                                          0

                                                                                          Ну то есть вы за определение считаете именно шесть пунктов из EHoS?

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

                                                                                            Как пример, можно взять пункт о классах. Положим (скорее всего, так и было, и тому есть косвенные свидетельства; но я не уверен, утверждать не буду — это не принципиально), изначально классы входили в определение ООП. Но затем появился Self — развивающий концепцию ООП, но при этом очевиднейшим образом остающийся объектным. Пункт про классы перекочевывает в «необязательные».

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

                                                                                              0
                                                                                              Так ООП определил автор.

                                                                                              Окей, это и запомним. Вот это определение:


                                                                                              1. Everything is an object.
                                                                                              2. Objects communicate by sending and receiving messages (in terms of objects).
                                                                                              3. Objects have their own memory (in terms of objects).
                                                                                              4. Every object is an instance of a class (which must be an object).
                                                                                              5. The class holds the shared behavior for its instances (in the form of objects in a program list)
                                                                                              6. 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 как образец такой коммуникации?

                                                                                                0
                                                                                                И вот тут вы попадаете в логический парадокс.
                                                                                                Никакого логического парадокса нет. В него пытаетесь завести вы:
                                                                                                А о них бесполезно говорить. Идеи сложно формализовать, нельзя дать объективное определение
                                                                                                С таким же успехом можно заявлять, что исходное определение — не определение. Математической точности нет (к сожалению или счастью). Но ООП родилось не просто так, а как решение (попытка решения) определенных проблем. И идеи, которые за ним стоят, — это подход к решению этих проблем.

                                                                                                Если чуть-чуть ограничить себя в попытках победить в споре любыми методами и поставить задачу понять, то можно найти время и прочитать в том же 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 четко следует исходной конкцепции ООП и как раз развивает (а не перевирает и уродует) ее, пытаясь (весьма успешно) улучшить некоторые момент реализации.
                                                                                                  +1
                                                                                                  можно найти время и прочитать в том же EHoS следующий абзац:

                                                                                                  … из которого следует, что это определение — и есть идеи. Нет?


                                                                                                  Так что мы не только можем, мы должны использовать его [Smalltalk-80] в качестве источника

                                                                                                  Прекрасно. Разбирая реализацию сообщений в Smalltalk-80 можно выяснить следующее:


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

                                                                                                  Где я не прав/что важное я забыл?


                                                                                                  вся суть ООП заключена в связке объект-сообщение. [...] Я давал ссылку на подробное разъяснение Кэя по этому поводу

                                                                                                  Дайте, пожалуйста, эту ссылку еще раз, чтобы не получилось так, что мы с вами говорим о разных ссылках.

                                                                                                    0
                                                                                                    Alan Kay On Messaging
                                                                                                    Там и про сообщения и про развитие заодно.

                                                                                                    … из которого следует, что это определение — и есть идеи. Нет?
                                                                                                    Нет. Есть проблема. Есть подход к ее решению (то, что я назвал идеями). Про них — целая книга… и не только она. Есть реализация этих идей на «духовном» и «материальном» уровне: разработанная концепция ООП и Smalltalk.

                                                                                                    Где я не прав/что важное я забыл?
                                                                                                    То, что сразу бросается в глаза:

                                                                                                    сообщения определяются именем
                                                                                                    Не понимаю, что имеется ввиду. Сообщение — это объект(!), включающий в себя имя и набор параметров. Может быть два сообщения с одинаковыми именами, но с разными значениями параметров. Так что, скорее, нет.

                                                                                                    первичный выбор кода, вызываемого в ответ на сообщение, выполняется виртуальной машиной по имени сообщения (и адресату, конечно).
                                                                                                    Вас интересуют нюансы реализации? Да, непосредственно передача сообщения объекту в Smalltalk-80 реализована в виртуалке — дань производительности и некоторым сложностям с реализацией. Но семантика (с точки зрения пользователя) проста: за обработку сообщения отвечает объект.

                                                                                                    В Smalltalk-е есть еще целый ряд похожих отступлений от концепции по аналогичным мотивам. …А можно еще вспомнить, что уровнем ниже все это работает на процессоре и ни о каких объектах вообще речи нет.

                                                                                                    В целом, зачем нужны все эти детали в нашем обсуждении — не ясно. Если только вы не продолжаете игры в софистику. И если ваш план состоит в том, чтобы «дискредитировать» мои слова, зафиксировав Smalltalk-овскую реализацию и объявив любую другую необъектной, то не стоит усилий — я на это уже ответил.

                                                                                                    Если же есть настоящее желание понять, то гораздо важнее обсудить подход/идеи, приведшие к созданию ООП. Хотя там все еще менее однозначно и более спорно, чем с определением.
                                                                                                      0
                                                                                                      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, и может использовать ее для более раннего связывания.


                                                                                                      Нет, не так?

                                                                                                        –1
                                                                                                        Как все банально! Придираться к словам и не замечать ненужное. Потихоньку начинает утомлять, но я пока еще потерплю.
                                                                                                        Есть маленькая проблема: нигде в этом сообщении не сказано, что оно про ООП.
                                                                                                        Ну, да когда речь идет про OOPSLA, Smalltalk, Squeak в письме в группу того же Squeak — при чем здесь ООП?!

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

                                                                                                        По поводу связывания по имени — не стоило стараться какими-то хитро-вывернутыми путями получать от меня подтверждение: даже если я это еще не писал здесь (вроде бы даже писал), все равно никакого секрета в этом нет. Другого способа пока как-то не изобрели, насколько я знаю.

                                                                                                        За обработку — да. А за выбор, что обрабатывает — внезапно, не объект. Потому что, если в объекте нет соответствующих методов, он даже не получит управления.
                                                                                                        Объект не может отвечат за выбор «что обрабатывать» — что прислали, то и обрабатывает. И если нет соответствующих методов, то объект все равно получит сообщение — как аргумент в #doesNotUnderstand:.

                                                                                                        Чтобы создать определение того, что же такое «прием-передача сообщения».
                                                                                                        Вам все еще недостаточно источников? Ну, посмотрите здесь. Там много всякого написано, из-за чего может разгореться ни один флейм, но про сообщения, вроде, адекватно.

                                                                                                        Давайте, сравнения ради, посмотрим на «вызов метода» в каком-нибудь C#. <…>
                                                                                                        Зачем?! :D Вы затеяли весь этот некороткий обмен сообщениями ради того, чтобы поймать меня на противопоставлении «посылки сообщений» и «вызова метода»?! Вынужден разочаровать, я достаточно представляю, как реализованы «виртуальные методы» в C++ (5 лет разработки на нем), методы C# (всего пару лет), Java (даже не хочется считать) и т.д., чтобы не утверждать, что там нет посылки сообщений. Конечно есть, иначе сложно было бы называть их объектно-ориентированными. А вот называть посылку сообщения вызовом метода — некорректно. Когда это делают мои коллеги (иногда даже я сам) при обсуждении каких-нибудь повседневных программистких проблем, на это никто не обращает внимания. Но если так начинают высказываться участники дискуссии об ООП, это граничит с невежеством.

                                                                                                        Потому что человек не понимает, чем ООП отличается от «остального». Разбиение системы на компоненты, объединение в компоненте кода с данными… что там еще? Все это было до. Не было наследования (хотя, как же! было, к примеру, в Simula-67…и это, заметьте, на тот момент почему-то не стало поводом для создания новой парадигмы), но классы (а следовательно, и наследование) не являются обязательным атрибутом объектной системы. Так что это тоже не является отличием. А что является?

                                                                                                        Похоже, к данному моменту я таки исчерпал лимит терпения. Можете считать себя победившим в споре, если в этом состояла цель. На массу интересных вопросов мы так и не вышли, но я честно старался.

                                                                                                          0
                                                                                                          Ну, да когда речь идет про OOPSLA, Smalltalk, Squeak в письме в группу того же Squeak — при чем здесь ООП?!

                                                                                                          При чем угодно или ни при чем вообще. Но скорее всего речь идет о дизайне языка, а не об ООП как о парадигме. Но, повторюсь, поскольку в оригинальном письме вся борода цитат вырезана, мы не знаем, на что отвечает Кэй.


                                                                                                          Вам все еще недостаточно источников? Ну, посмотрите здесь

                                                                                                          Угу. Вот только там столько разных вариантов, что понять, о каком именно говорит Кэй — нельзя. А между, скажем, синхронной и асинхронной передачей разница фундаментальная.


                                                                                                          Зачем?

                                                                                                          Чтобы найти отличия, если они есть.


                                                                                                          Конечно есть [посылка сообщения в C++, C# и Java], иначе сложно было бы называть их объектно-ориентированными

                                                                                                          Прекрасно, значит по этому пункту эти языки попадают под определение Кэя. Несложно увидеть, что, скажем, C# попадает и под остальные (кроме шестого, но про него я уже один раз написал). Так? Или есть возражения?


                                                                                                          А что является?

                                                                                                          Вот и мне интересно.

                                                                                                            –1
                                                                                                            В C# далеко не все является объектом.

                                                                                                            Я уже выразил свое разочарование данной беседой. Если есть что сказать по существу — говорите.
                                                                                                              0
                                                                                                              В C# далеко не все является объектом.

                                                                                                              И что же не является объектом в C#? Иными словами, чему я не могу послать сообщение?

                                                                                                                0
                                                                                                                Например, сообщению.
                                                                                                                  0

                                                                                                                  Ой ли?


                                                                                                                  Когда вы имеете дело с сообщением (например, внутри TryInvokeMember) вам ничего не мешает посылать сообщения сочетанию биндера и аргументов.

                                                                                                                    0
                                                                                                                    Что за объект «сочетание биндера и аргументов»?
                                                                                                                      0

                                                                                                                      new Message(invokeMemberBinder, args)

                                                                                                                        0
                                                                                                                        это не объект, это два объекта, не так ли?
                                                                                                                          0

                                                                                                                          Результат выражения — один объект. Ну и да, в языке, где любая коллекция и любой тупл — объект, любое сочетание объектов есть объект.

                                                                                                                            –1
                                                                                                                            Пошлите сообщение объекту-сочетанию биндера и аргументов.
                                                                                                                              0

                                                                                                                              new {invokeMemberBinder, args}.ToString()

                                                                                                                                0
                                                                                                                                «Это не тот объект, который вы ищите». Не надо фокусов. Я прошу объект сообщение, а не тупо Tuple.
                                                                                                                                  0

                                                                                                                                  А это и не Tuple. Впрочем, пример объекта-сообщения был выше:


                                                                                                                                  new Message(invokeMemberBinder, args).Equals(smth)

                                                                                                                                    0
                                                                                                                                    …и откуда он взялся?
                                                                                                                                      0

                                                                                                                                      Я его написал.

                                                                                                                                        0
                                                                                                                                        Третий раз: не надо фокусов. Возможность обернуть объект вокруг чего-то не делает это что-то объектом.
                                                                                                                                          0

                                                                                                                                          Вы хотите сказать, что invokeMemberBinder и/или args не являются объектами? А если бы TryInvokeMember получал в себя готовый message ситуация бы изменилась?

                                                                                                                  0
                                                                                                                  if(x==null)
                                                                                                                  {
                                                                                                                  x= 101;
                                                                                                                  }

                                                                                                                  Код в {} является объектом?
                                                                                                                    0

                                                                                                                    Когда вы работаете с AST — да.

                                                                                                                      –1
                                                                                                                      …А когда я не работаю с AST?
                                                                                                                        0

                                                                                                                        А когда вы не работаете с AST, то зависит от того, с чем вы работаете, потому что если вы открыли этот код в текстовом редакторе, то он просто набор текста. Но если вы работаете с кодом программно из C#, то вы в любом случае будете иметь дело с объектом — будь то объект строки или объект AST.

                                                                                                                    0
                                                                                                                    В те времена, когда я работал на C#, базовые типы, пока их не обернешь в объект, объектами не являлись? Что-то изменилось?

                                                                                                                    А что там насчет указателей?
                                                                                                                      0
                                                                                                                      В те времена, когда я работал на C#, базовые типы, пока их не обернешь в объект, объектами не являлись? Что-то изменилось?

                                                                                                                      Console.WriteLine(5.CompareTo(3))


                                                                                                                      Всегда работало, кстати.


                                                                                                                      А что там насчет указателей?

                                                                                                                      А указатели — это небезопасный код, который является расширенными возможностями.

                                                                                                                        0
                                                                                                                        Еще раз: не надо фокусов. Взять необъектный базовый тип и создать над ним объект — не велика наука. Но это не делает исходное число объектом.

                                                                                                                        То есть, указатели — не объекты?
                                                                                                                          0
                                                                                                                          Взять необъектный базовый тип и создать над ним объект — не велика наука. Но это не делает исходное число объектом.

                                                                                                                          (Расскажите это Smalltalk с его реализацией SmallInteger)


                                                                                                                          С точки зрения пользователя, число имеет тип System.Int32, который унаследован от System.Object. В любом месте, где используется object, можно использовать число. По каким именно — поведенческим! — признакам вы отличаете "необъектный базовый" тип от всех остальных?


                                                                                                                          То есть, указатели — не объекты?

                                                                                                                          Указатели — это хак, который не входит в объектную парадигму C# (и CLI вообще).

                                                                                                                            0
                                                                                                                            Я написал:
                                                                                                                            int v = 101;

                                                                                                                            Какое сообщение я могу отправить v?
                                                                                                                              0

                                                                                                                              Любое, поддерживаемое типом System.Int32.


                                                                                                                              > int v = 101;
                                                                                                                              > Console.WriteLine(v.ToString("N"));
                                                                                                                              101,00
                                                                                                                                –1
                                                                                                                                Это сообщения объекту, который будет создан над значением, содержащемся в v. v останется не-объектом. Язык допускает использование не-объектов. Но это все не принципиально — я только что ответил на исходное послание.
                                                                                                                                  0
                                                                                                                                  v останется не-объектом.

                                                                                                                                  Как вы определите, что это "не-объект" по внешним признакам?

                                                                                                                      0
                                                                                                                      Напомните, какие методы поддерживает null и покончим с этим.

                                                                                                                      Поразмыслив, я понял, что зря упираюсь. Допустим мне удасться найти какие-то моменты, не покрытые в виртуалке соответсвующим хуками. Или я смогу найти нестыковки в языке, допускающие использование не-объектов. Очевидно, все это не носит принципиального характера: архитектуру виртуалки можно пофиксить, в язык добавить еще пару тонн сахара и гордо заявить о «чистом объектном языке». От этого потягивает каким-то душком, но я готов заткнуть нос и согласиться. Что дальше?
                                                                                                                        0
                                                                                                                        Напомните, какие методы поддерживает null и покончим с этим.

                                                                                                                        Никакие, но это не значит, что ему нельзя послать сообщение.


                                                                                                                        Что дальше?

                                                                                                                        А дальше выясняется, что (как минимум некоторые; мы вот увидели на примере C#, но это не потому, что другие хуже, а потому, что я их плохо знаю) современные ОО-языки вполне удовлетворяют правилам Кэя. Возникает вопрос: а что же это за "современная версия ООП" "рассыпается"?

                                                                                                                          –1
                                                                                                                          Никакие, но это не значит, что ему нельзя послать сообщение.
                                                                                                                          Это как же?! Покажите, пожалуйста, пример посылки сообщения этому «объекту». И заодно (раз уж у нас ООП на классах) поясните, какого класса экземпляром он является.

                                                                                                                          Возникает вопрос: а что же это за «современная версия ООП» «рассыпается»?
                                                                                                                          Что за современная версия — я уже не раз писал и здесь, и в комментах к других статьям по теме. Подозреваю, что с логично назревающим вопросом «как именно она рассыпается» такими темпами с вами мы будем разбираться еще полгода. Увольте.
                                                                                                                            0
                                                                                                                            Это как же?! Покажите, пожалуйста, пример посылки сообщения этому «объекту».

                                                                                                                            string q = null;
                                                                                                                            q.Substring(1);

                                                                                                                            И заодно (раз уж у нас ООП на классах) поясните, какого класса экземпляром он является.

                                                                                                                            В моем примере — string.


                                                                                                                            Что за современная версия — я уже не раз писал и здесь

                                                                                                                            Ну тогда я думаю, вас не затруднит коротенько повторить.

                                                                                                                              –1
                                                                                                                              Ошибаетесь
                                                                                                                                0

                                                                                                                                Очень аргументировано, да. Впрочем, с "современным ООП" то же самое — я в этом посте не нашел ни одного данного вами объяснения ни о том, что это такое, ни о том, почему оно "рассыпается".

                                                                                                                                  0
                                                                                                                                  У вас настолько же «аргументированных» ответов, пожалуй побольше, да.

                                                                                                                                  Плохо искали. Даже в этой ветке были отсылки. Только не я вводил это понятие.

                                                                                                                                  Соответственно, если есть желание продолжать — вам и карты в руки. Ведь это же вы, если не ошибаюсь, говорили за индустрию, за развитие понятия ООП и т.п. (причем не раз и не только здесь)? С устаревшим мы, вроде как разобрались, верно? Самое время вам изложить продвинуто-современное.
                                                                                                                                    0
                                                                                                                                    Плохо искали. Даже в этой ветке были отсылки. Только не я вводил это понятие.

                                                                                                                                    Вот именно, что не вводили — так что это очень напоминает straw man argument.


                                                                                                                                    С устаревшим мы, вроде как разобрались, верно?

                                                                                                                                    А я что-то говорил про устаревание?


                                                                                                                                    Самое время вам изложить продвинуто-современное.

                                                                                                                                    Внезапно (!) я считаю, что "продвинуто-современное" понятие ООП сводится к тому, что написано в википедии: объединение (семантически связанных) данных и поведения. Из этого весьма несложным образом вытекают инкапсуляция и полиморфизм. Все.

                                                                                                                                      0
                                                                                                                                      Вот именно, что не вводили — так что это очень напоминает straw man argument.
                                                                                                                                      Вводили другие, я указал на различие. Что-то вам где-то напоминает? Ну, ладно…

                                                                                                                                      А я что-то говорил про устаревание?
                                                                                                                                      А как же? Не ваши слова про то, что было понятие, индустрия изменилась, понятие — тоже. Риторический вопрос: что стало с исходным понятием?

                                                                                                                                      Внезапно (!) я считаю, что «продвинуто-современное» понятие ООП сводится к тому, что написано в википедии: объединение (семантически связанных) данных и поведения.
                                                                                                                                      То есть, абстрактный тип данных? Или в чем отличие?
                                                                                                                                      Кстати, не совсем понятно, как это определение соотносится с теми 6-ю пунктами? Если про устаревание речи не было, то они должны быть эквивалентны, не так ли?

                                                                                                                                      Из этого весьма несложным образом вытекают инкапсуляция и полиморфизм.
                                                                                                                                      Хотелось бы услышать, как из совокупления данных и поведения рождается для начала полиморфизм? Кстати, было бы неплохо уточнить, что это такое. И что такое инкапсуляция, если она «вытекает» из этого, а не является этим.

                                                                                                                                        0
                                                                                                                                        То есть, абстрактный тип данных? Или в чем отличие?

                                                                                                                                        Зависит от того, как вы понимаете термин "поведение".


                                                                                                                                        Кстати, не совсем понятно, как это определение соотносится с теми 6-ю пунктами?

                                                                                                                                        Оно шире, чем те 6 пунктов.


                                                                                                                                        Хотелось бы услышать, как из совокупления данных и поведения рождается для начала полиморфизм?

                                                                                                                                        Полиморфизм — в данном случае — это возможность совершать одни и те же операции над разными объектами. Проистекает она как раз из того, что объект предоставляет операции наружу, и можно ими пользоваться вне зависимости от того, что внутри.


                                                                                                                                        И что такое инкапсуляция, если она «вытекает» из этого, а не является этим.

                                                                                                                                        Инкапсуляция — опять-таки, в данном контексте — это сокрытие информации о внутреннем устройстве объекта, заменяя ее внешним интерфейсом.

                                                                                                                                          0
                                                                                                                                          Оно шире, чем те 6 пунктов.
                                                                                                                                          Что именно добавлено? Или наоборот убрано? Вы ведь можете конкретизировать мысль, а то даже не ясно в каком смысле оно «шире»: там больше ограничений и, соответственно, меньшее количество систем подпадает под это определение? Или наоборот?

                                                                                                                                          Полиморфизм — в данном случае — это возможность совершать одни и те же операции над разными объектами. Проистекает она как раз из того, что объект предоставляет операции наружу, и можно ими пользоваться вне зависимости от того, что внутри
                                                                                                                                          Операции над объектами? Что такое операции над объектами — не припомню, чтобы вы их упоминали…
                                                                                                                                          И поясните процесс проистекания, а то я теряюсь в догадках. Вот создал я объект класса Integer, в котором есть операция умножения. А потом создал экземпляр класса String, где эта операция не объявлена. Теперь я могу второй объект умножать??

                                                                                                                                          Инкапсуляция — опять-таки, в данном контексте — это сокрытие информации о внутреннем устройстве объекта, заменяя ее внешним интерфейсом.
                                                                                                                                          Поясните слово сокрытие? А то вот все говорят «сокрытие», а потом объявляют поля как public… И вот снова незнакомое слово — интерфейс. Что это? Меня терзают смутные сомнения: не надо ли добавить его в определение?

                                                                                                                                          Зависит от того, как вы понимаете термин «поведение».
                                                                                                                                          То есть ваше понимание зависит от моего? Другими словами, своей позиции вы не имеете, а ваши предыдущие слова про согласие с современной трактовкой следует понимать как «я не знаю, но согласен с толпой», верно?
                                                                                                                                          Вот тут есть рассуждение Уильяма Кука по поводу этих различий. Не буду врать, что я его уже прочитал и полностью понял, но хочу поделиться заранее.
                                                                                                                                          И это вроде как подтверждает мою догадку?
                                                                                                                                            0
                                                                                                                                            Что именно добавлено? Или наоборот убрано?

                                                                                                                                            Убрано. Нет необходимости в классах, нет обязательных сообщений.


                                                                                                                                            Операции над объектами? Что такое операции над объектами — не припомню, чтобы вы их упоминали…

                                                                                                                                            Это то самое "поведение", которое было упомянуто изначально.


                                                                                                                                            И поясните процесс проистекания, а то я теряюсь в догадках. Вот создал я объект класса Integer, в котором есть операция умножения. А потом создал экземпляр класса String, где эта операция не объявлена. Теперь я могу второй объект умножать??

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


                                                                                                                                            Поясните слово сокрытие?

                                                                                                                                            Трактуйте его дословно: сокрытие избыточной (нерелевантной) информации от потребителя.


                                                                                                                                            А то вот все говорят «сокрытие», а потом объявляют поля как public…

                                                                                                                                            Это проблема кривой реализации, от нее вы не денетесь никуда.


                                                                                                                                            И вот снова незнакомое слово — интерфейс. Что это?

                                                                                                                                            Правильнее было бы сказать "контракт" (в Майеровском смысле), совокупность договоренностей о поведении объекта.


                                                                                                                                            Меня терзают смутные сомнения: не надо ли добавить его в определение?

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


                                                                                                                                            То есть ваше понимание зависит от моего? Другими словами, своей позиции вы не имеете, а ваши предыдущие слова про согласие с современной трактовкой следует понимать как «я не знаю, но согласен с толпой», верно?

                                                                                                                                            Нет, неверно. Я просто не настолько хорошо знаком с теорией ADT, чтобы аргументированно здесь отвечать.


                                                                                                                                            И это вроде как подтверждает мою догадку?

                                                                                                                                            Наоборот. Там написано следующее: "Objects and abstract data types are not the same thing, and neither one is a variation of the other." Мне пока не хватило усидчивости, чтобы проследить за всем рассуждением.

                                                                                                                                              0
                                                                                                                                              Убрано. Нет необходимости в классах, нет обязательных сообщений.
                                                                                                                                              Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
                                                                                                                                              А сообщения мы убрали — зафиксировано.

                                                                                                                                              Это то самое «поведение», которое было упомянуто изначально.
                                                                                                                                              Упомянуто — не значит определено. Что такое операция/поведение? Как этим пользоваться?

                                                                                                                                              Трактуйте его дословно: сокрытие избыточной (нерелевантной) информации от потребителя.
                                                                                                                                              Я не понимаю. Кто является потребителем? Какая информация является для него избыточной (нерелевантной)? Кто это решает? Как осуществляется это самое сокрытие?

                                                                                                                                              Это проблема кривой реализации, от нее вы не денетесь никуда.
                                                                                                                                              По слухам, в реализации акторной модели Erlang-а к данным объекта из других объектов на самом деле нет никакого доступа. Не уверен, что это так, но если да — ваша инкапсуляция ведь не об этом?
                                                                                                                                              Правильнее было бы сказать «контракт» (в Майеровском смысле), совокупность договоренностей о поведении объекта.<…> оно нам и не нужно
                                                                                                                                              Ну, хорошо — пусть контракт. Это понятие должно же войти в определение ООП, раз вы на него ссылаетесь? А если оно не нужно, почему вам пришлось его упоминать? Давайте тогда откатываться назад и еще раз: что такое инкапсуляция (без упоминаний интерфейсов/контрактов)?

                                                                                                                                              «Objects and abstract data types are not the same thing, and neither one is a variation of the other.»
                                                                                                                                              Ну, а как же тут быть? Мы обсуждаем некий новый термин — ООП. Вы же не опровергаете необходимость его существования? Значит, должны понимать, что он добавляет к уже существующим? Отложим этот вопрос?

                                                                                                                                                0
                                                                                                                                                Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).

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


                                                                                                                                                Упомянуто — не значит определено. Что такое операция/поведение?

                                                                                                                                                Операция/поведение — это, буквально, то, что понимается под этими словами. Что-то, что можно сделать с объектом (например, сохранить).


                                                                                                                                                Как этим пользоваться?

                                                                                                                                                Implementation defined. Где-то это методы, где-то это сообщения — это не принципиально.


                                                                                                                                                Кто является потребителем?

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


                                                                                                                                                Какая информация является для него избыточной (нерелевантной)?

                                                                                                                                                Это определяется решаемой задачей.


                                                                                                                                                Кто это решает?

                                                                                                                                                Разработчик объекта.


                                                                                                                                                Как осуществляется это самое сокрытие?

                                                                                                                                                Implementation-defined.


                                                                                                                                                По слухам, в реализации акторной модели Erlang-а к данным объекта из других объектов на самом деле нет никакого доступа.

                                                                                                                                                Это не так. Если объект сам решит предоставить свои данные наружу, доступ к ним будет. Public field — это то же самое.


                                                                                                                                                Это понятие должно же войти в определение ООП, раз вы на него ссылаетесь?

                                                                                                                                                Нет, не должно.


                                                                                                                                                А если оно не нужно, почему вам пришлось его упоминать?

                                                                                                                                                Потому что разъяснения вполне могут опираться на понятия, существующие за пределами парадигмы.


                                                                                                                                                Давайте тогда откатываться назад и еще раз: что такое инкапсуляция (без упоминаний интерфейсов/контрактов)?

                                                                                                                                                Сокрытие избыточной информации.


                                                                                                                                                Значит, должны понимать, что он добавляет к уже существующим?

                                                                                                                                                Начнем с того, что спрашивать, что термин "(какое-то) программирование" добавляет к термину "(какой-то) тип" — достаточно нелепо, не так ли? Есть люди, которые считают, что объектно-ориентированное программирование можно называть программированием на ADT, есть люди, которые так не считают. Я отношусь ко вторым, потому что (а) я считаю, что ADT — термин из другого уровня абстракции и (б) я считаю, что понятие "поведения" в ADT отличается от понятия "поведение" в объектах; но, к сожалению, я не могу это отличие вербализовать и формализовать. Иными словами, мое мнение о том, что ADT не идентичны объектам интуитивно, и собственных аргументов в его пользу у меня нет — однако, я нашел статью, которая это мнение подтверждает (как, впрочем, и википедия).

                                                                                                                                                  0
                                                                                                                                                  Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
                                                                                                                                                  Это, на самом деле, некие домыслы. Их можно «вычитать» из книжки, но напрямую это там не сказано.
                                                                                                                                                  Ну, куда уж прямее (и я уже указывал на это место): 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).
                                                                                                                                                    0

                                                                                                                                                    Неа. Там всего лишь сказано, что первые три принципа со временем менять не понадобилось, а с оставшимися тремя продолжали играть в каждой реализации.

                                                                                                                                                      0
                                                                                                                                                      Вы издеваетесь?
                                                                                                                                                      The first three principles are what objects «are about»—how they are seen and used from «the outside.»
                                                                                                                                                        0

                                                                                                                                                        Нет, я не издеваюсь. Я же говорю — это фраза, в которой можно прочитать что угодно, было бы желание. Дословный перевод абзаца (чтобы был виден контекст):


                                                                                                                                                        К этому времени [~1972-1973] бОльшая часть схем Smalltalk была сведена к шести основным идеям, которые соответствовали основным посылкам в дизайне интерпретатора. Первые три принципа говорят, "что такое" объекты — как они воспринимаются и используются "снаружи". В последующие годы их менять не понадобилось. Последние три — объекты изнутри — подкручивались в каждой версии Smalltalk (и в последующих OOP-проектах).

                                                                                                                                                        Но самое важное, что это же не имеет значения: мы все равно перешли от Кэевского определения к "моему".

                                                                                                                                                          0
                                                                                                                                                          Первые три принципа говорят, «что такое» объекты
                                                                                                                                                          И как же вы «прочитаете» эту фразу?
                                                                                                                                                          Но самое важное, что это же не имеет значения: мы все равно перешли от Кэевского определения к «моему».
                                                                                                                                                          Кто «мы» и что значит перешли? Перешли к обсуждению ваших попыток что-то сформулировать про ООП — да. Но от этого исходное определение не становится менее важным. Меня лично интересует соотношение идей, рожденных в 70-е, и «современное» их «развитие». Я вот никак не могу уловить, что же улучшилось.
                                                                                                                                                            0
                                                                                                                                                            И как же вы «прочитаете» эту фразу?

                                                                                                                                                            Дословно: в ней описывается, как объекты выглядят "снаружи", т.е., по воспринимаемому поведению.


                                                                                                                                                            Меня лично интересует соотношение идей, рожденных в 70-е, и «современное» их «развитие». Я вот никак не могу уловить, что же улучшилось.

                                                                                                                                                            А почему вы думаете, что развитие идеи — это обязательно ее улучшение? Это может быть уточнение, или обобщение, или создание методологии, или создание производных — и так до бесконечности.

                                                                                                                                                              0
                                                                                                                                                              А почему вы думаете, что развитие идеи — это обязательно ее улучшение?
                                                                                                                                                              Так, развитие может быть связано с ухудшением или «неизменением»? Все, вопрос закрыт! Это как нельзя точно характеризует «современное» определение ООП — ровно то, что я и хотел изначально сказать.
                                                                                                                                                                0
                                                                                                                                                                Так, развитие может быть связано с ухудшением или «неизменением»?

                                                                                                                                                                С ухудшением — нет. А как можно развивать идею, не "улучшая" ее — я выше привел много примеров.

                                                                                                                                                    0
                                                                                                                                                    Начнем с того, что спрашивать, что термин "(какое-то) программирование" добавляет к термину "(какой-то) тип" — достаточно нелепо, не так ли?
                                                                                                                                                    Нелепо плодить синонимы. Если термин появился и был признан, значит он что-то добавил к тому набору терминов, которые были до него.

                                                                                                                                                    Но я так не понял, вы в состоянии дать «замкнутое» определение ООП? Такое, чтобы без отсылок к сущностям, которые не входят в определение, а определяются через третьи сущности, которые тоже не входят и т.д.? А то у вас получается «короткое определение», но куда ни ткни — они объясняются через какие-то новые понятия. Сформулируйте, пожалуйста, хотя бы на уровне тех 3+3 пунктов что же такое ООП, из которых будет понятно, чем оно отличается от не-ООП. А то по кругу ходить надоело уже.
                                                                                                                                                      0
                                                                                                                                                      Нелепо плодить синонимы.

                                                                                                                                                      Так это и не синонимы. Программирование (любое) не может быть синонимом типа (любого).


                                                                                                                                                      Но я так не понял, вы в состоянии дать «замкнутое» определение ООП? Такое, чтобы без отсылок к сущностям, которые не входят в определение, а определяются через третьи сущности, которые тоже не входят и т.д.?

                                                                                                                                                      Конечно, не в состоянии. И никто не в состоянии.


                                                                                                                                                      Сформулируйте, пожалуйста, хотя бы на уровне тех 3+3 пунктов что же такое ООП, из которых будет понятно, чем оно отличается от не-ООП. А то по кругу ходить надоело уже.

                                                                                                                                                      Я, вроде бы, уже сформулировал: объединение (семантически связанных) данных и поведения. В не-ООП (семантически связанные) данные и поведение находятся в разных сущностях; в ООП — в одной (эта сущность и называется объектом). В идеальной реализации объект устроен таким образом, что только он (=его разработчик) определяет, какие части его поведения и/или данных доступны его пользователям (другим объектам).

                                                                                                                                                        –1
                                                                                                                                                        Так это и не синонимы. Программирование (любое) не может быть синонимом типа (любого).
                                                                                                                                                        Если вы не в состоянии объяснить, чем термин A отличается от термина B, то эти термины — синонимы.

                                                                                                                                                        Возвращаясь к конкретике: в каком-нибудь до-объектном языке (ну, скажем, C) есть тип int; есть набор операций, которые вы можете выполнять над значениями этого типа. Чем это не объект по вашему определению?

                                                                                                                                                        Скорее всего, вы возразите, что тут данные и поведение находятся в разных сущностях. Я спрошу: в каких? И мы уйдем в долгий и нудный цикл софистики.

                                                                                                                                                        Но можно этого не делать, а вспомнить, что в том же «чистом»(необъектном) C (или таком же Pascal) можно создать модуль: сложить данные и процедуры вместе. Тут уже сомнение о их совместном расположении быть не может. Так что мы получили объект, соответствующий вашему определению. Нет?
                                                                                                                                                          0
                                                                                                                                                          Если вы не в состоянии объяснить, чем термин A отличается от термина B, то эти термины — синонимы.

                                                                                                                                                          Вам правда надо объяснять, чем тип отличается от программирования? Тип — это сущность, программирование — процесс.


                                                                                                                                                          Чем это не объект по вашему определению?

                                                                                                                                                          Вы сами ответили на этот вопрос.


                                                                                                                                                          Но можно этого не делать, а вспомнить, что в том же «чистом»(необъектном) C (или таком же Pascal) можно создать модуль: сложить данные и процедуры вместе. Тут уже сомнение о их совместном расположении быть не может. Так что мы получили объект, соответствующий вашему определению. Нет?

                                                                                                                                                          А это зависит от того, какие данные и какие процедуры мы сложили вместе. Предположим, нам надо (=у нас есть бизнес-задача) вести учет моих домашних финансов. У нас есть модуль "мои деньги", в котором определены процедуры "приход" (дата и сумма), "расход" (дата и сумма) и "баланс" (возвращает сумму). Если дизайн модуля таков, что все общение с ним происходит через эти процедуры, то да, мы — соласно моему определению — получили объект. Дальше, правда, у нас есть/могут быть проблемы. Например, не очень понятно, как, сохранив этот дизайн, получить учет раздельно моих финансов и семейных финансов. Или, скажем, не очень понятно — хотя вот тут это частично вызвано моим незнанием возможностей Паскаля/Си — насколько легко/сложно пользователю этого модуля обойти эти процедуры и начать напрямую оперировать данными объекта (в этот момент объект "лопнет").

                                                                                                                                                            0
                                                                                                                                                            Словоблудство продолжайте без меня.
                                                                                                                                                              0

                                                                                                                                                              … а казалось бы, именно вы зачем-то попросили у меня мое собственное определение ООП.

                                                                                                                                            0
                                                                                                                                            То есть, абстрактный тип данных? Или в чем отличие?

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

                                                                                          +1
                                                                                          > Можно заходить на очередной круг с вопросом о том, что внутреннее состояние + интерфейс взаимодействия — это не ООП (хотя бы потому, что какой-нибудь паскалевский модуль вполне удовлетворяет этому определению)

                                                                                          внутреннее состояние + интерфейс взаимодействия — это совсем не ООП. Это всего лишь характеристики единицы, с которой оперирует ООП, т.е. объекта.
                                                                                          То, что «паскалевский модуль вполне удовлетворяет», всего лишь означает, что паскалевский модуль может использоваться в качестве инструмента для описания поведения объекта, изменения его состояния и его реакций на внешний мир.

                                                                                          А ООП — это построение программы как описания взаимодействия таких объектов.
                                                                                          В отличие, например, от классического описания последовательности действий.
                                                                                        +1
                                                                                        Если под «современным» пониманием ООП понимать классы, наследование, инкапсуляцию и прочее подобное, то это, конечно муть.
                                                                                        Все перечисленное — всего лишь инструменты для написания ОО программ. Инструменты не идеальные, но какие есть. И с их помощью вполне можно писать ОО программы.
                                                                                        Да, это не так удобно, как в некоторых других языках, больше возможностей для ошибок, но вполне возможно. В конце концов, ООП — всего лишь парадигма построения программы, а не конкретный набор инструментов. А инструменты можно и самому нарисовать.
                                                                                        И должен заметить, что идеального ОО языка просто не существует. У всех какие-то дополнительные заморочки, осложняющие построение модели мира из взаимодействующих объектов.
                                                                                          0
                                                                                          Идеального языка можно ждать до пенсии. :)

                                                                                          Пишем на том, что есть, ничего ж страшного, недостатки и способы их компенсировать или обойти известны.
                                                                            0
                                                                            2. Что-то типо ивентов? По типу: был subscriber, отключили, починили, переподписали обратно на ивент.
                                                                            Так это и на существующих моделях можно реализовать.
                                                                            Вот только он ведь всё равно не сможет отвечать пока отключен.
                                                                            Или я что-то не так понял?
                                                                              0
                                                                              Когда «вызывается метод», вызывается конкретный код.
                                                                              Когда передается сообщение, какой код будет выполнен — заранее неизвестно. Требуется «связать» сообщение с методом. За это отвечает объект, и конкретный код будет выполнен когда сообщение получит конкретный объект в конкретном состоянии. Поэтому тот же Кэй постоянно говорит о позднем связывании.
                                                                                0
                                                                                Когда «вызывается метод», вызывается конкретный код.

                                                                                Кстати, нет. Позднее связывание на методах тоже встречается, причем больше, чем одного вида.

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

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

                                                                                      –2
                                                                                      А вы уверены, что можете говорить от имени всей индустрии? :)

                                                                                      Ну, расскажите свою версию, и мы убедимся, что она является частным случаем описанного процесса.

                                                                                      Мое понимание основывается на том, что изначально вкладывалось в термин object-oriented programming автором термина. То, что, как вы утверждаете от имени всей индустрии, «эволюционировало» (скорее, деградировало) в современное «понимание» этого термина, а) сложнее, б) является частным случаем исходного определения, в) привело к массе ошибочных выводов о «хорошем объектном дизайне» и в конечном итоге завело эту самую индустрию в очередной тупик с криками «ООП умерло! Нас обманули! Ай-да эволюционировать функциональное программирование!»
                                                                                        0
                                                                                        А вы уверены, что можете говорить от имени всей индустрии?

                                                                                        Нет.


                                                                                        На этом, пожалуй, закончим, мне этот формат диалога не интересен. К счастью, когда я говорю method call, окружающие меня коллеги понимают меня одинаково.

                                                                                          –3
                                                                                          Когда слесарь дядя Вася говорит «берем эту хреновину, кладем на эту загогулину и херачим по ней», окружающие его коллеги тоже понимают его одинаково. И все они очень довольны современным состоянием индустрии. Удачи!
                                                                                      0
                                                                                      В мейнстримовых языках это дело хорошо законспирировано, что вводит многих в заблуждение.

                                                                                      Не замечал такого.

                                                                                      В Smaltlalk-е разница между сообщением и методом (оба, кстати, являются объектами и объектами разных классов) — максимально ясна и прозрачна.

                                                                                      А зачем плодить сущности? Всё ясно и прозрачно в мейнстримовых языках, не выдумывайте.
                                                                                        0
                                                                                        В исходном определении ООП есть всего две сущности: объект и сообщение. Реализация его в Smalltalk добавила еще классы, методы …и, на самом деле, еще несколько сущностей — но ни одной такой, какая отсутствовала бы в «современном» определении. А там еще есть инкапсуляция, полиморфизм, абстракция… и еще много действительно лишних сущностей.

                                                                                        Сообщение же лишней сущностью не является, поскольку именно в ней заключен весь смысл понятия «объектно-ориентированное программирование». Что Алан Кэй и все еще пытается донести до «профессионалов» — спустя уже более 40 (±) лет с момента изобретения.

                                                                                        Если же это не так, и «вызов метода» является синонимом «передачи сообщения», то мы немедленно приходим к выводу, что «объектно-ориентированного программирования» не существует. Вызов метода уж точно аналогичен вызову процедуры, а значит все это просто-напросто «программирование на абстрактных типах данных» — незначительное усовершенствование процедурного стиля.
                                                                                          0
                                                                                          Исходное != современное

                                                                                          Исходное понятие ООП и современное понятие ООП — не одно и то же.

                                                                                          Выше я уже высказывался, что Алан создал не тот термин, от этого все беды.
                                                                                            –2
                                                                                            Разумеется! Человек сгенерировал, проработал и воплотил прекрасную идею. Потом ее не поняли, переврали, получили непонятное и страшное нечто, которое никто не понимает и не может объяснить. Зато это СОВРЕМЕННО! (Еще можно приплести индустрию.) И плевать, что из этого нечто рождаются монстры, что все блюют и плачут, что это нечто создает на два порядка больше проблем, чем дает преимуществ. Мы все равно будем называть это нечто не тем термином, ни в коем случае не попробуем понять что же было вначале, будем продолжать пользоваться нашей химерой до тех пор, пока не найдем другой хайп и не начнем насиловать другую идею. Ну, хорошо, если это ваш путь — удачи!
                                                                                              +1
                                                                                              1. Точно воплатил, а не только высказал?
                                                                                              2. Такая ли уж она была прекрасная, раз её реализовывать почти никто не захотел?
                                                                                                0
                                                                                                1. Smalltalk
                                                                                                2. См. п.1 + Objective C + Ruby + еще несколько попыток натянуть новую идею на старый манекен. Да и кто вам мешает самостоятельно ее изучить, попробовать и решить для себя?
                                                                                                  +1
                                                                                                  Да и кто вам мешает самостоятельно ее изучить, попробовать и решить для себя?

                                                                                                  Отсутствие потребности. Я пишу на разных языках, от asm-а до js. И каждый раз приспосабливаюсь к языку. Это совсем не трудно, если не пренебрегать чтением спецификации. А абстрактный спор, что называть ООП, меня не настолько занимает, чтобы ради него осваивать ненужный мне язык.

                                                                                                    0
                                                                                                    Это именно то, о чем я написал выше.
                                                                                                –2
                                                                                                Оказывается это общеизвестно https://habrahabr.ru/post/307354/#comment_9746612
                                                                                                Есть два подтипа ООП.
                                                                                                То за которое нам тут минусы понаставили называется «классно ориентированное». А то которое народу не понравилось называется «компонентно ориентированное».
                                                                                                В общем описали то что давно известно. Но то о чем 99% программистов не знают. И за это получили минуса ))
                                                                                                  +1

                                                                                                  В той статье, которую вы привели типов ООП не два а три. Третий — прототипно ориентированное программирование, которое в javascript. Класс ориентированный подход и прототипно ориентированный подход это варианты реализации поддержки ООП в языке, а компонентный подход это подход к проектированию систем с использованием ООП.


                                                                                                  Всё это действительно давно известно и об этом знают 99% программистов. Теперь вот знаете и вы :)

                                                                                                    –2
                                                                                                    не надо обманывать и додумывать.
                                                                                                    и да, я дописал апдейт к статье где указал что три.

                                                                                                    КомпОП — это разновидность ООП. Еще точнее это и есть ООП в изначальной формулировке. То как это видел автор понятия.
                                                                                                    КлассОП — это более популярная разновидность. Которая появилась через C++

                                                                                                    Что такое КомпОП реально мало кто из программистов знает. Ну я штук 10 опросил. Ни один ничего внятного не сказал. Все про классы говорят. Ну и комменты в этой статье это явно доказывают. Всего 2 или 3 коммента в тему насчитал. Все остальное просто слюни и вода на тему «а мы думаем иначе».
                                                                                                      +1

                                                                                                      Обратите внимание на то, что классовый и прототипный подход это реализации ООП. Оперирующие конкретными терминами которым соответствуют концепции в языке. Нельзя сделать класс в Ecma Script 5, потому, что там его нет.


                                                                                                      Компонентный подход, с другой стороны, реализуется на том, что попадёт в руки. Например на С++.


                                                                                                      Если вы считаете написанное в википедии источником истины, то так же обратите внимание, что в англоязычной википедии компонентный подход не является разновидностью ООП, а вот акторный подход, который вам так не понравился — является.


                                                                                                      Ну и действительно, поправьте статью. Там как ничего не было про прототипное ООП, так ничего и нет.

                                                                                    0
                                                                                    По поводу второго пункта. Правильное понимание ООП по этому поводу дает как минимум два возможных решения:
                                                                                    — «NULL» (в Smalltalk-е его называют nil) является полноценным объектом, для которого можно определить требуемое поведение.
                                                                                    — Даже если требуемое поведение таки не определили, это не смертельно. В том же Smalltalk-е при обработке исключения не «разматывается» стек. Поэтому даже необработанное исключение не приводит к аварийному завершению программы. Получив окно с сообщением об ошибке, разработчик может открыть отладчик, найти причину ошибки, исправить ее и продолжить выполнение программы. В сети ходили видики, где подобным образом (не останавливая работу программу) отлаживают, например, веб-приложения и игру «Астероиды».
                                                                                    +3
                                                                                    Посмотрите на объекты с другой стороны. Не как структуры в программе, а как отдельные программы, общающиеся по какому-то протоколу. Скажем, модные ныне микросервисы (чтобы было больше похоже, пусть там будет не restful API, а json-rpc). Вот примерно такую вещь Алан и имел ввиду.
                                                                                      0
                                                                                      Последний абзац перед Резюме в статье, это не тоже самое?
                                                                                        +1
                                                                                        Почти.

                                                                                        RESTful в его каноничной форме несколько противоречит другому:

                                                                                        «как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении»

                                                                                        С чтением еще ничего (структуру так или иначе знать надо). А вот запрос вида PATCH /user/ {email: «new@email.com»} вместо сообщения changeUserEmail — это уже завязка на внутренние свойства.

                                                                                        Вот всякие JSON-RPC/XML-RPC с методами, отражающими бизнес-действие — ровно оно.
                                                                                          0
                                                                                          Я все же склоняюсь к тому что знать API надо. Не надо знать как он работает внутри. На мой взгляд именно это имел ввиду автор ООП.
                                                                                          Скажем RESTfull API JSON может быть написано на php, ruby или asp.net. Причем внутри он может быть написан на голых функциях без классов и наследования глупым джуниором с говнокодом и кучей ошибок. Но при этом если он отрабатывает все запросы ровно и без ошибок — значит все ок. Объект ведет себя правильно и ожидаемо — значит принцип ООП выполнен.

                                                                                          В плагинах WP тот же принцип. Их более 45 000 штук. Из них 80% написаны ужасно. Открываешь код и хочется рыдать. Но при этом если их включить то в целом система работает. Потому что выполнен базовый принцип ООП — продумана логика обмена сообщениями.

                                                                                          Это не защищает от ошибок на 100%. Если в логике допущены жесткие ошибки то система помрет как и любая другая. Но степень антихрупкости у таких систем сильно выше относительно тех в которых нет механики обмена сообщениями. И компоненты внутри могут быть ужасными, но если на межкомпонентном уровне они себя ведут адекватно, то система будет работать. Возможно в этом причина того что под WP так просто написать новый плагин.
                                                                                            0
                                                                                            ну в ентерпрайзном ООП то же самое — архитектуру и интерфейсы проектировал белый господин из Калифорнии, а внутри классов там что угодно индусско-китайское, и ладно, главное чтобы тесты проходило
                                                                                      +2
                                                                                      Конечно, если говорить про скриптовые языки и фреймворки на них, то там все как-бы проще — нет компиляции, код очень просто подгружать и даже генерировать/модифицировать во время выполнения, концепция сообщений в том или ином виде присутствует. Я не знаком конкретно с вордпресс, поэтому обобщаю на все скритовое — а почти весь веб именно на скриптовых языках.
                                                                                      Если говорить о С++ — то это «низкоуровневое ООП», или, если можно так сказать — ООП времени компиляции. Да, там вызовы методов вместо отправки сообщений и т.д., но без этого низкого уровня невозможен никакой высокий. Ведь процессору пофиг на ООП; процессор все что умеет — исполнять ассемблерные команды, и, так или иначе, только это и делает — но в потоке команд какие-то относятся непосредственно к решаемой задаче, а какие-то к обслуживанию интерпретатора скриптов, фреймворка и прочих высокоуровневых штук. Какой процент тех и других в среднестатистическом современном коде?
                                                                                      Нет, конечно есть например Objective C, в котором реализованы сообщения. Есть Qt с сигналами и слотами — тоже своеобразные сообщения. Да, там еще нельзя изымать объекты и вставлять их во время работы — но в общем это не так уж и сложно сделать. Главный вопрос — нужно ли это? И при построении архитектуры конкретного приложения как раз и определяется, на каком уровне достаточно старого доброго процедурного программирования, где нужно низкоуровневое ООП, а где — полноценное высокоуровневое, с полностью динамическими объектами и сообщениями.
                                                                                        0
                                                                                        Вот эту мысль я и ждал. Похожу мы где то на одной частоте мыслим.
                                                                                        Вероятно есть разные типы ООП. Метод классов как в C++ хорош для компиляций и высоких скоростей.
                                                                                        Метод обмена сообщениями хорош для систем с высоким уровнем сложности и необходимостью подключать и отключать компоненты налету. В крупных системах это часто нужная штука. Например у меня много опыта работы с магазинами, агрегаторами и системами управления бизнес-процессами. Всю систему не вырубить на долго. Но добавлять, изменять и отключать компоненты нужно очень часто, почти каждый день.

                                                                                        От куда вы взяли понятие о низком уровне ООП и высоком уровне ООП? Это кем то уже описано? Или личный опыт?
                                                                                          0
                                                                                          Мысль просто из головы, прочитал ваш пост и придумал.
                                                                                          +1
                                                                                          Есть Qt с сигналами и слотами — тоже своеобразные сообщения. Да, там еще нельзя изымать объекты и вставлять их во время работы — но в общем это не так уж и сложно сделать.

                                                                                          Connect/Disconnect в рантайме вполне себе работают из коробки.
                                                                                            0
                                                                                            Речь идет о подключении и отключении «плагинов» во время работы программы. Да, это возможно и на Qt и даже на Си, но поскольку языки слишком низкоуровневые, то это выглядит не как «идеальное ООП», а как нечто весьма навороченное.
                                                                                            Всякие COM-объекты тоже мыслились как чистое ООП в рантайме. Встраивание программ друг в друга, встраивание данных одной программы в данные другой и т.д.
                                                                                          0
                                                                                          Какой-то не очень связанный (если не сказать бессвязный) поток мыслей. Объект — совокупность данных и операций над ними. Операции проводятся по получению объектом сообщений от других объектов. Вот, пожалуй, и весь ООП. Сокрытие информации и АТД были и до ООП, в ООП добавилось наследование и динамическое связывание. С помощью этих инструментов появляются доселе невиданные возможности расширения ПО таким образом, которые практически никак не затрагивает уже имеющиеся части программы.
                                                                                            +1
                                                                                            Мне показалось что именно эта платформа подошла ближе всего к понятию ООП. Вероятно по этой причина эта платформа захватила рынок. Стала №1 в мире по ряду показателей.
                                                                                            Когда читал это абсолютно честно думал, что это про Windows с их API построеных на событиях и хуках…
                                                                                              0
                                                                                              В общем то почему бы и нет? Я плохо знаком с API Windows. Если там есть обмен сообщениями между компонентами, а компоненты можно легко ставить и удалять то близко.
                                                                                              Вот только в отличие от Windows в том же WP зачастую обмен сообщениями сделан глубже. Хотя могу ошибаться. Суть в том что один компонент WP может подменить собой часть другого компонента, какой то мелкий кусок или почти целиком. Например один компонент фомирует страницу по одному шаблону, а мне это не нравиться и я могу написать компонент, который перехватит сообщение и изменит его так что поменят как шаблон вывода, так и состав данных по своему усмотрению. Тем самым достигается возможность глубоких изменений системы на любом этапе жизни.
                                                                                              При этом зачастую если в итоге нужда в такой логике отпала, то мы отключаем компонент и возвращается оригинальная механика которая была до включения.
                                                                                              Windows приложения могут чуть чуть перекрашивать друг друга, но вот они не могут вмешиваться в ход работы друг друга достаточно легко. Либо я могу ошибаться и сейчас такая возможность уже есть.
                                                                                              +1
                                                                                              Все ерунда это. Есть принципы проектирования, все остальное крутится вокруг них. ООП, не-ООП все подчиняется им. Я так вообще считаю, что все крутится вокруг loose coupling и high cohesion. Все остальные принципы, типа сокрытия, абстракции, модульности, иерархии, локальности все они производные слабого зацепления. И те же упомянутые объекты, сообщения, модули это всего лишь механизмы для достижения слабого зацепления. Классы это иерархия объектов, ничего больше.

                                                                                                +1
                                                                                                ООП это может и идея, но обсуждают программисты не идею, а конкретную реализацию. На С++, На java, неважно, не обязательно вообще на языках программирования, но уже не концепцию а нюансы реализации.

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

                                                                                                Из этого идет и вывод что такое ООП для ИТ — «Это когда мы берем некие данные, и создаем объект, в котором они хранятся. И внутри этого объекта храним также и методы, которые позволяют с этими данными манипулировать. И только эти методы должны точно знать формат данных.»

                                                                                                Всякие геттеры/сеттеры и вообще принцип, по которому обращаясь к данными внутри объекта мы лезем не в само поле с этими данными, а к методу, которые с ними оперирует — вот этот принцип нам позволяет ВЕСЬ код, который имеет четкое представление о том, в каком виде данные хранятся в объекте, содержать внутри этого же объекта, и назвать его методами.

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

                                                                                                Это касается и поддержки — достаточно не создавать суперклассы, чтобы можно было локализировать проблему в конкретном классе объекта, и не бегать по всему проекту в поисках, где что еще нужно поменять, и один человек сможет в этом классе разобраться за разумное время.
                                                                                                От ООП бОльшего как-бы и не ожидалось.
                                                                                                  +1

                                                                                                  Функция конвертации данных из одного формата в другой к какому объекту должна относиться?

                                                                                                    0
                                                                                                    видимо к двум? Одна функция выдает данные своего объекта, другая их сохраняет внутри своего объекта в своем формате.
                                                                                                    Или вам вдруг нужно хранить те же данные в разном виде в одном и том же объекте?

                                                                                                      0
                                                                                                      Одна функция выдает данные своего объекта

                                                                                                      В каком формате?

                                                                                                        0

                                                                                                        В совместимом, очевидно :)

                                                                                                          0

                                                                                                          И чем в данном случае "совместимый" отличается от "другой"?

                                                                                                            +1

                                                                                                            А что мы называем форматом данных? Я подумал, что Вы имеете в виду данные, представленные объектами. Если же Вы имели в виду элементарные типы, то почему бы такой функции не принадлежать глобальному объекту, который сам данные не хранит?

                                                                                                              0

                                                                                                              Это семантика потока байт, реализованная через объекты.


                                                                                                              Хранить все данные глобально? Вы серьёзно?

                                                                                                                0

                                                                                                                Читать сообщение пробовали? Вы видите хранение данных глобально? Я не вижу.

                                                                                                          0
                                                                                                          Вы почитали мой первоначальный комментарий?
                                                                                                          Формат данных — это поля, которые хранятся внутри объекта.

                                                                                                          Если вам нужно получить эти данные — пишете метод внутри объекта, который вам их выдаст в нужном формате.
                                                                                                          Нужны разные — пишете разные методы. И любой внешний объект может запросить данные через геттеры. Но то, как данные хранятся — знают только методы внутри объекта. Поэтому менять их внутренний формат (модернизировать, масштабировать) — несложно. Поменял поля, и подправил методы внутри этого же объекта. А то, что они возвращают наружу — остается как было, совместимость не теряется.

                                                                                                          Что же вы хотите сделать — я пока не понимаю.
                                                                                                            –1

                                                                                                            Есть 100500 различных форматов: DOM0, DOM1, DOM2, JSON, ProtoBuf, Tree…
                                                                                                            Вам нужно произвольно конвертировать их друг в друга.
                                                                                                            А теперь нужно добавить ещё один формат, например, YAML-OM, чтобы можно было конвертировать и в него и из него.
                                                                                                            Через какой промежуточный формат вы предлагаете реализовать конвертер, из DOM0 в YAML-OM?