Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в 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% программистов не знают что такое ООП. В комментариях ошиблись те кто решил что эта идея бред. Как-то так.
Комментарии (292)
pda0
08.08.2016 16:22+1Все что шло далее, наследовало именно это понятие.
Ну, правильно. C++ инкапсулировал ООП, а остальные уже наследовали, слегка полиморфя. :)
maxxannik
09.08.2016 00:40-5Идея на столько глубоко засела в уме, что никак не выходит и эта мысль продиктована через ее призму.
Это сложно. Реально сложно попытаться что-то представить выбросив нечто давно сидящее в голове.
Проблема не в том что ООП изменилось со времен C++. Проблема в том что ООП в C++ никогда не было. И то что мутировало в современное ООП — было чем то другим.
То что называлось как ООП — было не верно понятно изначально и в такой форме родилось и в такой форме развивалось.
Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием. И это то что сегодня понимается под ООП.
Но тот который когда то произнес это понятие и ввел его в обиход думал о абсолютно других вещах. Вот об этом статья.
И эти понятие не менее поразительны и полезны.
Представьте что кто то сказал слово «Хуркапука» и имел ввиду нечто похожее на мячик.
А кто то взял и сделал лампочку. И сказал что это Хуркапука. И далее все показали на нее пальцем и сказали что это Хуркапука. И Хуркапука развивалась так много лет и вот у нас уже супер современная Хуркапука. Которую кто то любит, а кто то нет. И когда показывают лампочку то все говорят «вот это Хуркапука».
Но суть в том что изначально то под это понятие ввели мячик. И мячик развивался все это время по своей линии эволюции. И он далеко не лампочка.
Вот об этом статья :)
И вот я пытаюсь сказать о том что Хуркапука изначально круглая и ей круто в ворота голы забивать и это имел ввиду автор этого понятия. А народ тут говорит что я дурак и Хуркапука это такая хрень которая светится и ворота ее бить глупо.
Вот так и живем ))
И кто тут дурак? Я как тот кто попытался воссоздать изначальное понятие и рассказать об этом и может быть плохо донес мысль. Или народ который не понял вообще о чем речь и пытается меня обвинить в глупости говоря что мячик мутировал в лампочку и это нормально?michael_vostrikov
09.08.2016 06:49+2Ради прикола можно назвать это «КЛАССное программирование» от слова «класс» по аналогии с функциональным программированием.
Почему вы в таком случае называете обмен сообщениями объектно-ориентированным программированием? Это можно назвать «сообщение-ориентированное программирование» или «коммуникативное программирование». Потому что там сообщениями обмениваются объекты? Ну так методы друг друга вызывают тоже объекты, а не классы.
Все программисты думают что C++ поддерживает ООП
Самое смешное в этих статьях то, что многие под ООП понимают некий принцип когда-то заложенный в C++. И редко кто реально понимает что такое ООП. Вдруг мне показалось что 99% программистов вообще плохо понимают что такое ООП.
Вам говорят, что ООП это многозначное понятие. Вы же говорите, что никто не понимает, что такое ООП, что есть только одно значение, которое было изначально. Оба смысла этого термина произошли от слова «объект», но используются в немного разных контекстах. Не надо подменять одно другим, или говорить, что все, кто использует другое значение, дураки, которые ничего не понимают.
Alew
09.08.2016 15:41-1Вы наивный человек, если надеетесь донести мысль которую до вас не смогли донести несколько поколений гораздо более подготовленных евангелистов.
geher
09.08.2016 20:20+2> Проблема в том что ООП в C++ никогда не было.
Проблема в том, что ООП — это способ программирования, а C++ — всего лишь универсальный язык программирования.
На С++ вполне можно писать ОО программы. Но их можно писать и на старом добром С, и на ассемблере.
А на С++ еще можно и функциональное программирование, только очень неудобно («шурупы гаечным ключом» :) ).
Вся суть ООП сводится к тому, что основой программы являются объекты, обладающие набором свойств и методов воздействия на них. А программа описывает взаимодействие между объектами.
Механизм получения свойств (прямое чтение, вызов метода, посылка сообщения и ожидание ответа) и исполнения метода (обычный вызов функции, посылка сообщения, инициация события в системе) — это уже всего лишь особенности реализации.
Все, что присутствует в «ООП языках» (классы, наследование, инкапсуляция, полиморфизм и т.п.), является всего лишь набором различных инструментов, облегчающим написание ОО программы, а не неотемлемой частью ООП.
Alex_ME
08.08.2016 17:07+6Все конечно прекрасно, но пара моментов зацепила.
Обмен посредством сообщений.
Чем это принципиально отличается от того, что объекты вызывают методы других объектов? Или сигналов\слотов Qt?
- Каждый компонент может быть отключен и заменен на лету.
Допустим, есть объект, который взаимодействует с другим объектом. Соединены они при помощи позднего связывания. Тут "на лету" второй объект отключают, а потом присоединяют другой. Такое легко реализовать в современных языках — на том же C++ это можно сделать через указатель на абстрактный класс родитель. Но ведь проблема в другом — необходимо обработать возможность отключения объекта (получаем NULL) в рантайме. И это уже задача разработчика объекта. Каким образом некое правильное понимание ООП решит эту проблему?
vadimr
08.08.2016 17:391. Отличается это тем, что мы не должны ничего знать об объекте, чтобы послать ему сообщение. В частности, он может вообще не реализовывать обработку этого сообщения. А в C++ вызов несуществующего метода — это ошибка. В широком смысле, эта особенность C++ нарушает принцип инкапсуляции.
2. Это проблема C++ -вского взгляда на вещи. Как раз отличие функции-метода от сообщения.
Lsh
08.08.2016 18:12+4Отличается это тем, что мы не должны ничего знать об объекте, чтобы послать ему сообщение.
Я правильно понимаю, что хороший пример «как надо» это Objective-C в данном случае?
Только не очень понятно, что в этом хорошего. Сообщение послали, ошибки нет, что происходит — не понятно.
lair
08.08.2016 18:20+1Только не очень понятно, что в этом хорошего. Сообщение послали, ошибки нет, что происходит — не понятно.
Ну почему "ошибки нет"? В "как надо" должны вернуть сообщение "не поняли ваше сообщение", а уж что вы с ним сделаете — дело ваше.
Zenitchik
08.08.2016 19:04+2а уж что вы с ним сделаете — дело ваше.
Есть два варианта обработки ошибки в программе: тихо исправить и громко упасть. Можно считать, что в C++ второй случай реализован из коробки, и его не придётся писать самому.
lair
08.08.2016 19:05+2Проблема (для тех, кто исповедует другую школу) в том, что в C++ надо приложить слишком много усилий, чтобы исправить.
symbix
08.08.2016 19:21+3Да это все незначительная техническая деталь, и еще неизвестно что лучше: разработчики на Objective C тоже могут много рассказать о том, как их программа тихо себе работала с нулл-объектом из-за опечатки, которые остались незамеченными из-за редкого кейса.
Самая важная у Алана мысль другая (не могу найти точную цитату, кто помнит откуда — помогайте): она в том, что объект — это такой самостоятельный «виртуальный» компьютер с конкретным назначением. Тут он предвосхитил и DDD с его bounded context-ами, и микросервисы.lair
08.08.2016 19:22… и толку от этой мысли? Чем она отличается от "объект — это совокупность данных и поведения"?
symbix
08.08.2016 19:48Если с высоты опыта вот так рассуждать — то ничем. Но если вспомнить себя давным-давно, к мысли «объект — это совокупность данных и поведения» надо приложить SOLID, DDD и лет 5 опыта, и все равно временами косячим, а тут сразу понятно. (там в оригинале лучше было, но что-то не могу вспомнить и нагуглить).
kemiisto
08.08.2016 19:42+3Вызов несуществующего метода (точнее, в случае Smalltalk, попытка отослать сообщение, которое объект не умеет обрабатывать) — это ошибка и в Smalltalk (исключение MessageNotUnderstood). Тут вся разница только в том, что в С++ это ошибка обнаружит себя на этапе компиляции (из-за статической типизации), а в Smalltalk придётся довольствоваться исключением времени исполнения. А разницы между вызовом метода и посылкой сообщения не существует. Это суть есть одно и тоже, терминология просто различная.
vadimr
09.08.2016 05:48Разница в том, что это исключение можно обработать.
kemiisto
09.08.2016 11:35Ошибку компиляции тоже можно «обработать»: добавить метод или исправить тип объекта на правильный. Что такого особенно полезного можно сделать во время выполнения, обработав исключение, чего нельзя сделать при компиляции, обнаружив ошибку?
vadimr
09.08.2016 17:58Да что угодно, например, проигнорировать исключение.
Вы, к примеру, ко мне обращаетесь, говорите: давай, мол, накатим по 100 грамм! А я такой: спасибо, не пью. Это смоллток. А в парадигме C++ Вы говорите, что недопустимо существование такой Вселенной, в которой предлагают выпить непьющему, потому что это ошибка. Вот и разница.lair
09.08.2016 18:01+1Вы, к примеру, ко мне обращаетесь, говорите: давай, мол, накатим по 100 грамм! А я такой: спасибо, не пью. Это смоллток.
Не совсем. Не "спасибо, не пью", а "о чем вы, не понимаю вас".
недопустимо существование такой Вселенной, в которой предлагают выпить непьющему, потому что это ошибка
И таки для некоторых доменов такой сценарий более предпочтителен.
kemiisto
09.08.2016 18:07Понятно было, что будет какая-нибудь чушь… В «парадигме С++», чтобы это не значило, можно с тем же успехом «послать сообщение» предложитьВыпить, на которое получатель реагировал бы, исходя из его текущего состояния и каких-то сведений о сути предложения. Использовать для эмуляции подобной логики исключения — это как раз плохой тон, так как ничего исключительнего в отказе на предложение нет. Это одно из ожидаемых поведений получателя.
chaetal
09.08.2016 21:26Простите, но вы вводите людей в заблуждение. В Smalltalk-е, если сообщение не удается связать с методом, получателю будет передано сообщение doesNotUnderstand:. В Object (или ProtoObject) соответствующий метод действительно выкидывает MNU, но никто не мешает это поведение переопределить, реагируя иным способом — например, реализуя Proxy или Mock-и.
Насчет разницы между посылкой сообщения и вызовом метода вы, опять же, заблуждаетесь — она существует. Ее я объяснил ниже.kemiisto
09.08.2016 21:42Ну да, речь шла о поведении по-умолчанию. Я в курсе, что можно переопределить это поведение, но вопрос тот же: чего такого полезного можно добиться этим способом, чего нельзя сделать в ООП «в стиле С++»? Максимум, это упрощает реализацию некоторых шаблонов (Proxy, например), но ничего принципиально нереализуемого на ООП «в стиле С++» не добавляет.
chaetal
09.08.2016 21:54+1Ни один язык ничего принципиально нереализуемого не добавляет к машине Тьюринга. На этом развитие программирования можно считать завершенным?
А добиться этим способом (и в более общем виде: «правильным» ООП) можно одной вещи: простоты.
geher
09.08.2016 22:49Не вижу проблемы в С++.
На нем вполне можно и «истинное ООП». Только работы и возможности ошибиться будет чутка больше, чем в «истинном ОО языке», в котором эту самую работу и возможность ошибиться мы просто перекладываем на разработчиков компилятора или интерпретатора этого языка.chaetal
10.08.2016 08:22-2«Не вижу проблемы!» — сказал слепой, направляясь к обрыву.
А вы пробовали увидеть? :)Zenitchik
10.08.2016 12:19Практика — критерий истины. Обрыв либо есть, либо нет. Если он есть — так покажите его.
chaetal
10.08.2016 13:55-3К сожалению, никто не сможет (добровольно) слепому что-либо показать. Вместо бесплодных пререканий тут лучше просто загрузите Pharo или какую-нибудь другую современную реализацию Smalltalk-а да сравните. Впрочем, если в мейнстриме все устраивает, вряд ли поможет — скорее всего, надо разочароваться в привычной парадигме, чтобы понять/принять другую.
Zenitchik
10.08.2016 15:37Кажется, Вы скатываетесь в языкосрач.
chaetal
10.08.2016 16:48-1Отнюдь! Я нисколько не хотел никого задеть.
Я пытаюсь сказать, что «современное» понимание ООП проповедуется и в ВУЗах, и в книгах, и в языках. Ясно, что большинство считает именно это понимание правильным. Это понимание приводит к целому ряду проблем. Лозунг «ООП мертв» — яркое тому подтверждение. И если человек эти проблемы осознает, он может, увидев альтернативу, ее понять и оценить. Если же считать, что в мейнстриме все хорошо, то шансы сразу падают.Zenitchik
10.08.2016 16:57Лозунг "ООП мёртв" — нелеп, как нападки на "понимание ООП".
С пониманием ООП, конечно, есть проблемы. Но в целом, идея объекта, имеющего внутреннее состояние, и имеющего интерфейс взаимодействия — хороша и удобна. Каков характер интерфейса — сообщения или свойства с методами (впрочем, они взаимовыразимы) — вопрос не существенный.chaetal
10.08.2016 17:30-1Все ясно. Можно заходить на очередной круг с вопросом о том, что внутреннее состояние + интерфейс взаимодействия — это не ООП (хотя бы потому, что какой-нибудь паскалевский модуль вполне удовлетворяет этому определению)… Но зачем, если все хорошо. Проблем нет, индустрия прекрасна! Наслаждайтесь! :)
Zenitchik
10.08.2016 17:47внутреннее состояние + интерфейс взаимодействия
Всего-навсего более общий случай "объектов, обменивающихся сообщениями". Причём, не намного более общий.
паскалевский модуль вполне удовлетворяет этому определению
Так Вы, кажется жаловались, что "«современное» понимание ООП" — неправильное. Вот, извольте.
Чем модуль не объект? Скажем, в VB были классы, но не было наследования. А модуль практически не отличался от глобально объявленного экземпляра объекта.
chaetal
10.08.2016 18:15-2Я вам уже все объяснил. Перечитайте мои комментарии, либо (лучше) почитайте того же Кэя. Ключевые слова — «позднее связывания».
Zenitchik
10.08.2016 18:33Ключевые слова — «позднее связывания».
Если это ключевые слова, то название термина подкачало. Назовите парадигму, в которой "Ключевые слова — «позднее связывания»", адекватно ключевым словам. А парадигму, где ключевое слово "объект" — оставьте в покое.
Кстати, первое — это подмножество второго.geher
10.08.2016 20:56Это точно. Если программирование объектно-ориентированное, то ключевой единицей является объект, а не какое-то там связывание. Связывание, каким бы оно ни было — это в контексте объектов всего лишь иструмент.
chaetal
11.08.2016 22:40-4Я сначала-то подумал, что это такой троллинг. Но появились поклонники, и оказалось, что это почти диагноз. Я изложу свою точку зрения еще раз — по пунктам — и больше здесь не повторяю:
- Термин «object-oriented programming» придумал Alan Kay. Как автор он мог вложить в этот термин любой смысл. Он вложил следующий (о чем неоднократно разными способами разъяснял, и более того — реализовал, так что можно посмотреть и убедиться).
- Объекты в рамках ООП отличаются от любых других (даже одноименных) сущностей из других парадигм (или назовите как хотите) тем, что объекты взаимодействуют по средствам сообщений.
- Поскольку это их отличительная особенность, сообщения чем-то должны отличаться от общепринятого (до ООП) способа «общения» — вызова процедуры/функции.
- Отличие сообщения от вызова заключается в том, что во втором случае всегда управление передается в конкретный, заранее известный код, а объект при получении сообщения (именно в момент получения — это и есть позднее связывание) сам «решает», как именно прореагировать — какой код вызвать.
- Данная идея (ООП) именно в таком виде действительно очень неплохо работает (а должна еще лучше, ведь до сих пор полностью в абсолютно чистом виде так и не была реализована). Впрочем, это, конечно, спорный вопрос. Но вот то, что ее «современная версия» на самом деле рассыпается — это становится очевидным все большему количеству людей. Статьи с критикой ООП (а это всегда «современный ООП») появляются все чаще и далеко не всегда эта критика беспочвенна.
Сказанное не означает, что позднее связывание — это и есть ООП. Понятие существовало и было реализовано (например, в LISP) гораздо раньше. (Кстати, тот же Кэй очень любит LISP, и почему-то даже называет его чуть ли не объектным… впрочем, это надо уточнять, контекст и общую мысль.) ООП — это связка объект-сообщение. И именно связка: убери любое из этой пары — идея рассыпается. Почему это важно — отдельный и долгий разговор.
В дискуссиях на темы по типу «нам оно не надо — я щаслифф с двумя плюсами (кофием, диезами и т.д.)», «я так люблю тот ООП, который мне вдолбили, и ничего не хочу больше слушать» я участвовать не собираюсь. Почему — я уже объяснил.
Если же к изложенному будут вопросы/замечания по существу — разумеется, отвечу.lair
11.08.2016 22:53Объекты в рамках ООП отличаются от любых других (даже одноименных) сущностей из других парадигм (или назовите как хотите) тем, что объекты взаимодействуют по средствам сообщений.
И на основании чего вы делаете такой вывод?
Поскольку это их отличительная особенность, сообщения чем-то должны отличаться от общепринятого (до ООП) способа «общения» — вызова процедуры/функции.
Совершенно не обязательно. Например, "отличительная особенность" может быть в том, что общаются объекты, а не что-то другое.
Отличие сообщения от вызова заключается в том, что во втором случае всегда управление передается в конкретный, заранее известный код, а объект при получении сообщения (именно в момент получения — это и есть позднее связывание) сам «решает», как именно прореагировать — какой код вызвать.
То есть реализация "операции", в которой объект в момент "операции" решает, как прореагировать, является основанной на сообщениях, безотносительно того, как эта операция называется в ЯП?
chaetal
11.08.2016 23:18И на основании чего вы делаете такой вывод?
На основании слов Алана Кэя (книги, письма, интервью) и их реализации (Smalltalk).
Совершенно не обязательно. Например, «отличительная особенность» может быть в том, что общаются объекты, а не что-то другое.
Вы не шутите?! Пункт первый: «объекты отличаются сообщениями». Пункт второй: «сообщения отличаются объектами». Я вас правильно понял?
То есть реализация «операции», в которой объект в момент «операции» решает, как прореагировать, является основанной на сообщениях, безотносительно того, как эта операция называется в ЯП?
Я не понимаю, что вы хотите уточнить. На сообщениях основывается не реализация, а взаимодействие между объектами. Объект нужен для того, чтобы отвечать на сообщения. Все остальное — детали реализации.
chaetal
11.08.2016 23:11Забыл упомянуть еще одну важую вещь: первым пунктом Кэй в своем определении говорит «все является объектом». То есть, сообщение — тоже объект.
lair
11.08.2016 23:21На основании слов Алана Кэя (книги, письма, интервью) и их реализации (Smalltalk).
Можно привести конкретные слова Кэя с указанием источника? Желательно так, чтобы они друг другу не противоречили.
Пункт первый: «объекты отличаются сообщениями». Пункт второй: «сообщения отличаются объектами». Я вас правильно понял?
Нет, не правильно.
Я не понимаю, что вы хотите уточнить. На сообщениях основывается не реализация, а взаимодействие между объектами. Объект нужен для того, чтобы отвечать на сообщения.
Я хочу уточнить тот факт, что для определения того, является ли конкретный язык/реализация/парадигма объектно-ориентированными, нам важно не название того, как там сделана операция, а способ. Иными словами, не важно, называется ли "нечто" в конкретном ЯП сообщением или вызово важно, что оно (а) направлено к объекту и (б) поведение определяется в момент вызова. (Я просто не понимаю, как вы иначе будете определять, что есть вызов, а что есть сообщение)
chaetal
11.08.2016 23:37-2Отвечу в вашем стиле.
Можно привести конкретные слова Кэя с указанием источника? Желательно так, чтобы они друг другу не противоречили.
Можно.
Иными словами, не важно, называется ли «нечто» в конкретном ЯП сообщением или вызово важно, что оно (а) направлено к объекту и (б) поведение определяется в момент вызова.
Примерно. Пункт (б) требует коррекции.
lair
11.08.2016 23:17Термин «object-oriented programming» придумал Alan Kay. Как автор он мог вложить в этот термин любой смысл. Он вложил следующий (о чем неоднократно разными способами разъяснял, и более того — реализовал, так что можно посмотреть и убедиться).
Кстати, весьма любопытно. С Кэевским определением все совсем не так просто. Так на какое же именно определение (и основанное на каких источниках) опираетесь вы?
chaetal
11.08.2016 23:32В очередной раз перечитал статью — что именно не просто? Я знаю только один референс, который может претендовать на роль определения — в Early History Of Smalltalk (см., например, здесь). Возражения о том, что это относится исключительно к Smalltalk-у несостоятельны, поскольку а) там явно сказано, что «The first three principles are what objects „are about“ и б) Smalltalk создавался как реализация тех самых идей — соответственно в нем и воплощены они в исходном виде. (Вопрос о том, что на самом деле было три весьма разных Smalltalk-а, ничего не добавит — обнародован был Smalltalk-80, именно он стал реализацией. Хотя в Smalltalk-72 были, похоже, еще более кардинальные идеи). Кроме того, Кэй несколько раз пояснял свою идею в интервью и в письмах. Но это именно дополнения, на роль четких определений они не тянут. Кстати, вот одно из самых длинных и подробно разъясняющих главное: Alan Kay On Messaging
lair
11.08.2016 23:39Ну то есть вы за определение считаете именно шесть пунктов из EHoS?
chaetal
12.08.2016 07:46Так ООП определил автор. Вы (если не ошибаюсь) верно заметили в одном из комментариев, что должно быть развитие, и это определение тоже можно развивать. Но изменение должно оставаться в рамках исходных идей (мы о них, кстати, еще даже не говорили).
Как пример, можно взять пункт о классах. Положим (скорее всего, так и было, и тому есть косвенные свидетельства; но я не уверен, утверждать не буду — это не принципиально), изначально классы входили в определение ООП. Но затем появился Self — развивающий концепцию ООП, но при этом очевиднейшим образом остающийся объектным. Пункт про классы перекочевывает в «необязательные».
Мне — как еще один пример — кажется излишним пункт про наличие памяти у объектов. На мой взгляд, это некоторое дополнение, поясняющее концепцию. Вроде бы, на сегодняшний день не видно, как может быть иначе. Но это не повод сужать область определения без необходимости. Может быть (я фантазирую) что-то из ФП сможет таким образом попасть в разряд ООП (если получится идентифицировать объекты…). При этом, если каким-то чудесным образом появится концепция как делать объекты без этой самой внутренней памяти, и эта концепция будет идти в каких-то моментах вразрез с идеями ООП, то мне придется отказаться от этой гипотезы. А эту волшебную концепцию (или «парадигму» на ее основе) нужно будет называть иначе.
lair
12.08.2016 11:24Так ООП определил автор.
Окей, это и запомним. Вот это определение:
- Everything is an object.
- Objects communicate by sending and receiving messages (in terms of objects).
- Objects have their own memory (in terms of objects).
- Every object is an instance of a class (which must be an object).
- The class holds the shared behavior for its instances (in the form of objects in a program list)
- To eval a program list, control is passed to the first object and the remainder is treated as its message.
Но изменение должно оставаться в рамках исходных идей (мы о них, кстати, еще даже не говорили).
А о них бесполезно говорить. Идеи сложно формализовать, нельзя дать объективное определение того, что в рамках, а что нет, и, что веселее всего, обращаясь к идеям, можно внезапно выяснить, что эти идеи были не про ООП.
Поэтому давайте оставаться в рамках определения.
Положим (скорее всего, так и было, и тому есть косвенные свидетельства; но я не уверен, утверждать не буду — это не принципиально), изначально классы входили в определение ООП.
Какое "положим", какие "косвенные свидетельства"? Пункты 4 и 5 выше явно говорят нам, что в определение-ООП-по-Кэю классы входят.
Но затем появился Self — развивающий концепцию ООП, но при этом очевиднейшим образом остающийся объектным. Пункт про классы перекочевывает в «необязательные».
И вот тут вы попадаете в логический парадокс. Если термин ООП придуман и определен Кэем, то язык, противоречащий этому определению, не может "очевиднейшим образом" быть объектным. Поэтому одно из двух: или определение Кэя некорректно (и тогда вся ваша риторика по "современный ООП" выдумана на пустом месте), или же нет ничего очевидного в том, что Self — ОО-язык.
Так вот, вернемся к определению. Поскольку это определение, то то, что под него попадает — ООП, то, что не попадает — не ООП. Давайте, для простоты, договоримся не учитывать 6 пункт, потому что это дизайн-ограничение для среды выполнения (и, будем честными, реализуется в любом современном языке с AST).
Из оставшихся пяти вопрос вызывает, очевидно, второй пункт: "objects communicate by sending and receiving messages". Что именно это означает? Какой тип коммуникации является отправкой/получением сообщений, а какой — нет? Можем ли мы использовать Smalltalk 80 как образец такой коммуникации?
chaetal
12.08.2016 12:06И вот тут вы попадаете в логический парадокс.
Никакого логического парадокса нет. В него пытаетесь завести вы:
А о них бесполезно говорить. Идеи сложно формализовать, нельзя дать объективное определение
С таким же успехом можно заявлять, что исходное определение — не определение. Математической точности нет (к сожалению или счастью). Но ООП родилось не просто так, а как решение (попытка решения) определенных проблем. И идеи, которые за ним стоят, — это подход к решению этих проблем.
Если чуть-чуть ограничить себя в попытках победить в споре любыми методами и поставить задачу понять, то можно найти время и прочитать в том же 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 четко следует исходной конкцепции ООП и как раз развивает (а не перевирает и уродует) ее, пытаясь (весьма успешно) улучшить некоторые момент реализации.lair
12.08.2016 12:20+1можно найти время и прочитать в том же EHoS следующий абзац:
… из которого следует, что это определение — и есть идеи. Нет?
Так что мы не только можем, мы должны использовать его [Smalltalk-80] в качестве источника
Прекрасно. Разбирая реализацию сообщений в Smalltalk-80 можно выяснить следующее:
- сообщения определяются именем
- процесс отправки-получения сообщения синхронен
- процесс отправки-получения сообщения двухсторонний (т.е., "отправка сообщения" — это выражение, имеющее результат, и этот результат возвращается из вызванного кода)
- первичный выбор кода, вызываемого в ответ на сообщение, выполняется виртуальной машиной по имени сообщения (и адресату, конечно). Это происходит в момент отправки-получения, потому что раньше машина не обладает информацией, нужной для принятия решения.
- может быть объявлен код, который будет выполняться, если алгоритм выбора из предыдущего пункта не нашел код (метод
doesNotUnderstand)
Где я не прав/что важное я забыл?
вся суть ООП заключена в связке объект-сообщение. [...] Я давал ссылку на подробное разъяснение Кэя по этому поводу
Дайте, пожалуйста, эту ссылку еще раз, чтобы не получилось так, что мы с вами говорим о разных ссылках.
chaetal
12.08.2016 15:00Alan Kay On Messaging
Там и про сообщения и про развитие заодно.
… из которого следует, что это определение — и есть идеи. Нет?
Нет. Есть проблема. Есть подход к ее решению (то, что я назвал идеями). Про них — целая книга… и не только она. Есть реализация этих идей на «духовном» и «материальном» уровне: разработанная концепция ООП и Smalltalk.
Где я не прав/что важное я забыл?
То, что сразу бросается в глаза:
сообщения определяются именем
Не понимаю, что имеется ввиду. Сообщение — это объект(!), включающий в себя имя и набор параметров. Может быть два сообщения с одинаковыми именами, но с разными значениями параметров. Так что, скорее, нет.
первичный выбор кода, вызываемого в ответ на сообщение, выполняется виртуальной машиной по имени сообщения (и адресату, конечно).
Вас интересуют нюансы реализации? Да, непосредственно передача сообщения объекту в Smalltalk-80 реализована в виртуалке — дань производительности и некоторым сложностям с реализацией. Но семантика (с точки зрения пользователя) проста: за обработку сообщения отвечает объект.
В Smalltalk-е есть еще целый ряд похожих отступлений от концепции по аналогичным мотивам. …А можно еще вспомнить, что уровнем ниже все это работает на процессоре и ни о каких объектах вообще речи нет.
В целом, зачем нужны все эти детали в нашем обсуждении — не ясно. Если только вы не продолжаете игры в софистику. И если ваш план состоит в том, чтобы «дискредитировать» мои слова, зафиксировав Smalltalk-овскую реализацию и объявив любую другую необъектной, то не стоит усилий — я на это уже ответил.
Если же есть настоящее желание понять, то гораздо важнее обсудить подход/идеи, приведшие к созданию ООП. Хотя там все еще менее однозначно и более спорно, чем с определением.lair
12.08.2016 15:21Alan 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, и может использовать ее для более раннего связывания.
Нет, не так?
chaetal
12.08.2016 16:41-1Как все банально! Придираться к словам и не замечать ненужное. Потихоньку начинает утомлять, но я пока еще потерплю.
Есть маленькая проблема: нигде в этом сообщении не сказано, что оно про ООП.
Ну, да когда речь идет про OOPSLA, Smalltalk, Squeak в письме в группу того же Squeak — при чем здесь ООП?!
Мы условились использовать ее для иллюстрации идей, а не того, как должна быть реализована объектная система. Я на это ваше внимание уже обращал, даже вроде бы (лень перечитывать) неоднократно.Вас интересуют нюансы реализации?
Конечно. Мы же условились, что мы используем ее как образцовую.
По поводу связывания по имени — не стоило стараться какими-то хитро-вывернутыми путями получать от меня подтверждение: даже если я это еще не писал здесь (вроде бы даже писал), все равно никакого секрета в этом нет. Другого способа пока как-то не изобрели, насколько я знаю.
За обработку — да. А за выбор, что обрабатывает — внезапно, не объект. Потому что, если в объекте нет соответствующих методов, он даже не получит управления.
Объект не может отвечат за выбор «что обрабатывать» — что прислали, то и обрабатывает. И если нет соответствующих методов, то объект все равно получит сообщение — как аргумент в #doesNotUnderstand:.
Чтобы создать определение того, что же такое «прием-передача сообщения».
Вам все еще недостаточно источников? Ну, посмотрите здесь. Там много всякого написано, из-за чего может разгореться ни один флейм, но про сообщения, вроде, адекватно.
Давайте, сравнения ради, посмотрим на «вызов метода» в каком-нибудь C#. <…>
Зачем?! :D Вы затеяли весь этот некороткий обмен сообщениями ради того, чтобы поймать меня на противопоставлении «посылки сообщений» и «вызова метода»?! Вынужден разочаровать, я достаточно представляю, как реализованы «виртуальные методы» в C++ (5 лет разработки на нем), методы C# (всего пару лет), Java (даже не хочется считать) и т.д., чтобы не утверждать, что там нет посылки сообщений. Конечно есть, иначе сложно было бы называть их объектно-ориентированными. А вот называть посылку сообщения вызовом метода — некорректно. Когда это делают мои коллеги (иногда даже я сам) при обсуждении каких-нибудь повседневных программистких проблем, на это никто не обращает внимания. Но если так начинают высказываться участники дискуссии об ООП, это граничит с невежеством.
Потому что человек не понимает, чем ООП отличается от «остального». Разбиение системы на компоненты, объединение в компоненте кода с данными… что там еще? Все это было до. Не было наследования (хотя, как же! было, к примеру, в Simula-67…и это, заметьте, на тот момент почему-то не стало поводом для создания новой парадигмы), но классы (а следовательно, и наследование) не являются обязательным атрибутом объектной системы. Так что это тоже не является отличием. А что является?
Похоже, к данному моменту я таки исчерпал лимит терпения. Можете считать себя победившим в споре, если в этом состояла цель. На массу интересных вопросов мы так и не вышли, но я честно старался.
lair
12.08.2016 16:52Ну, да когда речь идет про OOPSLA, Smalltalk, Squeak в письме в группу того же Squeak — при чем здесь ООП?!
При чем угодно или ни при чем вообще. Но скорее всего речь идет о дизайне языка, а не об ООП как о парадигме. Но, повторюсь, поскольку в оригинальном письме вся борода цитат вырезана, мы не знаем, на что отвечает Кэй.
Вам все еще недостаточно источников? Ну, посмотрите здесь
Угу. Вот только там столько разных вариантов, что понять, о каком именно говорит Кэй — нельзя. А между, скажем, синхронной и асинхронной передачей разница фундаментальная.
Зачем?
Чтобы найти отличия, если они есть.
Конечно есть [посылка сообщения в C++, C# и Java], иначе сложно было бы называть их объектно-ориентированными
Прекрасно, значит по этому пункту эти языки попадают под определение Кэя. Несложно увидеть, что, скажем, C# попадает и под остальные (кроме шестого, но про него я уже один раз написал). Так? Или есть возражения?
А что является?
Вот и мне интересно.
chaetal
12.08.2016 18:01-1В C# далеко не все является объектом.
Я уже выразил свое разочарование данной беседой. Если есть что сказать по существу — говорите.lair
12.08.2016 18:05В C# далеко не все является объектом.
И что же не является объектом в C#? Иными словами, чему я не могу послать сообщение?
chaetal
12.08.2016 18:09Например, сообщению.
lair
12.08.2016 18:12Ой ли?
Когда вы имеете дело с сообщением (например, внутри
TryInvokeMember) вам ничего не мешает посылать сообщения сочетанию биндера и аргументов.chaetal
12.08.2016 18:14Что за объект «сочетание биндера и аргументов»?
lair
12.08.2016 18:19new Message(invokeMemberBinder, args)chaetal
12.08.2016 18:22это не объект, это два объекта, не так ли?
lair
12.08.2016 18:24Результат выражения — один объект. Ну и да, в языке, где любая коллекция и любой тупл — объект, любое сочетание объектов есть объект.
chaetal
12.08.2016 18:26-1Пошлите сообщение объекту-сочетанию биндера и аргументов.
lair
12.08.2016 18:34new {invokeMemberBinder, args}.ToString()chaetal
12.08.2016 18:37«Это не тот объект, который вы ищите». Не надо фокусов. Я прошу объект сообщение, а не тупо Tuple.
lair
12.08.2016 18:41А это и не
Tuple. Впрочем, пример объекта-сообщения был выше:
new Message(invokeMemberBinder, args).Equals(smth)chaetal
12.08.2016 18:45…и откуда он взялся?
lair
12.08.2016 18:46Я его написал.
chaetal
12.08.2016 18:49Третий раз: не надо фокусов. Возможность обернуть объект вокруг чего-то не делает это что-то объектом.
lair
12.08.2016 18:50Вы хотите сказать, что
invokeMemberBinderи/илиargsне являются объектами? А если быTryInvokeMemberполучал в себя готовыйmessageситуация бы изменилась?
chaetal
12.08.2016 18:25if(x==null)
{
x= 101;
}
Код в {} является объектом?lair
12.08.2016 18:26Когда вы работаете с AST — да.
chaetal
12.08.2016 18:32-1…А когда я не работаю с AST?
lair
12.08.2016 18:34А когда вы не работаете с AST, то зависит от того, с чем вы работаете, потому что если вы открыли этот код в текстовом редакторе, то он просто набор текста. Но если вы работаете с кодом программно из C#, то вы в любом случае будете иметь дело с объектом — будь то объект строки или объект AST.
chaetal
12.08.2016 18:36В те времена, когда я работал на C#, базовые типы, пока их не обернешь в объект, объектами не являлись? Что-то изменилось?
А что там насчет указателей?lair
12.08.2016 18:42В те времена, когда я работал на C#, базовые типы, пока их не обернешь в объект, объектами не являлись? Что-то изменилось?
Console.WriteLine(5.CompareTo(3))
Всегда работало, кстати.
А что там насчет указателей?
А указатели — это небезопасный код, который является расширенными возможностями.
chaetal
12.08.2016 18:47Еще раз: не надо фокусов. Взять необъектный базовый тип и создать над ним объект — не велика наука. Но это не делает исходное число объектом.
То есть, указатели — не объекты?lair
12.08.2016 18:54Взять необъектный базовый тип и создать над ним объект — не велика наука. Но это не делает исходное число объектом.
(Расскажите это Smalltalk с его реализацией
SmallInteger)
С точки зрения пользователя, число имеет тип
System.Int32, который унаследован отSystem.Object. В любом месте, где используетсяobject, можно использовать число. По каким именно — поведенческим! — признакам вы отличаете "необъектный базовый" тип от всех остальных?
То есть, указатели — не объекты?
Указатели — это хак, который не входит в объектную парадигму C# (и CLI вообще).
chaetal
12.08.2016 18:56Я написал:
int v = 101;
Какое сообщение я могу отправить v?lair
12.08.2016 19:07Любое, поддерживаемое типом
System.Int32.
> int v = 101; > Console.WriteLine(v.ToString("N")); 101,00chaetal
12.08.2016 19:39-1Это сообщения объекту, который будет создан над значением, содержащемся в v. v останется не-объектом. Язык допускает использование не-объектов. Но это все не принципиально — я только что ответил на исходное послание.
lair
12.08.2016 20:41v останется не-объектом.
Как вы определите, что это "не-объект" по внешним признакам?
chaetal
12.08.2016 19:37Напомните, какие методы поддерживает null и покончим с этим.
Поразмыслив, я понял, что зря упираюсь. Допустим мне удасться найти какие-то моменты, не покрытые в виртуалке соответсвующим хуками. Или я смогу найти нестыковки в языке, допускающие использование не-объектов. Очевидно, все это не носит принципиального характера: архитектуру виртуалки можно пофиксить, в язык добавить еще пару тонн сахара и гордо заявить о «чистом объектном языке». От этого потягивает каким-то душком, но я готов заткнуть нос и согласиться. Что дальше?lair
12.08.2016 20:40Напомните, какие методы поддерживает null и покончим с этим.
Никакие, но это не значит, что ему нельзя послать сообщение.
Что дальше?
А дальше выясняется, что (как минимум некоторые; мы вот увидели на примере C#, но это не потому, что другие хуже, а потому, что я их плохо знаю) современные ОО-языки вполне удовлетворяют правилам Кэя. Возникает вопрос: а что же это за "современная версия ООП" "рассыпается"?
chaetal
12.08.2016 21:01-1Никакие, но это не значит, что ему нельзя послать сообщение.
Это как же?! Покажите, пожалуйста, пример посылки сообщения этому «объекту». И заодно (раз уж у нас ООП на классах) поясните, какого класса экземпляром он является.
Возникает вопрос: а что же это за «современная версия ООП» «рассыпается»?
Что за современная версия — я уже не раз писал и здесь, и в комментах к других статьям по теме. Подозреваю, что с логично назревающим вопросом «как именно она рассыпается» такими темпами с вами мы будем разбираться еще полгода. Увольте.lair
12.08.2016 21:20Это как же?! Покажите, пожалуйста, пример посылки сообщения этому «объекту».
string q = null; q.Substring(1);
И заодно (раз уж у нас ООП на классах) поясните, какого класса экземпляром он является.
В моем примере —
string.
Что за современная версия — я уже не раз писал и здесь
Ну тогда я думаю, вас не затруднит коротенько повторить.
chaetal
12.08.2016 22:35-1Ошибаетесь
lair
12.08.2016 22:38Очень аргументировано, да. Впрочем, с "современным ООП" то же самое — я в этом посте не нашел ни одного данного вами объяснения ни о том, что это такое, ни о том, почему оно "рассыпается".
chaetal
12.08.2016 23:12У вас настолько же «аргументированных» ответов, пожалуй побольше, да.
Плохо искали. Даже в этой ветке были отсылки. Только не я вводил это понятие.
Соответственно, если есть желание продолжать — вам и карты в руки. Ведь это же вы, если не ошибаюсь, говорили за индустрию, за развитие понятия ООП и т.п. (причем не раз и не только здесь)? С устаревшим мы, вроде как разобрались, верно? Самое время вам изложить продвинуто-современное.lair
12.08.2016 23:19Плохо искали. Даже в этой ветке были отсылки. Только не я вводил это понятие.
Вот именно, что не вводили — так что это очень напоминает straw man argument.
С устаревшим мы, вроде как разобрались, верно?
А я что-то говорил про устаревание?
Самое время вам изложить продвинуто-современное.
Внезапно (!) я считаю, что "продвинуто-современное" понятие ООП сводится к тому, что написано в википедии: объединение (семантически связанных) данных и поведения. Из этого весьма несложным образом вытекают инкапсуляция и полиморфизм. Все.
chaetal
12.08.2016 23:33Вот именно, что не вводили — так что это очень напоминает straw man argument.
Вводили другие, я указал на различие. Что-то вам где-то напоминает? Ну, ладно…
А я что-то говорил про устаревание?
А как же? Не ваши слова про то, что было понятие, индустрия изменилась, понятие — тоже. Риторический вопрос: что стало с исходным понятием?
Внезапно (!) я считаю, что «продвинуто-современное» понятие ООП сводится к тому, что написано в википедии: объединение (семантически связанных) данных и поведения.
То есть, абстрактный тип данных? Или в чем отличие?
Кстати, не совсем понятно, как это определение соотносится с теми 6-ю пунктами? Если про устаревание речи не было, то они должны быть эквивалентны, не так ли?
Из этого весьма несложным образом вытекают инкапсуляция и полиморфизм.
Хотелось бы услышать, как из совокупления данных и поведения рождается для начала полиморфизм? Кстати, было бы неплохо уточнить, что это такое. И что такое инкапсуляция, если она «вытекает» из этого, а не является этим.
lair
13.08.2016 00:05То есть, абстрактный тип данных? Или в чем отличие?
Зависит от того, как вы понимаете термин "поведение".
Кстати, не совсем понятно, как это определение соотносится с теми 6-ю пунктами?
Оно шире, чем те 6 пунктов.
Хотелось бы услышать, как из совокупления данных и поведения рождается для начала полиморфизм?
Полиморфизм — в данном случае — это возможность совершать одни и те же операции над разными объектами. Проистекает она как раз из того, что объект предоставляет операции наружу, и можно ими пользоваться вне зависимости от того, что внутри.
И что такое инкапсуляция, если она «вытекает» из этого, а не является этим.
Инкапсуляция — опять-таки, в данном контексте — это сокрытие информации о внутреннем устройстве объекта, заменяя ее внешним интерфейсом.
chaetal
13.08.2016 09:13Оно шире, чем те 6 пунктов.
Что именно добавлено? Или наоборот убрано? Вы ведь можете конкретизировать мысль, а то даже не ясно в каком смысле оно «шире»: там больше ограничений и, соответственно, меньшее количество систем подпадает под это определение? Или наоборот?
Полиморфизм — в данном случае — это возможность совершать одни и те же операции над разными объектами. Проистекает она как раз из того, что объект предоставляет операции наружу, и можно ими пользоваться вне зависимости от того, что внутри
Операции над объектами? Что такое операции над объектами — не припомню, чтобы вы их упоминали…
И поясните процесс проистекания, а то я теряюсь в догадках. Вот создал я объект класса Integer, в котором есть операция умножения. А потом создал экземпляр класса String, где эта операция не объявлена. Теперь я могу второй объект умножать??
Инкапсуляция — опять-таки, в данном контексте — это сокрытие информации о внутреннем устройстве объекта, заменяя ее внешним интерфейсом.
Поясните слово сокрытие? А то вот все говорят «сокрытие», а потом объявляют поля как public… И вот снова незнакомое слово — интерфейс. Что это? Меня терзают смутные сомнения: не надо ли добавить его в определение?
Зависит от того, как вы понимаете термин «поведение».
То есть ваше понимание зависит от моего? Другими словами, своей позиции вы не имеете, а ваши предыдущие слова про согласие с современной трактовкой следует понимать как «я не знаю, но согласен с толпой», верно?
Вот тут есть рассуждение Уильяма Кука по поводу этих различий. Не буду врать, что я его уже прочитал и полностью понял, но хочу поделиться заранее.
И это вроде как подтверждает мою догадку?lair
13.08.2016 12:22Что именно добавлено? Или наоборот убрано?
Убрано. Нет необходимости в классах, нет обязательных сообщений.
Операции над объектами? Что такое операции над объектами — не припомню, чтобы вы их упоминали…
Это то самое "поведение", которое было упомянуто изначально.
И поясните процесс проистекания, а то я теряюсь в догадках. Вот создал я объект класса Integer, в котором есть операция умножения. А потом создал экземпляр класса String, где эта операция не объявлена. Теперь я могу второй объект умножать??
Нет. Но если вы создали объект, описывающий целое число, и объявили на нем операцию умножения, а потом создали объект, описывающий дробное число, и объявили на нем операцию умножения, то третий объект, желающий сделать возведение в степень, может сделать это для обоих этих объектов.
Поясните слово сокрытие?
Трактуйте его дословно: сокрытие избыточной (нерелевантной) информации от потребителя.
А то вот все говорят «сокрытие», а потом объявляют поля как public…
Это проблема кривой реализации, от нее вы не денетесь никуда.
И вот снова незнакомое слово — интерфейс. Что это?
Правильнее было бы сказать "контракт" (в Майеровском смысле), совокупность договоренностей о поведении объекта.
Меня терзают смутные сомнения: не надо ли добавить его в определение?
Нет, не надо. Контракт всего лишь вырастает как дизайн-практика, он не является обязательным свойством объектно-ориентированного программирования (хотя, несомненно, любой объект обладает контрактом, другое дело, что если мы не формализуем это понятие, оно нам и не нужно).
То есть ваше понимание зависит от моего? Другими словами, своей позиции вы не имеете, а ваши предыдущие слова про согласие с современной трактовкой следует понимать как «я не знаю, но согласен с толпой», верно?
Нет, неверно. Я просто не настолько хорошо знаком с теорией ADT, чтобы аргументированно здесь отвечать.
И это вроде как подтверждает мою догадку?
Наоборот. Там написано следующее: "Objects and abstract data types are not the same thing, and neither one is a variation of the other." Мне пока не хватило усидчивости, чтобы проследить за всем рассуждением.
chaetal
13.08.2016 15:17Убрано. Нет необходимости в классах, нет обязательных сообщений.
Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
А сообщения мы убрали — зафиксировано.
Это то самое «поведение», которое было упомянуто изначально.
Упомянуто — не значит определено. Что такое операция/поведение? Как этим пользоваться?
Трактуйте его дословно: сокрытие избыточной (нерелевантной) информации от потребителя.
Я не понимаю. Кто является потребителем? Какая информация является для него избыточной (нерелевантной)? Кто это решает? Как осуществляется это самое сокрытие?
Это проблема кривой реализации, от нее вы не денетесь никуда.
По слухам, в реализации акторной модели Erlang-а к данным объекта из других объектов на самом деле нет никакого доступа. Не уверен, что это так, но если да — ваша инкапсуляция ведь не об этом?
Правильнее было бы сказать «контракт» (в Майеровском смысле), совокупность договоренностей о поведении объекта.<…> оно нам и не нужно
Ну, хорошо — пусть контракт. Это понятие должно же войти в определение ООП, раз вы на него ссылаетесь? А если оно не нужно, почему вам пришлось его упоминать? Давайте тогда откатываться назад и еще раз: что такое инкапсуляция (без упоминаний интерфейсов/контрактов)?
«Objects and abstract data types are not the same thing, and neither one is a variation of the other.»
Ну, а как же тут быть? Мы обсуждаем некий новый термин — ООП. Вы же не опровергаете необходимость его существования? Значит, должны понимать, что он добавляет к уже существующим? Отложим этот вопрос?
lair
13.08.2016 15:38Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
Это, на самом деле, некие домыслы. Их можно "вычитать" из книжки, но напрямую это там не сказано.
Упомянуто — не значит определено. Что такое операция/поведение?
Операция/поведение — это, буквально, то, что понимается под этими словами. Что-то, что можно сделать с объектом (например, сохранить).
Как этим пользоваться?
Implementation defined. Где-то это методы, где-то это сообщения — это не принципиально.
Кто является потребителем?
Любой, кто пользуется объектом (находясь на том же уровне абстракции, конечно — поэтому среда выполнения не является потребителем).
Какая информация является для него избыточной (нерелевантной)?
Это определяется решаемой задачей.
Кто это решает?
Разработчик объекта.
Как осуществляется это самое сокрытие?
Implementation-defined.
По слухам, в реализации акторной модели Erlang-а к данным объекта из других объектов на самом деле нет никакого доступа.
Это не так. Если объект сам решит предоставить свои данные наружу, доступ к ним будет. Public field — это то же самое.
Это понятие должно же войти в определение ООП, раз вы на него ссылаетесь?
Нет, не должно.
А если оно не нужно, почему вам пришлось его упоминать?
Потому что разъяснения вполне могут опираться на понятия, существующие за пределами парадигмы.
Давайте тогда откатываться назад и еще раз: что такое инкапсуляция (без упоминаний интерфейсов/контрактов)?
Сокрытие избыточной информации.
Значит, должны понимать, что он добавляет к уже существующим?
Начнем с того, что спрашивать, что термин "(какое-то) программирование" добавляет к термину "(какой-то) тип" — достаточно нелепо, не так ли? Есть люди, которые считают, что объектно-ориентированное программирование можно называть программированием на ADT, есть люди, которые так не считают. Я отношусь ко вторым, потому что (а) я считаю, что ADT — термин из другого уровня абстракции и (б) я считаю, что понятие "поведения" в ADT отличается от понятия "поведение" в объектах; но, к сожалению, я не могу это отличие вербализовать и формализовать. Иными словами, мое мнение о том, что ADT не идентичны объектам интуитивно, и собственных аргументов в его пользу у меня нет — однако, я нашел статью, которая это мнение подтверждает (как, впрочем, и википедия).
chaetal
13.08.2016 17:17
Ну, куда уж прямее (и я уже указывал на это место): The first three principles are what objects «are about»—how they are seen and used from «the outside.» These did not require any modification over the years. The last three—objects from the inside—were tinkered with in every version of Smalltalk (and in subsequent OOP designs).Я уже обращал ваше внимание, что только первые три пункта определения Кэя относятся к ООП (являются обязательными), а оставшиеся три — описывают детали реализации Smalltalk-а (то есть, не обязательны).
Это, на самом деле, некие домыслы. Их можно «вычитать» из книжки, но напрямую это там не сказано.lair
13.08.2016 17:28Неа. Там всего лишь сказано, что первые три принципа со временем менять не понадобилось, а с оставшимися тремя продолжали играть в каждой реализации.
chaetal
13.08.2016 17:55Вы издеваетесь?
The first three principles are what objects «are about»—how they are seen and used from «the outside.»
lair
13.08.2016 18:04Нет, я не издеваюсь. Я же говорю — это фраза, в которой можно прочитать что угодно, было бы желание. Дословный перевод абзаца (чтобы был виден контекст):
К этому времени [~1972-1973] бОльшая часть схем Smalltalk была сведена к шести основным идеям, которые соответствовали основным посылкам в дизайне интерпретатора. Первые три принципа говорят, "что такое" объекты — как они воспринимаются и используются "снаружи". В последующие годы их менять не понадобилось. Последние три — объекты изнутри — подкручивались в каждой версии Smalltalk (и в последующих OOP-проектах).
Но самое важное, что это же не имеет значения: мы все равно перешли от Кэевского определения к "моему".
chaetal
14.08.2016 18:26Первые три принципа говорят, «что такое» объекты
И как же вы «прочитаете» эту фразу?
Но самое важное, что это же не имеет значения: мы все равно перешли от Кэевского определения к «моему».
Кто «мы» и что значит перешли? Перешли к обсуждению ваших попыток что-то сформулировать про ООП — да. Но от этого исходное определение не становится менее важным. Меня лично интересует соотношение идей, рожденных в 70-е, и «современное» их «развитие». Я вот никак не могу уловить, что же улучшилось.lair
14.08.2016 20:45И как же вы «прочитаете» эту фразу?
Дословно: в ней описывается, как объекты выглядят "снаружи", т.е., по воспринимаемому поведению.
Меня лично интересует соотношение идей, рожденных в 70-е, и «современное» их «развитие». Я вот никак не могу уловить, что же улучшилось.
А почему вы думаете, что развитие идеи — это обязательно ее улучшение? Это может быть уточнение, или обобщение, или создание методологии, или создание производных — и так до бесконечности.
chaetal
14.08.2016 21:43А почему вы думаете, что развитие идеи — это обязательно ее улучшение?
Так, развитие может быть связано с ухудшением или «неизменением»? Все, вопрос закрыт! Это как нельзя точно характеризует «современное» определение ООП — ровно то, что я и хотел изначально сказать.lair
14.08.2016 21:46Так, развитие может быть связано с ухудшением или «неизменением»?
С ухудшением — нет. А как можно развивать идею, не "улучшая" ее — я выше привел много примеров.
chaetal
13.08.2016 18:11Начнем с того, что спрашивать, что термин "(какое-то) программирование" добавляет к термину "(какой-то) тип" — достаточно нелепо, не так ли?
Нелепо плодить синонимы. Если термин появился и был признан, значит он что-то добавил к тому набору терминов, которые были до него.
Но я так не понял, вы в состоянии дать «замкнутое» определение ООП? Такое, чтобы без отсылок к сущностям, которые не входят в определение, а определяются через третьи сущности, которые тоже не входят и т.д.? А то у вас получается «короткое определение», но куда ни ткни — они объясняются через какие-то новые понятия. Сформулируйте, пожалуйста, хотя бы на уровне тех 3+3 пунктов что же такое ООП, из которых будет понятно, чем оно отличается от не-ООП. А то по кругу ходить надоело уже.lair
13.08.2016 18:21Нелепо плодить синонимы.
Так это и не синонимы. Программирование (любое) не может быть синонимом типа (любого).
Но я так не понял, вы в состоянии дать «замкнутое» определение ООП? Такое, чтобы без отсылок к сущностям, которые не входят в определение, а определяются через третьи сущности, которые тоже не входят и т.д.?
Конечно, не в состоянии. И никто не в состоянии.
Сформулируйте, пожалуйста, хотя бы на уровне тех 3+3 пунктов что же такое ООП, из которых будет понятно, чем оно отличается от не-ООП. А то по кругу ходить надоело уже.
Я, вроде бы, уже сформулировал: объединение (семантически связанных) данных и поведения. В не-ООП (семантически связанные) данные и поведение находятся в разных сущностях; в ООП — в одной (эта сущность и называется объектом). В идеальной реализации объект устроен таким образом, что только он (=его разработчик) определяет, какие части его поведения и/или данных доступны его пользователям (другим объектам).
chaetal
14.08.2016 18:38-1Так это и не синонимы. Программирование (любое) не может быть синонимом типа (любого).
Если вы не в состоянии объяснить, чем термин A отличается от термина B, то эти термины — синонимы.
Возвращаясь к конкретике: в каком-нибудь до-объектном языке (ну, скажем, C) есть тип int; есть набор операций, которые вы можете выполнять над значениями этого типа. Чем это не объект по вашему определению?
Скорее всего, вы возразите, что тут данные и поведение находятся в разных сущностях. Я спрошу: в каких? И мы уйдем в долгий и нудный цикл софистики.
Но можно этого не делать, а вспомнить, что в том же «чистом»(необъектном) C (или таком же Pascal) можно создать модуль: сложить данные и процедуры вместе. Тут уже сомнение о их совместном расположении быть не может. Так что мы получили объект, соответствующий вашему определению. Нет?lair
14.08.2016 20:51Если вы не в состоянии объяснить, чем термин A отличается от термина B, то эти термины — синонимы.
Вам правда надо объяснять, чем тип отличается от программирования? Тип — это сущность, программирование — процесс.
Чем это не объект по вашему определению?
Вы сами ответили на этот вопрос.
Но можно этого не делать, а вспомнить, что в том же «чистом»(необъектном) C (или таком же Pascal) можно создать модуль: сложить данные и процедуры вместе. Тут уже сомнение о их совместном расположении быть не может. Так что мы получили объект, соответствующий вашему определению. Нет?
А это зависит от того, какие данные и какие процедуры мы сложили вместе. Предположим, нам надо (=у нас есть бизнес-задача) вести учет моих домашних финансов. У нас есть модуль "мои деньги", в котором определены процедуры "приход" (дата и сумма), "расход" (дата и сумма) и "баланс" (возвращает сумму). Если дизайн модуля таков, что все общение с ним происходит через эти процедуры, то да, мы — соласно моему определению — получили объект. Дальше, правда, у нас есть/могут быть проблемы. Например, не очень понятно, как, сохранив этот дизайн, получить учет раздельно моих финансов и семейных финансов. Или, скажем, не очень понятно — хотя вот тут это частично вызвано моим незнанием возможностей Паскаля/Си — насколько легко/сложно пользователю этого модуля обойти эти процедуры и начать напрямую оперировать данными объекта (в этот момент объект "лопнет").
geher
10.08.2016 20:43+1> Можно заходить на очередной круг с вопросом о том, что внутреннее состояние + интерфейс взаимодействия — это не ООП (хотя бы потому, что какой-нибудь паскалевский модуль вполне удовлетворяет этому определению)
внутреннее состояние + интерфейс взаимодействия — это совсем не ООП. Это всего лишь характеристики единицы, с которой оперирует ООП, т.е. объекта.
То, что «паскалевский модуль вполне удовлетворяет», всего лишь означает, что паскалевский модуль может использоваться в качестве инструмента для описания поведения объекта, изменения его состояния и его реакций на внешний мир.
А ООП — это построение программы как описания взаимодействия таких объектов.
В отличие, например, от классического описания последовательности действий.
geher
10.08.2016 20:34+1Если под «современным» пониманием ООП понимать классы, наследование, инкапсуляцию и прочее подобное, то это, конечно муть.
Все перечисленное — всего лишь инструменты для написания ОО программ. Инструменты не идеальные, но какие есть. И с их помощью вполне можно писать ОО программы.
Да, это не так удобно, как в некоторых других языках, больше возможностей для ошибок, но вполне возможно. В конце концов, ООП — всего лишь парадигма построения программы, а не конкретный набор инструментов. А инструменты можно и самому нарисовать.
И должен заметить, что идеального ОО языка просто не существует. У всех какие-то дополнительные заморочки, осложняющие построение модели мира из взаимодействующих объектов.symbix
10.08.2016 21:32Идеального языка можно ждать до пенсии. :)
Пишем на том, что есть, ничего ж страшного, недостатки и способы их компенсировать или обойти известны.
Dimonkov
08.08.2016 19:182. Что-то типо ивентов? По типу: был subscriber, отключили, починили, переподписали обратно на ивент.
Так это и на существующих моделях можно реализовать.
Вот только он ведь всё равно не сможет отвечать пока отключен.
Или я что-то не так понял?
chaetal
09.08.2016 21:18Когда «вызывается метод», вызывается конкретный код.
Когда передается сообщение, какой код будет выполнен — заранее неизвестно. Требуется «связать» сообщение с методом. За это отвечает объект, и конкретный код будет выполнен когда сообщение получит конкретный объект в конкретном состоянии. Поэтому тот же Кэй постоянно говорит о позднем связывании.lair
09.08.2016 21:30Когда «вызывается метод», вызывается конкретный код.
Кстати, нет. Позднее связывание на методах тоже встречается, причем больше, чем одного вида.
chaetal
09.08.2016 21:39То, что (неверно) называют вызовом метода (в объектных языках) — это и есть передача сообщения (иначе язык не мог бы претендовать на звание объектного). В процессе обработки сообщения тем или иным методом обеспечивается связывание сообщения с определенным в классе объекта методом, и только затем происходит вызов этого метода.
В мейнстримовых языках это дело хорошо законспирировано, что вводит многих в заблуждение. В Smaltlalk-е разница между сообщением и методом (оба, кстати, являются объектами и объектами разных классов) — максимально ясна и прозрачна.lair
09.08.2016 21:40Вы уверены, что ваше понимание — оно точно правильное, и другого быть не может? Потому как, опять-таки, вся индустрия давно под вызовом метода понимает именно то, что происходит сейчас, со всеми вариантами связывания.
chaetal
09.08.2016 21:52-2А вы уверены, что можете говорить от имени всей индустрии? :)
Ну, расскажите свою версию, и мы убедимся, что она является частным случаем описанного процесса.
Мое понимание основывается на том, что изначально вкладывалось в термин object-oriented programming автором термина. То, что, как вы утверждаете от имени всей индустрии, «эволюционировало» (скорее, деградировало) в современное «понимание» этого термина, а) сложнее, б) является частным случаем исходного определения, в) привело к массе ошибочных выводов о «хорошем объектном дизайне» и в конечном итоге завело эту самую индустрию в очередной тупик с криками «ООП умерло! Нас обманули! Ай-да эволюционировать функциональное программирование!»lair
09.08.2016 21:53А вы уверены, что можете говорить от имени всей индустрии?
Нет.
На этом, пожалуй, закончим, мне этот формат диалога не интересен. К счастью, когда я говорю method call, окружающие меня коллеги понимают меня одинаково.
chaetal
09.08.2016 21:57-3Когда слесарь дядя Вася говорит «берем эту хреновину, кладем на эту загогулину и херачим по ней», окружающие его коллеги тоже понимают его одинаково. И все они очень довольны современным состоянием индустрии. Удачи!
kemiisto
09.08.2016 21:55В мейнстримовых языках это дело хорошо законспирировано, что вводит многих в заблуждение.
Не замечал такого.
В Smaltlalk-е разница между сообщением и методом (оба, кстати, являются объектами и объектами разных классов) — максимально ясна и прозрачна.
А зачем плодить сущности? Всё ясно и прозрачно в мейнстримовых языках, не выдумывайте.chaetal
09.08.2016 22:06В исходном определении ООП есть всего две сущности: объект и сообщение. Реализация его в Smalltalk добавила еще классы, методы …и, на самом деле, еще несколько сущностей — но ни одной такой, какая отсутствовала бы в «современном» определении. А там еще есть инкапсуляция, полиморфизм, абстракция… и еще много действительно лишних сущностей.
Сообщение же лишней сущностью не является, поскольку именно в ней заключен весь смысл понятия «объектно-ориентированное программирование». Что Алан Кэй и все еще пытается донести до «профессионалов» — спустя уже более 40 (±) лет с момента изобретения.
Если же это не так, и «вызов метода» является синонимом «передачи сообщения», то мы немедленно приходим к выводу, что «объектно-ориентированного программирования» не существует. Вызов метода уж точно аналогичен вызову процедуры, а значит все это просто-напросто «программирование на абстрактных типах данных» — незначительное усовершенствование процедурного стиля.
kez
09.08.2016 22:49Исходное != современное
Исходное понятие ООП и современное понятие ООП — не одно и то же.
Выше я уже высказывался, что Алан создал не тот термин, от этого все беды.chaetal
10.08.2016 08:20-2Разумеется! Человек сгенерировал, проработал и воплотил прекрасную идею. Потом ее не поняли, переврали, получили непонятное и страшное нечто, которое никто не понимает и не может объяснить. Зато это СОВРЕМЕННО! (Еще можно приплести индустрию.) И плевать, что из этого нечто рождаются монстры, что все блюют и плачут, что это нечто создает на два порядка больше проблем, чем дает преимуществ. Мы все равно будем называть это нечто не тем термином, ни в коем случае не попробуем понять что же было вначале, будем продолжать пользоваться нашей химерой до тех пор, пока не найдем другой хайп и не начнем насиловать другую идею. Ну, хорошо, если это ваш путь — удачи!
Zenitchik
10.08.2016 12:20+1- Точно воплатил, а не только высказал?
- Такая ли уж она была прекрасная, раз её реализовывать почти никто не захотел?
chaetal
10.08.2016 13:511. Smalltalk
2. См. п.1 + Objective C + Ruby + еще несколько попыток натянуть новую идею на старый манекен. Да и кто вам мешает самостоятельно ее изучить, попробовать и решить для себя?Zenitchik
10.08.2016 15:45+1Да и кто вам мешает самостоятельно ее изучить, попробовать и решить для себя?
Отсутствие потребности. Я пишу на разных языках, от asm-а до js. И каждый раз приспосабливаюсь к языку. Это совсем не трудно, если не пренебрегать чтением спецификации. А абстрактный спор, что называть ООП, меня не настолько занимает, чтобы ради него осваивать ненужный мне язык.
maxxannik
11.08.2016 14:27-2Оказывается это общеизвестно https://habrahabr.ru/post/307354/#comment_9746612
Есть два подтипа ООП.
То за которое нам тут минусы понаставили называется «классно ориентированное». А то которое народу не понравилось называется «компонентно ориентированное».
В общем описали то что давно известно. Но то о чем 99% программистов не знают. И за это получили минуса ))poxu
11.08.2016 14:39+1В той статье, которую вы привели типов ООП не два а три. Третий — прототипно ориентированное программирование, которое в javascript. Класс ориентированный подход и прототипно ориентированный подход это варианты реализации поддержки ООП в языке, а компонентный подход это подход к проектированию систем с использованием ООП.
Всё это действительно давно известно и об этом знают 99% программистов. Теперь вот знаете и вы :)
maxxannik
11.08.2016 14:58-2не надо обманывать и додумывать.
и да, я дописал апдейт к статье где указал что три.
КомпОП — это разновидность ООП. Еще точнее это и есть ООП в изначальной формулировке. То как это видел автор понятия.
КлассОП — это более популярная разновидность. Которая появилась через C++
Что такое КомпОП реально мало кто из программистов знает. Ну я штук 10 опросил. Ни один ничего внятного не сказал. Все про классы говорят. Ну и комменты в этой статье это явно доказывают. Всего 2 или 3 коммента в тему насчитал. Все остальное просто слюни и вода на тему «а мы думаем иначе».poxu
11.08.2016 20:47+1Обратите внимание на то, что классовый и прототипный подход это реализации ООП. Оперирующие конкретными терминами которым соответствуют концепции в языке. Нельзя сделать класс в Ecma Script 5, потому, что там его нет.
Компонентный подход, с другой стороны, реализуется на том, что попадёт в руки. Например на С++.
Если вы считаете написанное в википедии источником истины, то так же обратите внимание, что в англоязычной википедии компонентный подход не является разновидностью ООП, а вот акторный подход, который вам так не понравился — является.
Ну и действительно, поправьте статью. Там как ничего не было про прототипное ООП, так ничего и нет.
chaetal
09.08.2016 21:34По поводу второго пункта. Правильное понимание ООП по этому поводу дает как минимум два возможных решения:
— «NULL» (в Smalltalk-е его называют nil) является полноценным объектом, для которого можно определить требуемое поведение.
— Даже если требуемое поведение таки не определили, это не смертельно. В том же Smalltalk-е при обработке исключения не «разматывается» стек. Поэтому даже необработанное исключение не приводит к аварийному завершению программы. Получив окно с сообщением об ошибке, разработчик может открыть отладчик, найти причину ошибки, исправить ее и продолжить выполнение программы. В сети ходили видики, где подобным образом (не останавливая работу программу) отлаживают, например, веб-приложения и игру «Астероиды».
symbix
08.08.2016 17:28+3Посмотрите на объекты с другой стороны. Не как структуры в программе, а как отдельные программы, общающиеся по какому-то протоколу. Скажем, модные ныне микросервисы (чтобы было больше похоже, пусть там будет не restful API, а json-rpc). Вот примерно такую вещь Алан и имел ввиду.
maxxannik
08.08.2016 17:32Последний абзац перед Резюме в статье, это не тоже самое?
symbix
08.08.2016 17:36+1Почти.
RESTful в его каноничной форме несколько противоречит другому:
«как модули будут общаться друг с другом, а не заботиться об их внутренних свойствах и поведении»
С чтением еще ничего (структуру так или иначе знать надо). А вот запрос вида PATCH /user/ {email: «new@email.com»} вместо сообщения changeUserEmail — это уже завязка на внутренние свойства.
Вот всякие JSON-RPC/XML-RPC с методами, отражающими бизнес-действие — ровно оно.maxxannik
08.08.2016 23:46Я все же склоняюсь к тому что знать API надо. Не надо знать как он работает внутри. На мой взгляд именно это имел ввиду автор ООП.
Скажем RESTfull API JSON может быть написано на php, ruby или asp.net. Причем внутри он может быть написан на голых функциях без классов и наследования глупым джуниором с говнокодом и кучей ошибок. Но при этом если он отрабатывает все запросы ровно и без ошибок — значит все ок. Объект ведет себя правильно и ожидаемо — значит принцип ООП выполнен.
В плагинах WP тот же принцип. Их более 45 000 штук. Из них 80% написаны ужасно. Открываешь код и хочется рыдать. Но при этом если их включить то в целом система работает. Потому что выполнен базовый принцип ООП — продумана логика обмена сообщениями.
Это не защищает от ошибок на 100%. Если в логике допущены жесткие ошибки то система помрет как и любая другая. Но степень антихрупкости у таких систем сильно выше относительно тех в которых нет механики обмена сообщениями. И компоненты внутри могут быть ужасными, но если на межкомпонентном уровне они себя ведут адекватно, то система будет работать. Возможно в этом причина того что под WP так просто написать новый плагин.symbix
09.08.2016 02:56ну в ентерпрайзном ООП то же самое — архитектуру и интерфейсы проектировал белый господин из Калифорнии, а внутри классов там что угодно индусско-китайское, и ладно, главное чтобы тесты проходило
NeoCode
08.08.2016 18:39+2Конечно, если говорить про скриптовые языки и фреймворки на них, то там все как-бы проще — нет компиляции, код очень просто подгружать и даже генерировать/модифицировать во время выполнения, концепция сообщений в том или ином виде присутствует. Я не знаком конкретно с вордпресс, поэтому обобщаю на все скритовое — а почти весь веб именно на скриптовых языках.
Если говорить о С++ — то это «низкоуровневое ООП», или, если можно так сказать — ООП времени компиляции. Да, там вызовы методов вместо отправки сообщений и т.д., но без этого низкого уровня невозможен никакой высокий. Ведь процессору пофиг на ООП; процессор все что умеет — исполнять ассемблерные команды, и, так или иначе, только это и делает — но в потоке команд какие-то относятся непосредственно к решаемой задаче, а какие-то к обслуживанию интерпретатора скриптов, фреймворка и прочих высокоуровневых штук. Какой процент тех и других в среднестатистическом современном коде?
Нет, конечно есть например Objective C, в котором реализованы сообщения. Есть Qt с сигналами и слотами — тоже своеобразные сообщения. Да, там еще нельзя изымать объекты и вставлять их во время работы — но в общем это не так уж и сложно сделать. Главный вопрос — нужно ли это? И при построении архитектуры конкретного приложения как раз и определяется, на каком уровне достаточно старого доброго процедурного программирования, где нужно низкоуровневое ООП, а где — полноценное высокоуровневое, с полностью динамическими объектами и сообщениями.maxxannik
08.08.2016 23:22Вот эту мысль я и ждал. Похожу мы где то на одной частоте мыслим.
Вероятно есть разные типы ООП. Метод классов как в C++ хорош для компиляций и высоких скоростей.
Метод обмена сообщениями хорош для систем с высоким уровнем сложности и необходимостью подключать и отключать компоненты налету. В крупных системах это часто нужная штука. Например у меня много опыта работы с магазинами, агрегаторами и системами управления бизнес-процессами. Всю систему не вырубить на долго. Но добавлять, изменять и отключать компоненты нужно очень часто, почти каждый день.
От куда вы взяли понятие о низком уровне ООП и высоком уровне ООП? Это кем то уже описано? Или личный опыт?
Zifix
09.08.2016 06:26+1Есть Qt с сигналами и слотами — тоже своеобразные сообщения. Да, там еще нельзя изымать объекты и вставлять их во время работы — но в общем это не так уж и сложно сделать.
Connect/Disconnect в рантайме вполне себе работают из коробки.NeoCode
09.08.2016 08:00Речь идет о подключении и отключении «плагинов» во время работы программы. Да, это возможно и на Qt и даже на Си, но поскольку языки слишком низкоуровневые, то это выглядит не как «идеальное ООП», а как нечто весьма навороченное.
Всякие COM-объекты тоже мыслились как чистое ООП в рантайме. Встраивание программ друг в друга, встраивание данных одной программы в данные другой и т.д.
kemiisto
08.08.2016 19:19Какой-то не очень связанный (если не сказать бессвязный) поток мыслей. Объект — совокупность данных и операций над ними. Операции проводятся по получению объектом сообщений от других объектов. Вот, пожалуй, и весь ООП. Сокрытие информации и АТД были и до ООП, в ООП добавилось наследование и динамическое связывание. С помощью этих инструментов появляются доселе невиданные возможности расширения ПО таким образом, которые практически никак не затрагивает уже имеющиеся части программы.
Gitkan
08.08.2016 19:19+1Мне показалось что именно эта платформа подошла ближе всего к понятию ООП. Вероятно по этой причина эта платформа захватила рынок. Стала №1 в мире по ряду показателей.
Когда читал это абсолютно честно думал, что это про Windows с их API построеных на событиях и хуках…maxxannik
08.08.2016 23:27В общем то почему бы и нет? Я плохо знаком с API Windows. Если там есть обмен сообщениями между компонентами, а компоненты можно легко ставить и удалять то близко.
Вот только в отличие от Windows в том же WP зачастую обмен сообщениями сделан глубже. Хотя могу ошибаться. Суть в том что один компонент WP может подменить собой часть другого компонента, какой то мелкий кусок или почти целиком. Например один компонент фомирует страницу по одному шаблону, а мне это не нравиться и я могу написать компонент, который перехватит сообщение и изменит его так что поменят как шаблон вывода, так и состав данных по своему усмотрению. Тем самым достигается возможность глубоких изменений системы на любом этапе жизни.
При этом зачастую если в итоге нужда в такой логике отпала, то мы отключаем компонент и возвращается оригинальная механика которая была до включения.
Windows приложения могут чуть чуть перекрашивать друг друга, но вот они не могут вмешиваться в ход работы друг друга достаточно легко. Либо я могу ошибаться и сейчас такая возможность уже есть.
gsaw
08.08.2016 19:19+1Все ерунда это. Есть принципы проектирования, все остальное крутится вокруг них. ООП, не-ООП все подчиняется им. Я так вообще считаю, что все крутится вокруг loose coupling и high cohesion. Все остальные принципы, типа сокрытия, абстракции, модульности, иерархии, локальности все они производные слабого зацепления. И те же упомянутые объекты, сообщения, модули это всего лишь механизмы для достижения слабого зацепления. Классы это иерархия объектов, ничего больше.
saboteur_kiev
08.08.2016 19:38+1ООП это может и идея, но обсуждают программисты не идею, а конкретную реализацию. На С++, На java, неважно, не обязательно вообще на языках программирования, но уже не концепцию а нюансы реализации.
В IT — объект это в первую очередь данные. Потому что все что есть в IT — это обработка данных.
И в IT данные не могут быть абстрактными — они состоят из конкретных битов/байтов и должны храниться в каком-то формате, и чтобы с этими данными работать, этот формат должен уметь разбирать некий код.
Из этого идет и вывод что такое ООП для ИТ — «Это когда мы берем некие данные, и создаем объект, в котором они хранятся. И внутри этого объекта храним также и методы, которые позволяют с этими данными манипулировать. И только эти методы должны точно знать формат данных.»
Всякие геттеры/сеттеры и вообще принцип, по которому обращаясь к данными внутри объекта мы лезем не в само поле с этими данными, а к методу, которые с ними оперирует — вот этот принцип нам позволяет ВЕСЬ код, который имеет четкое представление о том, в каком виде данные хранятся в объекте, содержать внутри этого же объекта, и назвать его методами.
Этот принцип позволил ООП парадигме удачно наложиться на то, что для создания крупного проекта, который не влазит в голову одного программиста, или влазит но очень долго, — разделить проект на достаточно независимые кусочки-объекты, которые можно раздеребанить на команду программистов, нарисовав UML схему. И в принципе все завертится.
Это касается и поддержки — достаточно не создавать суперклассы, чтобы можно было локализировать проблему в конкретном классе объекта, и не бегать по всему проекту в поисках, где что еще нужно поменять, и один человек сможет в этом классе разобраться за разумное время.
От ООП бОльшего как-бы и не ожидалось.
vintage
09.08.2016 20:02+1Функция конвертации данных из одного формата в другой к какому объекту должна относиться?
saboteur_kiev
10.08.2016 00:08видимо к двум? Одна функция выдает данные своего объекта, другая их сохраняет внутри своего объекта в своем формате.
Или вам вдруг нужно хранить те же данные в разном виде в одном и том же объекте?
vintage
10.08.2016 00:17Одна функция выдает данные своего объекта
В каком формате?
Zenitchik
10.08.2016 00:23В совместимом, очевидно :)
vintage
10.08.2016 00:55И чем в данном случае "совместимый" отличается от "другой"?
Zenitchik
10.08.2016 12:21+1А что мы называем форматом данных? Я подумал, что Вы имеете в виду данные, представленные объектами. Если же Вы имели в виду элементарные типы, то почему бы такой функции не принадлежать глобальному объекту, который сам данные не хранит?
saboteur_kiev
10.08.2016 01:26Вы почитали мой первоначальный комментарий?
Формат данных — это поля, которые хранятся внутри объекта.
Если вам нужно получить эти данные — пишете метод внутри объекта, который вам их выдаст в нужном формате.
Нужны разные — пишете разные методы. И любой внешний объект может запросить данные через геттеры. Но то, как данные хранятся — знают только методы внутри объекта. Поэтому менять их внутренний формат (модернизировать, масштабировать) — несложно. Поменял поля, и подправил методы внутри этого же объекта. А то, что они возвращают наружу — остается как было, совместимость не теряется.
Что же вы хотите сделать — я пока не понимаю.vintage
11.08.2016 09:52-1Есть 100500 различных форматов: DOM0, DOM1, DOM2, JSON, ProtoBuf, Tree…
Вам нужно произвольно конвертировать их друг в друга.
А теперь нужно добавить ещё один формат, например, YAML-OM, чтобы можно было конвертировать и в него и из него.
Через какой промежуточный формат вы предлагаете реализовать конвертер, из DOM0 в YAML-OM?Zenitchik
11.08.2016 13:29+1Демагогию разводить не надо. Если формат данных — это способ их сериализации (именно это Вы и перечислили), то они хранятся в строке либо массиве байтов. Т.е. элементарном типе. Это не объект. Повторяю ещё раз для маргиналов: в объектных языках для преобразования формата таких данных нужно либо использовать методы объекта-библиотеки, который сам данные не хранит, либо оборачивать элементарный тип в объект, и реализовывать преобразование формата уже в его методах.
vintage
11.08.2016 23:53Я перечислил объектные модели.
Zenitchik
12.08.2016 00:57Как бы не так. DOM0, DOM1, DOM2 — это структура, состоящая из объектов. JSON — это формат сериализованных данных. ProtoBuf — двоичный формат данных.
Оба варианта уже рассмотрены выше.vintage
12.08.2016 09:23Ок, DOM0, DOM1, DOM2, JSON-OM, ProtoBuf-OM, Tree-OM. Легче стало?
Zenitchik
12.08.2016 10:21Да. Этот вариант я рассматривал первым. Сериализация, потом десериализация.
vintage
12.08.2016 14:07+1Сериализация во что?
Zenitchik
12.08.2016 14:39В любой строковый или бинарный формат. XML, JSON, ProtoBuf, etc.
vintage
12.08.2016 20:41+1Ок, мы сериализовали DOM0 в XML. И что дальше? Как нам получить JSON?
Zenitchik
15.08.2016 21:18А почему сразу не сериализовать DOM0 в JSON?
vintage
16.08.2016 00:23-1Функция конвертации данных из одного формата в другой к какому объекту должна относиться?
Рекурсия, однако :-)
Zenitchik
16.08.2016 00:45-1И где же она?
Вам реально не очевиден ответ? Всё же уже разжевали, насколько только возможно.
DOM0 — объект. JSON — строка. Так к какому объекту относится метод сериализации?vintage
16.08.2016 01:19JSON — объектная модель прежде всего, а потом уже способ её сериализации.
Zenitchik
16.08.2016 11:20-1Вы определитесь с терминами. Что у Вас объект, а что у Вас строка? Выше Вы предложили другой термин, а теперь обратно? Демагогия, батенька.
Все варианты ответа на Ваш вопрос я уже назвал выше. Для любого мыслимого случая подойдёт один из названных вариантов. Не прикидывайтесь, что не врубаетесь.
vintage
16.08.2016 15:12Ок, DOM0, DOM1, DOM2, JSON-OM, ProtoBuf-OM, Tree-OM. Легче стало?
И снова рекурсия :-)
Zenitchik
16.08.2016 17:33Ох… Ну где же рекурсия-то? В принятой терминологии JSON не тождественен JSON-OM.
DOM0 сериализуется в JSON, или в XML, или любой другой удобный формат. А он в свою очередь десериализуется в JSON-OM. К чему относятся функции — смотри выше.vintage
17.08.2016 13:53Каким образом вы XML десериализуете в JSON?
Zenitchik
17.08.2016 15:11Вы сами-то поняли что написали? Или это Вы опять уклоняетесь от введённой Вами же терминологии, не иначе с софистическими целями?
vintage
17.08.2016 18:10Каким образом вы XML десериализуете в JSON-OM?
Zenitchik
17.08.2016 19:37Таким образом, которым Вам это нужно. Поскольку JSON-OM послабее, чем DOM, придётся ввести какие-то дополнительные соглашения. Какие — это дело разработчика. Вы же хотели преобразовать DOM0 в JSON-OM? Вероятно, Вы уже знаете, какие именно соглашения пригодны для Вашего случая, иначе бы не ставили вопрос о том, где размещать функцию.
vintage
17.08.2016 23:33Вы предлагаете писать по отдельному парсеру XML для каждой целевой объектной модели?
Zenitchik
18.08.2016 00:13Это Вы предлагаете. Напомню, что Вы спрашиваете, к какому объекту должна относиться функция, а не как она должна быть устроена. Значит, наверно, знаете, что хотите сделать.
Zenitchik
10.08.2016 00:20+1Это должны быть две функции: метод исходного объекта, возвращающий сериализованные данные и конструктор нового объекта, десериализующий данные и использующий их для инициализации.
А в чём вообще трудность?vintage
10.08.2016 01:00У вас есть JSON и XML. Во что вы предлагаете "сериализовать" JSON, чтобы конструктор XML смог это десериализовать?
saboteur_kiev
10.08.2016 01:27У нас есть int, char, double.
а JSON это не тип данных, это формат упаковки данных для передачи куда-либо, а не хранения.vintage
11.08.2016 09:54-1int, char, double — не типа данных, а формат упаковки битов.
saboteur_kiev
11.08.2016 13:16+1Мы обсуждаем концепцию ООП или Вашу персональную терминологию?
Ну или покажите ссылку на rfc или IEEE, который подтверждает, что char, int, double это именно формат упаковки битов, а никак не типы данных, чтобы мы поняли что вы говорите про общепринятое толкование.vintage
11.08.2016 23:55saboteur_kiev
12.08.2016 15:41А Вы знаете, что слова «тип» и «данные», в отрыве от ИТ могут означать вообще что угодно?
Тип, это вообще может быть «какой-то мутный типочек»?
А «данные» могут быть «ситуации»?
Если мы обсуждаем тип данных на хабре, в контексте ООП, давайте обсуждать хотя бы «типы данных в программировании», а не в физике или философии.
P.S. Любой спор легко разрешается, если люди пытаются понять друг друга, а не ловят за слово и занимаются софистикой.
lair
16.08.2016 11:36… если уж совсем традиционно делать, то у вас есть конвертер "формат-объект". Т.е., объектное представление в памяти живет само по себе, и может быть [де]сериализовано в/из любого формата. Конвертеры живут вне объекта (чтобы не нарушать SRP) и традиционно называются [де]сериализатор или форматтер.
vadimr
10.08.2016 05:53Справедливо для информационных систем, не всегда справедливо для других типов программ. Например, управляющие программы построены в первую очередь вокруг состояния процессов, а не данных.
robert_ayrapetyan
08.08.2016 20:28+3> Более 25% сайтов в мире и в РФ работает на этой платформе. Это абсолютный мировой рекорд. Думаю многие уже догадались о чем речь :) Это WordPress.
Давайте посмотрим правде в глаза — WP появился в нужное время в нужном месте и дал пользователям то, чего им не хватало, а именно возможность самостоятельно и быстро поднять нечто тривиальное. Типичный сайт на WP — бложек ценных мыслей и заметок (обычно в количестве двух или трех и 0-1 комментарий к ним. При этом, «модульность», расписанная вами в статье, как правило, ограничивалась идущим в комплекте спам-фильтром и прикручиванием какой-нибудь аналитики. Все. Это 99.99% применимости WP в реале.
Теперь, при чем тут ООП — вообще не понятно. Даже если WP был бы написан у ужасном функциональном стиле на каком-нибудь бг-мерзком ПХП, он все равно бы завоевал ту же самую популярность, ибо сила его именно в подаренных возможностях, которые он предоставил в нужное время огромной армии людей (каюсь, сам с ним баловался, а кто из нас не грешил с WP?).
qrck13
08.08.2016 23:58-3Я бы сказал что эта статья опаздала лет так на 10, а то и 15.
Начиная хотя-бы с того, что очень маленький процент текущих программистов реально знает C++ на уровне достаточном для практического применения. В мире сейчас куда больше Java/C#/JS/PHP/итп программистов, которые про C++ слышали только разные страшилки, а сами C++ когда не писали со времен института.
Второй факт — C++ как-бы на месте не стоит, и актуальная тема должна была-бы называться что-то вроде «Все программисты думают что C++ поддерживает ФП, кроме авторов ФП» (впрочем тут проблема в том, что «авторов ФП» многих уже нет в живых). Конечно ФП возможностей в С++ реализована так-же далеко от идеала, но некоторфе ФП мезанизмы в нем есть.
В конечном счете — язык ориентированный на практическое применение не обязан сторого реализовывать ту или иную парадигму программирования. Язык должен просто выполнять возложенную на него задачу, и в своей области применения C++ с этим справляется лучше всех. Если требования применимости на практике требует отказаться от того или иного принципа — то глупо будет, в ушебр производительности и применимости, слепо следовать ООП принципам. В конечном счете — для «академической чистоты» есть свои языки. И для других практических областей — есть более подходящие языки. Никто не будет сейчас писать на C++ то, что можно сделать на C#/Java.maxxannik
09.08.2016 00:14-1Я согласился бы с этим утверждением, если бы понимал ООП так как большинство. Или так как понимал это 5 лет назад.
Но вот беда, я докопался до мыслей автора и теперь понимаю ООП иначе.
В 2011 году я добрался до предела сложности очередной большой и сложной системы. Она просто начала умирать под гнетом функционала и утопать в постоянно меняющихся требованиях. А затраты на ее обслуживание подскочили до небес. Использовал разные платформы, но всегда очень быстро упирался в предел гибкости. В какой то момент система становится на столько хрупкой что уже с трудом поддается изменениям.
И тогда абсолютно случайно наткнулся на WordPress. И обнаружил что там есть возможность играть компонентами. Добавлять их, отключать, менять их логику не трогая внутренности. И я долго не мог понять как эта способность системы называется. И нашел не так много систем с похожим поведением и механикой взаимодействия компонентов (Drupal, Backbone.js и т. д.). И эта особенность помогла преодолеть предел гибкости и позволила создать очень большую и эффективную систему управления относительно крупной федеральной компанией. Аналогов такой системы на рынке не просто найти.
И не так давно все встало по своим местам когда я наткнулся на цитаты Алена Кея. Оказалось что он тоже искал такие решения и исследовал эту специфику систем. И назвал это свойство ООП. Вот только история с C++ и дальнейшим ходом развития событий привела к тому что понятие ООП мутировало и сегодня понимается не так как задумал автор.
Статья лишь об этом. О том что у ООП есть две стороны: та что популярна и та что была задумана изначально. При этом мне лично и для моих задач более полезной и интересной оказалась та что первоначальная.
И об этом статья. Я не против того как ООП понимают большинство. Более того — я даже сам так программирую. Но хотел лишь сказать что есть и другая сторона — другое понимание этого понятия. То как это задумал автор этого понятия изначально.
Ну а то что большинство программистов оказались не способны это понять — это в общем то не особо удивило :)qrck13
09.08.2016 00:42+2> Ну а то что большинство программистов оказались не способны это понять — это в общем то не особо удивило :)
А вы прямо залезли к людям в голову и убедились, что они не способны понять.
> То как это задумал автор этого понятия изначально.
Много людей тешат себя мыслью, что понимают что то лучше других. Это дает им ощущение уникальности множит ЧСВ.
По факту, если вы не видели сложных масштабируемых систем на C++-подобных языках, это не значит что их нет в природе. Просто вам не повезло. Проект на котором я сейчас работаю состоит из более чем 10 тысяч файлов исходного кода, содержит огромное, просто немыслимое, количество различной функциональности, много чего можно динамически подключить или отключить, и при этом все работает весьма неплохо, никаких проблем с поддержкой этого кода и давлением новой функциональности — не имеем. Написано правда в основном на C#, но ничего такого, что нельзя сделать на C++ там нет (разве что C# events нужно будет реализовать вручную).
Так что все возможно, главное нормальная архитектураmaxxannik
09.08.2016 00:56-3вот с C# events не спорю. И я не говорил что на C++ нельзя создать систему с ООП. Скорее всего можно. Только не видел чтобы эти системы были или получили хоть какое-то распространение. И если это так, то значит что то в этих системах не оптимально.
Как только создаются события (хуки, каналы сообщений) и компоненты достаточно гибко начинают обмениваться между собой этими сообщениями, то вот тут мы уже подходим к ООП в изначальном понятии или «ООП как задумывалось».
А пока у нас классы с инкапсуляцией и наследованием то это «ООП как получилось».
И если система эффективна, то она растет, развивается и становится популярной.
А если система хрупка и сложна, то она редка и значит что ее рассматривать не особо интересно. Гораздо интересней рассматривать проблему на примере эффективных и популярных механизмов, доказавших свою адекватность и полезность обществу.
А таковыми являются WP, Drupal, Backbone.js и т д. Только по этой причине я их привел в пример.qrck13
09.08.2016 01:09+1Не в events-ах дело, похожие механизмы легко реализовать и на чистом C++ — см observer pattern. Не говоря уже о Qt Signals, которые по сути тоже самое что events в C#. Events — это просто удобный способ доставить одно и тоже сообщение произвольному числу слушателей.
maxxannik
09.08.2016 01:36Не вижу противоречий с моим сообщением. Не важно как называется метод доставки: events, хук, канал, процесс и т. д. В разных фреймворках метод обмена называется по разному. Суть в том что в понятии ООП автора этот метод крайне важен и является основной ООП.
А в том как ООП было понято авторами C++ и пущено в массы этому моменту не уделено внимание. Все думают только о методах и свойствах класса с наследованием и инкапсуляцией.
В целом это также попадает в область ООП но является пылинкой от того что имел ввиду автор изначально.
Когда система начинает собираться из множества компонентов которые легко включать и отключать и которые могут менять поведение друг друга и всей системы в целом посредством обмена сообщениями — вот тогда система приближается к изначальному значению понятия ООП.
Так ок?lair
09.08.2016 01:44+3А можно, кстати, цитату из Кэя, где он говорит, что "легко включать и отключать" — это свойство ООП? Только именно из Кэя, с указанием контекста.
maxxannik
09.08.2016 02:04-8Вообще можно, но не тебе. Вот именно тебе не дам. Ты мне не нравишься. И не вижу смысла тебе что-либо доказывать.
Если кто-то появится с интересными мыслями и запросит такую инфу, то конечное же предоставлю :)
qrck13
09.08.2016 07:09> Все думают только о методах и свойствах класса с наследованием и инкапсуляцией
Вы видимо опять смогли залезть в головы людям…
Нет, не думают, у вас страенное представление о людях
lair
09.08.2016 00:53+1И обнаружил что там есть возможность играть компонентами. Добавлять их, отключать, менять их логику не трогая внутренности. И я долго не мог понять как эта способность системы называется.
Настраиваемость. Внезапно, да?
maxxannik
09.08.2016 01:11-2Ты очень умный. Мне до тебя не дотянуться. Простейший Календарь в MAC OS имеет настройки. А значит обладает свойством настраиваемости.
Вот только он не обладает способностью к созданию больших и сложных систем посредством объектов (компонентов) которые можно легко менять, добавлять, дописывать и удалять и которые обмениваются между собой сообщениями.
Но это вообще не внезапно, нет. Ты очень умный.lair
09.08.2016 01:22+1И тем не менее это свойство системы называется именно настраиваемостью, и никакого отношения к ООП не имеет.
А про "больше и сложные системы блаблабла с обменом сообщениями" нам долго и упорно рассказывали в SOA, кстати. Там вообще все было строго по перечисленными вам Кэевским пунктам. Значит ли это, что SOA — до сих пор живущая в Кровавом Энтырпрайзе — это высшее воплощение ООП?
maxxannik
09.08.2016 01:25-1сомневаюсь что высшее, но допускаю что оно ближе к изначальному понятию ООП от Алена Кея чем то ООП которое придумали авторы C++.
главное понять что есть две версии понятия ООП далекие друг от друга:
1. ООП где объекты это компоненты больших систем которые обмениваются сообщениями и то что имел ввиду Ален Кей
2. ООП где объекты это классы с свойствами и методами которые придумали авторы C++, назвали это ООП и пустили развитие понятия по параллельному пути эволюции далекому от того что имел ввиду автор
И тебе ближе версия №2. А мне ближе версия №1. И кто из нас прав?
Вот только в отличие от тебя я допускаю обе версии. А ты уперся в версию 2 и пытаешься доказать ее правильность.lair
09.08.2016 01:40… но нет. Я вообще считаю, что между этими "версиями" нет отличия, потому что сообщения конвертируются в методы и обратно, свойства — это те же методы, а данные — это неизбежное внутреннее состояние объекта.
При этом, что характерно, "что придумал Кэй" мне интересно исключительно с исторической точки зрения, потому что на современнный дизайн систем оно не влияет. Потому что сейчас, когда говорят о сообщениях, говорят именно "сообщения" (вместе с шинами и message passing), когда кому-то нужны сервисы — говорят о сервисах, а когда говорят ООП — имеют в виду объединение данных и поведения (обратите внимание, что это не противоречит определению Кэя). Таково современное терминологическое поле, и спорить с ним бессмысленно.
maxxannik
09.08.2016 01:56-4Ну это я уже понял. Не смею мешать считать так.
Оставляю за собой право считать иначе. Думаю это всех устроит :)
actislav
09.08.2016 00:18+16Автор колеса четко сказал кругло каменное, максимум из дерева, а вы тут че, совсем что ли рехнулись, делаете не пойми из чего, да еще и резиной какой-то покрываете, совсем епан… ись, мало того, еще и воздух в это вдуваете, или азот там какой-то, ну нафига я вас спрашиваю? четко же сказано из чего и зачем, продел палку в отверстие и покатил, а вы там шасси какие-то, амортизаторы, оси… нафига это нужно? Вот WP — это колесо как надо, захотел покатил, захотел остановил, а у вас там что, какие-то коробочки, передачи, шестеренки, вот куда это все нужно вообще непонятно, не по канону делаете товарищи!
IIvana
09.08.2016 06:02>а когда говорят ООП — имеют в виду объединение данных и поведения
Ага, и трех китов впридачу. Помню, зашел разговор на тему кто такие растаманы. Ну я только начал про миграцию африканцев на ямайку и растафарианство в историческом контексте, как меня прервали кратким и емким «растаманы — это те, кто курит траву!» )) Автор молодец, хотя под платформой он конечно же описал Эрланг. Автор ООП еще больший молодец, несмотря на «невлияние на современный дизайн систем» (С), он и сейчас без дела не сидит, и если у него с соавторами хорошо выйдет, то потом море потребляторов будут этим пользоваться.
lair
09.08.2016 12:21У этой системы компоненты обмениваются сообщениями друг с другом и таким образом позволяют менять поведение друг друга.
Система изначально содержит в себе каналы сообщений.
Я вот полез в доки на WordPress, и ничего такого там не нашел. Кто-нибудь может показать пример, о чем идет речь?
Slavenin999
09.08.2016 15:07+1Вот читал-читал и думал сейчас будет слово «Erlang» и тут, неожиданно, WP… epic fail…
kashey
10.08.2016 08:06-2ООП очень странный предмет:
— для некоторых языков (тот же PHP, JS) это просто некий архитектурный синтаксический сахар. Возможность.
— для некоторых языков (С++?) это техническая возможность «обойти» статическую типизацию. Привет приведению типов!
У первой группы нет проблемы вызвать любой метод любого обьекта, у второй группы нет выбора. В итоге получается что бывает разный ООП, для разных целей и растет он из разных причин.
Судя по всему Ален Кей не называл ООП ни первое ни второй. Софистика…
DarkEld3r
10.08.2016 11:52Честно говоря, не понимаю какое отношение приведение типов имеет к ООП.
kashey
10.08.2016 12:36Если смотреть на техническую реализацию — ООП породил классы. Классы породили таблицу виртуальных методов. Которая дала возможность работать с классами-наследниками как с классами-родителями.
Что для большинства строго-типизированных языков — основа функционирования различных контейнеров и половины программных интерфейсов.
В том числе потому что эти «программные интерфейсы» на вход получают не реализации неких интерфейсов, а именно наследников базовых классов.
Этот момент сильно зависит от конкретного ЯП, зашит в стиль использования конкретного ЯП. Это норма, фактически словом ООП различные ЯП, архитектуры, школы и подходы и «продают» разные понятия. Насколько я понял — lair в начале этого топика примерно об этом и говорил.
maxxannik
11.08.2016 14:20-2Упс. Оказывается все что я тут описал уже общеизвестно и даже есть в википедии — пруф.
И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование. Другими словами то ООП что часто имеют ввиду это классно-ориентированное и это то что было придумано в C++, а то о котором речь в статье это компонентно-ориентированное и это то что было придумано Аленом Кеем.poxu
11.08.2016 14:33+2Действительно упс. В википедии не про то, что у вас в статье, а COM и CORBA. И вообще про подход к проектированию систем без использования наследования, дабы избежать проблемы хрупкого класса. Реализуется это всё на том же С++ и на той же Джаве без проблем.
maxxannik
11.08.2016 15:02-2Ну конечно про CORBA. А то что WP соответствует принципам архитектуры компонентов которые обмениваются через сообщения и соответствуют всем принципам ООП которые описал автор — да пофиг. Важно что в Википедии написано CORBA, а вот соответствует ли? Да хз, никто не знает, но упираться рогами в ворота будем до последнего.
lair
11.08.2016 15:36А то что WP соответствует принципам архитектуры компонентов которые обмениваются через сообщения и соответствуют всем принципам ООП которые описал автор — да пофиг.
Не "пофиг", а "не доказано".
poxu
11.08.2016 21:02Допустим этому принципу соответствует и CORBA и WP. CORBA это С++. В котором классовый подход. То есть противопоставлять классовый подход и компонентный подход неправильно. Компонентный подход реализуется с помощью классового.
maxxannik
12.08.2016 22:16-1Не могу сказать за CORBA. Не достаточно знаний об этой платформе.
В WordPress механика обмена сообщениями между компонентами (плагинами) реализована посредством хуков. Хуки представляют из себя фильтры и реализованные на их базе экшины. И эта механика основана на функциях. Сам же компонент я могу писать через классы или через функции. Это зависит от моих задач и желаний. Если я пишу что-то простое то пишу функциями. Если что то сложное то использую классы. В первом случае можно сказать что компонентная структура работает целиком на функциях, во втором случае на классах. Это не зависит от понятия компоненто ориентированной разработки, а лишь от моего стиля написания кода.
Потому можно сказать что утверждение «Компонентный подход реализуется с помощью классового» где то может быть правдой, а где то бредом.
Но есть мнение что компонентный подход это следующий этап развития класс-ориентированного программирования или ООП как это чаще понимается. Но если включить мозг и изучить первоисточники, забив на школьные учебники то станет ясно что компонентное программирование это не следующий этап развития, а это вообще корень ООП в изначальном понимании которое было просто извращено программистами по ходу работы.poxu
13.08.2016 14:08+2А почему компонентный подход это следующий этап развития класс-ориентированного программирования, а не прототипно-ориентированного программирования?
lair
11.08.2016 21:04Оказывается все что я тут описал уже общеизвестно и даже есть в википедии [...] И даже то что ООП разделяется на классно-ориентированное и компонентно-ориентированное программирование
Нет там такого. Вот что написано про компоненто-ориентированное программирование:
Компонентное программирование — следующий этап развития ООП
[...]
Компонентно-ориентированное программирование — это своеобразная «надстройка» над ООП, набор правил и ограничений, направленных на построение крупных развивающихся программных систем с большим временем жизни.
А термина "классно-ориентированное" там нет, есть "класс-ориентированное", и оно противопоставляется прототипному (что достаточно логично).
Впрочем, как вам уже сказали, в английской википедии традиционно написано лучше:
Object-oriented programming that uses classes is sometimes called class-based programming, while prototype-based programming does not typically use classes
[...]
Programming paradigms
[...]
- Object-oriented
- Actor-based
- Class-based
- Concurrent
- Prototype-based
И, наконец, про компоненты:
Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.
[...]
Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. [...] Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated componentsmaxxannik
12.08.2016 22:29-1Component-based software engineering (CBSE), also known as component-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.
[...]
Proponents of object-oriented programming (OOP) maintain that software should be written according to a mental model of the actual or imagined objects it represents. [...] Component-based software engineering, by contrast, makes no such assumptions, and instead states that developers should construct software by gluing together prefabricated components
Это хорошее утверждение. Им можно пользоваться в быту. Я с ним согласен.
Единственное что мне в нем не нравиться и что в быту я не говорю в слух, это то что CBD изначально имело имя OOP. Если брать первоисточник и мысль автора. Потом программисты взяли OOP превратили в Class-based, сказали что хай так будет. Просто я за историческую справедливость. И чтобы те кто хают ООП понимали что они хают не отличную идею, а то что из нее вышло благодаря извращению истории.
И конечно же в быту говоря ООП я всегда говорю про class-based, просто потому что бесполезно сопротивляться общепринятым идеям.
Но в уме я всегда понимаю что изначально ООП было хорошей идеей. А идиотизм с class-based возник лишь в ходе истории и слабых умов программистов. Одни умники извратили идею, а другие теперь ее хаят. Так и живем.lair
12.08.2016 22:31Если брать первоисточник и мысль автора.
Вот возьмите первоисточник и процитируйте ту мысль автора, согласно которой component-based development изначально называлось object-oriented programming.
Потом программисты взяли OOP превратили в Class-based [...] А идиотизм с class-based возник лишь в ходе истории и слабых умов программистов.
Вас не смущает, что в первом определении ООП, которое можно найти у Кэя, есть классы?
maxxannik
12.08.2016 22:38-1Я взял и процитировал. Оформил в статью. Мы прямо сейчас ее комментируем. Прикинь? Если интересно, можно перечитать.
Если проблемы с этим то могу специально для тебя тут повторить 3-4 цитаты которые об этом говорят.
При этом я не заметил или не нашел цитат где Ален Кей говорит о том что в его идеи ООП должны быть классы. Есть ссылка?lair
12.08.2016 22:46Я взял и процитировал. Оформил в статью. Мы прямо сейчас ее комментируем.
Ни в одной приведенной цитате нет слова "компонент".
Если проблемы с этим то могу специально для тебя тут повторить 3-4 цитаты которые об этом говорят.
Будьте добры.
При этом я не заметил или не нашел цитат где Ален Кей говорит о том что в его идеи ООП должны быть классы. Есть ссылка?
Есть, конечно:
- Everything is an object
- Objects communicate by sending and receiving messages (in terms of objects)
- Objects have their own memory (in terms of objects)
- Every object is an instance of a class (which must be an object)
- The class holds the shared behavior for its instances (in the form of objects in a program list)
- To eval a program list, control is passed to the first object and the remainder is treated as its message
Пункты 4 и 5.
(что характерно, этот список уже появлялся в комментариях, и да, это самое близкое к формальному Кэевскому определению ООП, что можно найти в верифицируемых источниках)
maxxannik
12.08.2016 23:12Упс. Не туда вставил. Пруф: https://habrahabr.ru/post/307354/#comment_9749676
- Object-oriented
maxxannik
12.08.2016 23:06-1Хорошие цитаты. Интересные :)
Давай предположим что твои ссылки на цитаты верны и мои.
И из этой предпосылки попробуй ответить на вопросы, которые мне не под силу:
1.Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями
Объект это компьютер в сети, которые обменивается сообщением с другим компьютером в сети. Это следует из определения. Причем тут класс?
Я могу объяснить причем тут класс, только уйдя от значения класса в контексте написания кода. У слова класс есть и другие значения.
При этом с позиции CBD это понятие легко объясняется.
2.Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
Вот как ты добавишь или удалишь класс (в понятии class-based) в большой написанно системе за долю секунды? Тебе как минимум надо будет написать методы расширения этого класса или учесть исключения если ты что то удаляешь? И как ты заставишь классы обмениваться сообщениями?
Упс. А ты заметил в этой цитате слово «компонент»? Или я один его вижу?
Опять же если брать во внимание CBD и в качестве примера WP, то там плагины можно реально включать и отключать за долю секунды, меняя логику обмена сообщениями и поведение системы. Скажем было сообщение о списках главного меню в приложении, мы добавили плагин который добавляет новый раздел, он перехватывает сообщение и добавляет в него новый пункт. На лету. За доли секунды. Модуль сломался, мы просто отключили плагин снова за долю секунды и сообщение перестало перехватываться. Одно сообщение может перехватываться 10 модулями и каждый волен дописать в него свою часть. При этом компонент который изначально владеет этим сообщением вообще не в курсе кто там завтра захочет это сообщение поймать и поиграть с ним. Таким образом мы строили систему из 200 различных модулей которая управляла бизнес процессами в компании на 3000 сотрудников. Оооочень большая и сложная система; Модули включали и отключали за доли секунды. Вся система работала именно так как описывал Ален Кей. При этом где то код был написан как class-based, а где то просто функциями, а где то и прототипы были на JS. Там дофига чего было. Но в основе всего был поставлен CBD-принцип или ООП в понятиях Алена Кея.maxxannik
12.08.2016 23:14это такой криво вставленный ответ вот на это https://habrahabr.ru/post/307354/#comment_9749654
lair
12.08.2016 23:26Объект это компьютер в сети, которые обменивается сообщением с другим компьютером в сети. Это следует из определения.
Из какого определения?
Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.
Вот как ты добавишь или удалишь класс (в понятии class-based) в большой написанно системе за долю секунды?
А зачем? Но вообще, конечно, с помощью загрузчика классов.
И как ты заставишь классы обмениваться сообщениями?
Сообщениями обмениваются не классы, а объекты.
Упс. А ты заметил в этой цитате слово «компонент»? Или я один его вижу?
А это цитата из Кэя? Можно первоисточник?
то там плагины можно реально включать и отключать за долю секунды
Готовые и написанные. Не вопрос, в любой нормальной плагинной системе то же самое. И да, это может быть одним из вариантов компонентной разработки, только при чем тут ООП?
меняя логику обмена сообщениями и поведение системы.
Давайте начнем с вопроса "где в WP сообщения".
Но в основе всего был поставлен CBD-принцип или ООП в понятиях Алена Кея.
Я уже привел определение "ООП в понятиях Кэя", которым я пользуюсь. Описанная вами система под него подходит? Или вы пользуетесь другим определением?
BTW, нигде в Кэевском описании (включая Alan Kay on messaging) нет ни слова про перехват сообщений: адресат сообщения всегда определен явно.
maxxannik
12.08.2016 23:32-1Из какого определения?
Из этого:
Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями
у тебя совсем плохо с мышлением?
А это цитата из Кэя? Можно первоисточник?
У меня ощущение что я общаюсь с пнем который научился печатать на клавиатуре.
В первом абзаце я написал что мы исходим из предположения что твои ссылки и мои верны.
Иначе я ровно также могу поставить под сомнение твою ссылку на какую то вики. Ровно также как ты ставишь под сомнение мои ссылки на какие то другие сайты. Перевeду для тех у кого проблемы с умом: любая цитата на сайте не первоисточник, тк первоисточник это живое общение с автором или на худой конец видео с его словами.lair
12.08.2016 23:36Из этого "Я думал об объектах как о живых клетках или как об отдельных компьютерах в сети, которые обмениваются сообщениями"
Это не определение. Это рассказ Кэя о том, как он пришел к своему видению.
В первом абзаце я написал что мы исходим из предположения что твои ссылки и мои верны.
Ссылку-то дайте. Пока что я вижу, что эта фраза ("Компонент в этой системе действительно больше походят на клетки, которые могут добавляться или удаляться за доли секунды. Их десятки тысяч. Из них ты строишь систему. При этом каждая такая клетка может обмениваться сообщениями с другими.") — это элемент авторского текста в посте. Никакой ссылки на первоисточник там нет.
Иначе я ровно также могу поставить под сомнение твою ссылку на какую то вики.
Дать библиографическую ссылку на Early History of Smalltalk с номером страницы? Мне же не сложно.
maxxannik
12.08.2016 23:49-1В статье всего две ссылки и сказано что размышление основана на тех данных которые указаны в них.
То что написано в статье — это лишь вырезки из тех страниц разбавленные выводами к которым пришел после размышлений и анализа своего опыта.
Можно сказать иначе: вся статья это лишь попытка обратить внимание на то что сказано в других источниках ссылки на которые указаны в статье. Все что нужно — просто прочитать статью и ткнуть по ссылкам. Доверять им или нет — не так уж важно. Это личное дело каждого. Я доверяю.
Ссылку на книгу конечно можно дать. Вот только надо учитывать что это все равно не первоисточник. Я писал статьи в журналы и видел как редакторы журналов правят тексты изменяя смысл с ног на голову. Потому почитать полезно, но верить или нет все равно удел личного решения. В этом отношении было бы клево конечно пообщаться с автором в живую :)lair
13.08.2016 00:09В статье всего две ссылки и сказано что размышление основана на тех данных которые указаны в них.
Ни по одной из этих ссылок в цитатах Кэя тоже нет слов "компонент".
Ссылку на книгу конечно можно дать.
Alan C. Kay, The Early History of Smalltalk — ACM SIGPLAN Notices Volume 28, No. 3, March 1993 Pages 69-95. Конкретные шесть пунктов находятся на 78 странице.
maxxannik
13.08.2016 00:00Прям как по заказу :)
Внимательное изучение своих же ссылок дает ссылку на виде http://www.tele-task.de/archive/video/html5/14029/ с выступлением автора.
Вероятно это выжимки из видео https://habrahabr.ru/company/hexlet/blog/303754/
Но могу ошибаться.
Мой английский не так хорош. Если есть кто то свободно владеющий, было бы круто посмотреть и рассудить :) Подтвердить выжимку или опровергнуть.
maxxannik
13.08.2016 00:07изучив указанные мной ссылки еще глубже нашел пруф на эл письма Алена http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en
И цитаты судя по всему от туда.lair
13.08.2016 00:10… в этом письме тоже нет ни одного слова "компонент". Цитата про "я думал об объектах как" — действительно есть, но я с этой цитатой и не спорил никогда, просто она — не определение.
maxxannik
13.08.2016 00:37если это просто не определение тогда что есть просто определение?
lair
13.08.2016 00:41Раннее (70-ых годов) определение я уже привел, оно содержит 6 пунктов (и сильно привязано к Smalltalk). Позднее (2003-его) года определение есть в посте и по ссылке, и оно сводится к
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things
Это определение, действительно, не требует классов, но надо понимать, когда оно возникло.
maxxannik
13.08.2016 00:50-1Получается что не найдя подтверждений своим идеям и не сумев логически разрешить противоречия идей с цитатами ты решил все списать на 'это было давно и не правда'. А допустить то что правда может отличаться от тех шаблонов в голове которые тебе вбиты учебниками и окружением ты не готов? Тогда какой смысл в нашем диалоге?
lair
13.08.2016 00:53Получается что не найдя подтверждений своим идеям и не сумев логически разрешить противоречия идей с цитатами
Э, что? Простите, а какая (моя) идея какой цитате противоречит?
Пока что я вижу строго обратное: цитаты из Кэя никак не соотносятся с панегирками в адрес WP. И, аналогично, никак не соотносятся с определением компонентной разработки.
maxxannik
13.08.2016 00:57-1Например твоя идея о том что в ООП объекты описаны классами или чтобы создать объект нужно написать класс. Именно такой шаблон в своей голове ты принимаешь за правду и дрочишь тут на карму? Цитата говорит о том что объекты это компьютеры в сети. Ну ка напиши как мне класс который создаст компьютер в сети. После чего противоречие твоей идеи с цитатой можно будет считать разрешённой.
lair
13.08.2016 01:01Например твоя идея о том что в ООП объекты описаны классами или чтобы создать объект нужно написать класс.
А у меня есть такая идея? Странно, я ее нигде не озвучивал.
(Зато, наоборот, требование, что каждый объект принадлежит к классу, есть в работе Кэя)
Цитата говорит о том что объекты это компьютеры в сети.
Нет. Цитата говорит, что Кэй думал об объектах как о чем-то похожем на компьютеры в сети: "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages".
Ну ка напиши как мне класс который создаст компьютер в сети
"Ну ка напиши как мне объект который создаст компьютер в сети"
maxxannik
13.08.2016 01:14-1Хм. Это либо у нас тут у кого то проблемы с головой. Либо мы сейчас нащупаем ещё одну разновидность ООП. Что в твоём понимании объект? Какие методы создания объектов ты знаешь? Давай так поставлю вопрос.
Я никогда не говорил что объекты должны быть написаны. Потому извини, но я не готов писать тебе компьютеры. То как я понимаю объекты далеко в принципе от программирования в общем виде и оооооооооочень редко может принимать форму кода. Примерно в 1% случаев от бесконечности.
Потому извини, не уверен что могу его написать.
А вот те кто молится богу class based OOP явно уверены что объект это экземпляр класса который написан кодом. И я думал что ты из этого лагеря. Но может быть нет? Надо понять твоё определение объекта и станет ясно проблема в голове или у нас новый тип ООП тут появился.lair
13.08.2016 01:19Что в твоём понимании объект?
Я надеюсь, речь идет применительно к программированию? Тогда — это набор данных и/или операций, обычно — в правильном дизайне — семантически связанных.
maxxannik
13.08.2016 01:28-1Учитывая уровень мышления местных обитателей конечно мы сузим область понятий до программных систем.
Я правильно понял что ты можешь создать объект не применяя классы например в php?
Потому что я могу. Из твоего определения создать объект в php без класса. И это означает что либо мы начинаем мыслить рядом, либо ты просто пытаешься придумать свой тип ООП. Потому давай сузим область вопроса до php. Как ты создашь объект в php? Какие способы там тебе известны?lair
13.08.2016 01:29Я правильно понял что ты можешь создать объект не применяя классы например в php? [...] Как ты создашь объект в php? Какие способы там тебе известны?
Не знаю, никогда не писал на php.
maxxannik
13.08.2016 01:41-2Обидно. Один из самых популярных языков. Которые сегодня знают даже домохозяйки. Не говоря уж о программистах.
В общем твоего определения хватит.
Попа в том что объектом в больших системах может быть не только код, методы и данные. В том числе могут быть машины. Например станок для заточки шестеренок или лампочка с управлением по bluetooth. Это объект. Он может предавать и получать данные. В этом суть. Именно потому автор говорил о похожести на клетки или компьютеры. Компьютер также является объектом и может обмениваться сообщениями в рамках tcp ip сети. Почему автор и приводит TCP систему в качестве примера близкого к идеалу ООП.
Но я понимаю что для не окрепших умов эти понятия слишком далеки от шаблонов и мозг не способен их понять. Возможно на это уйдут годы. А может быть и одной жизни не хватит. Тут кому как повезёт.lair
13.08.2016 01:44объектом в больших системах может быть не только код, методы и данные В том числе могут быть машины. Например станок для заточки шестеренок или лампочка с управлением по bluetooth. Это объект.
Это не объект в терминах программирования. В объектах в терминах программирования могут быть только данные и код (хотя одно можно рассматривать как частный случай другого, в любую сторону).
maxxannik
13.08.2016 01:53-1и кто же определил эти термины?
я конкретно веду речь про ООП от первых слов статьи и до сюда. И привёл уже кучу цитат одного из отцов ООП. Вот он говорит что объект больше похож на клетки и компьютеры. А то что понимают программисты это ковыряние в носу и чесание пуза на мелководье. Вместо того что бы нырнуть в глубь реально интересных и масштабных идей. Ну да ладно. Вам решать где плавать и в каких терминах :)lair
13.08.2016 01:56и кто же определил эти термины?
Узус. Практика использования, иными словами.
Вот он говорит что объект больше похож на клетки и компьютеры.
Нет, он этого не говорит. Сколько еще раз надо привести цитату дословно? "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages"
А главное, из того, что он думает об объектах как о чем-то похожем на компьютеры, никак не вытекает, что компьютеры — это объекты; скорее наоборот, если мы говорим о чем-то как о похожем, значит, оно не идентично.
maxxannik
13.08.2016 01:21-2Кстати реально все объекты принадлежат к классам. Особенно если понять что все есть объекты. Если например хватит ума понять вообще что такое объект и например его отношение к субъекту. Ежу станет понятно что все есть объекты и все объекты относятся к классам или являются экземплярами класса. Вот только есть одна беда — во всем этом ни слова о коде. И все это реально в том числе для идеологий и понятий которые были 1000 лет назад когда о компьютерах даже не могли мечтать. Все эти понятия и определения уже тогда были и будут ещё миллиарды лет после того как умрёт последний программист на земле. И только программист может думать что за этими словами скрывается что то похоже на код.
lair
Внезапно, нет. Это никак не вытекает из того, что вы выше цитируете из Кея.
Вы, видимо, ничего не слышали про модель акторов.
Тоже нет. В RESTful API принципиально не должно быть внутреннего состояния, и там нет никаких сообщений.
Впрочем, главная ваша ошибка в том, что вы пытаетесь судить об ООП, как оно есть сейчас, по словам автора, который когда-то этот термин придумал, но на индустрию после этого не влиял. Вы не задумывались, что некоторые термины эволюционируют сами?
maxxannik
Задумывался. Но это не отменяет суть проблемы.
Люди начинают судить о том что ООП плохо или хорошо на основании некого своего или агрегированного понятия, не принимая во внимание суть понятия которое вкладывал в него автор.
Также мне не дает покоя мысль о том что единственная система которая первая подошла близко к сути этого понятия вдруг стала №1 в мире. Совпадение? :)
lair
Так я об этом и говорю: уже не так важно, что именно вкладывал автор, с тех пор индустрия изменилась, и понятие тоже изменилось вместе с индустрией. Можно обсуждать, плохо это или хорошо, но это уже так, и это уже данность.
Во-первых, она "№1 в мире" только по избранными вами критериям. Например, в моей области она вообще неприменима.
Во-вторых, она "первая подошла близко к сути этого понятия" тоже только по вашему мнению — вы проигнорировали мой вопрос про модель акторов.
maxxannik
Модель акторов не применял. И плохо понимаю причем тут она.
Как сказал автор ООП «ошибка в формулировке привела к тому что программисты начали мыслить мелко». Я склонен ему верить. И развиваю его идею о том что объекты поняты обшибочно да и не важны. Вся соль и суть в способности компонентов обмениваться сообщениями. То на что почти никто не обращает внимание.
Так давайте уточним критерии. Их не много.
1. Веб — это множество сайтов. Сайт — единица строения Интернет. WP — охватывает более 25% веб сайтов. Другими словами более 25% Интернет адресов. Это достаточно объективный критерий с точки зрения одной из самых крупных систем в мире.
2. Количество специалистов и информационных материалов (в России этот показатель конечно пока под вопросом, но скоро думаю выровняется к мировому первенству)
3. Количество готовых компонентов
Их реально больше. Но для начала хватит 3-х. По этим критериям нет ни одной другой веб системы которая хоть как то могла бы конкурировать с WP.
Критерии и цитаты на основании которых я сделал такой вывод описал в статье.
Не понятно каким образом сюда можно отнести модель акторов?
lair
При том, что в модели авторов происходит ровно то, что описано у Кея: независимые объекты (акторы) обмениваются сообщениями. Все.
Нет. Вы забываете про то, что есть не веб-системы (а уж количество и сложность вообще никак не коррелируют). Попробуйте сделать на WP систему управления станком с ЧПУ, что ли...
Не имеет никакого отношения к качеству самой системы (даже если это утверждение верно, во что я не очень верю).
Банальная ложь: скажем, для .net framework готовых компонентов заведомо больше.
Это только слова. Покажите конкретные примеры архитектуры и кода, которые подтвердят, что WP действительно устроен так, как вы ему приписываете.
Выше уже написано.
maxxannik
Это здорово. Вот только меня смущает тот факт что я этого не встречал в реальном мире. Как много систем использует эти механизмы?
Если они так редки то что можно сказать о их качестве и адекватности?
Я про них не забыл. Просто убрал из внимания как мало используемые и слишком простые. Любая система которая находится вне веб зачастую очень простая и не может превращаться в достаточно сложную. А именно это ставил во главу угла Ален Кей.
Опять же это мой опыт. Я когда то занимался создание сложных систем для управления большими организациями. И все что было не веб — умирало рано или поздно просто потому что не могло выдержать расширения и масштабирования. Единственная область технологий которая доказала свою способсность масштабироваться и развиваться — это веб. Потому и рассматриваю только эту часть. Потому что все остальное не требовательно к ООП в той форме которую пытался описать автор. Другими словами там может работать любой тип ООП, даже тот который придуман в C++.
А подтвердить? Или тут на хабре принято просто обвинять людей во лжи без оснований?
Для WP по последним данным готовых компонентов только в одном официальном каталоге около 46 000 https://wordpress.org/plugins/
А еще есть бесчисленное множество не официальных каталогов и просто компонентов которые лежат на GitHub.
Есть данные о числе компонентов под .net? Или ваши слова ничем не подтверждены и являются лишь вашими догадками?
lair
Ну так пойдите и познакомьтесь.
Сколько-то.
Вы ничего не знаете об их редкости. И, что характерно, редкость никак не связана с качеством и/или адекватностью. Систем управления ядерными реакторами меньше, чем сайтов, но это не значит, что они "менее адекватные".
Серьезно? Слишком простые? АБС банка — слишком простая? Биллинг сотового оператора — слишком простой? Система бронирования авиабилетов — слишком простая? Глобальный месседжнер, навроде WhatsApp — слишком простой?
(я пока даже не беру инфраструктурные вещи типа распределенной базы данных, которая тоже сложнее большей части веб-сайтов)
И много вы знаете сложных систем для управления большими предприятиями, написанных на WP?
А еще вы путаете веб-сайты, по которым считается статистика использования, и системы с веб-интерфейсом, которые (а) зачастую вообще не видны из веба и (б) превосходят "обычный" веб-сайт по сложности на два порядка.
There are 60,966 packages. Это не считая того факта, что в .net каждый класс — это "компонент" в терминах обмена сообщениями.
maxxannik
Ты случаем не вегетарианец? Чето какой то напряженный. С таким уровнем аргументации боюсь мало смысла пытаться с тобой общаться. Ты дыши глубже если так нервничаешь и начинаешь так опускаться по мышлению. Либо надо прекращать это. Не дай бог клавиши сломаешь.
Ты почитай что там за компоненты. Это jQuery, Bootstrap, AngularJS. Я боюсь тебя огорчить но это не компоненты для .net. Это библиотеки для фронта.
Если собирать такие компоненты под WP то можно случайно за 100 000 перевалить. Давай играть честно. Или не играть тогда уж.
lair
Вот аргументы и кончились. Обидно.
maxxannik
Аргументы не кончились. Кончилось желание общаться на подобном уровне аргументации как у тебя.
lair
Так общайтесь на другом, кто ж вам мешает.
maxxannik
Я привожу цифры, факты, максимально конкретные и чистые.
Ты же приводишь аргументы уровня «ну так пойди и познакомься», далее «сколько-то». Единственный числовой фактор который ты привел на проверку оказался лживым и имеющим кучу помех.
Вопрос не в том как я общаюсь. А в том как ты. Будь тут хоть один разумный аргумент, я бы продолжил. А так ну нафиг.
lair
Единственный конкретный факт — это количество плагинов. И о чем оно говорит?
raveclassic
Да бросьте Вы. Собеседник не ведает, что творит.
bohdan4ik
Вспомнилось (:
https://habrahabr.ru/company/mailru/blog/307168/#comment_9736410
RaaaGEE
Достаточно. Посмотрите в сторону Akka или там Rx, на которых строятся большие масштабируемые системы (как пример тот же Яндекс) и не очень большие (тот же Rx, используется в Android-приложениях).
Кстати говоря, то что Вы описали, есть ничто иное, как микромодульная архитектура.
mird
Давайте рассмотрим, например, такую не веб программы как операционные системы Windows и Linux. Можете привести мне в пример веб программы большей сложности?
DarthVictor
А почему вы сайты на вордпресе считаете за отдельный сайт, а странички в фейсбуке или вконтакте нет? Просто потому что у них домен второго уровня что ли?
bromzh
Вот у нас на 1-м домене: часть адресов отдаётся CMS-кой, часть адресов — api (реализованный на Spring), часть — SPA-админки, использующие это апи. По сложности, api и админки намного превосходят CMS-составляющую, однако, т.к. эти страницы недоступны для роботов, то в статистику попадёт только CMS. И таких примеров среди ИТ-компаний очень много. А если же посмотреть внимательнее, то на деле львиная доля от этих 25-ти процентов WP-сайтов по своей сути простые лендинги/бложики/новостные сайты.
Ну ок, WP тут на первом месте. Но это никак не подтверждает и не опровергает, что он хорошо подходит для чего-то более серьёзного, чем типовые сайты.
С другой стороны, сколько, например, онлайн-банков построены на WP? Сколько на WP написано enterprise-систем? Сколько проектов/сайтов/приложений гугла, яндекса или других крупных IT-компаний используют WP?
Выводы сделать нетрудно.
poxu
Разрешите выразить своё полное согласие!
Есть вот такая CMS — Drupal. Там тоже хуки и она постарше вордпресса наверное будет. Тем не менее популярности в ней меньше. Так что даже если вдруг WP действительно номер один — причина этого явно не только в хуках и всём таком.
Alew
Не существует общественного консенсуса о том что такое ООП. Согласитесь, было бы очень странно если бы вы встретились с Аланом Кеем и начали бы ему рассказывать о правильном взгляде на ООП, а он бы только и делал, что удивлялся сокрушаясь как он отстал от жизни.
lair
Есть-есть. Например, есть вполне общераспространеннное мнение, что ООП — это не ФП или не ПП. Используя этот набор отрицаниц, можно создать некий взгляд.
Тем не менее, это именно то, что послужило поводом для его "разъяснений" о его понимании ООП — чье-то обсуждение о природе/определении.
И нет, я не вижу ничего странного в том, чтобы, встретившись с АК, рассказать, что нынче в мейнстриме называют ООП, и услышать его реакцию. Другое дело, что непонятно, зачем это надо.
Alew
Был бы консенсус, не было бы споров. Наиболее широко распространенное мнение — да, консенсус — нет.
Рассказать Кею, что в мире делается и предложить ему скорректировать ему свою картину мира, это все-таки не одно и тоже.
lair
А кто-то где-то предлагал?
Alew
Я об этом спрашивал в первом сообщении
lair
Ну то есть вы и предлагали. Не, мне это не интересно, спасибо.
poxu
Как я написал ниже, Drupal вот тоже модульный и на хуках. И чего-то такой популярности не получил.
kez
Алан просто придумал одно, а высказал — другое. Современное понятие ООП от этого не поменяется.
maxxannik
Не то.
Алан просто придумал и сказал одно, а поняли и начали развивать другое. Вот так точнее.
На выходе имеем хитрый и запутанный омоним. Одно слова и два значения.
Это как слово «ножка» — может быть речь о части тела человека? а может быть о части мебели на которой сидят?
Слово одно — но получило множество значений.
Также и с ООП. Тот кто придумал это понятие думал об одном и это понятие также живет и развивается. Этот подход жив и многие его используют. Но называют его иначе или чаще всего вообще никак не называют.
Но авторы C++ назвали этим словом некий свой механизм, который ассоциируется с классами, инкапсуляцией и наследованием. Развивается параллельно и имеет мало пересечений с тем значением которое было изначально.
Суть и смысл статьи не в том чтобы пытаться менять то ООП которое «классы», а в том чтобы знать правду и что существует второе значение у ООП, которое имелось ввиду автором. Оба инструмента крайне эффективны и полезны если их знать, понимать и уметь применять. Это я говорю как человек которые применяет оба инструмента в работе каждый день. У них реально мало общего — разве что звучание, один автор и то что оба применяются в ИТ. Но по сути это два абсолютно разных принципа и инструмента.
Как то так.
kez
цитата из сообщения Алана:
Нет, Алан именно неправильно выразился / «придумал неправильный термин».
Что сказал, то и начали развивать.
Я понимаю, в чём суть статьи (и не спорю с этой сутью), но просто пытаюсь Вам сказать, что сейчас «обмен сообщениями» называется термином акторы, и что Алан «хотел придумать» именно их.
maxxannik
Те системы которые мне известны, которые стали популярны и захватили рынок доказав свою эффективность соответствуют принципу ООП в понятиях Алена Кея не содержат в себе вещей называемых термином «акторы».
Я не против того что акторы имеют место быть и может быть соответствуют изначальному понятию ООП. Мне сложно об этом судить т.к. я не видел ни одной крупной и расширяемой системы которая построена на основе этих штуковин.
Но если будут примеры, то мне будет проще поверить в адекватность этой идеи.
Я не могу доказать обратное без личного опыта, но и без подтверждения с примерами этого утверждения не смогу воспринимать его всерьез. Возможно это так, а может быть и нет. Это все что я могу сказать по этому поводу :)
lair
WhatsApp (Erlang)
Halo (Orleans)
Akka
4lex1v
Не знаю на сколько это будет актуально и интересно, но Orleans все же не совсем Акторы. Тут есть интересное сравнение за авторством бывшего лида Акковской команды — https://github.com/akka/akka-meta/blob/master/ComparisonWithOrleans.md, не уверен, что есть на русском
lair
Для целей этой дискусии модель "виртуальных акторов" Orleans вполне совпадает с "чистой" моделью акторов в Акке. Нас же интересует изоляция и message passing (пусть даже последний в Orleans и скрыт кодогенерацией, которой MS славен во всех подобных сценариях, сколько я его помню).
kez
Честно прочитав все комментарии, заметил, что Вы часто ссылаетесь на «системы, которые Вам известны», в основном эти системы — система WP.
А ещё какие-нибудь?.. (Возможно я просто пропустил..)
Wordpress, как таковой, создавался для домохозяек, в нём должна быть возможность сделать какое-либо действие в один клик (в частности, подключить какой-то модуль). Организовать такую систему взаимодействия между модулями проще всего на сообщениях.
Если бы WP был написан на другом принципе, то эта статья была бы именно про него.
И, как Вы сказали ранее,
…
Пример привычного ООП:
В кругах биоинформатиков довольно популярен набор утилит picard tools. Достаточно успешный проект?
Кстати, не изучал подробно, но возможно Вы знаете, следуют ли веб-браузеры принципу ООП Алана?
…
Ну, про WhatsApp уже сказали…