Здравствуйте, Воронков Василий, Вы писали:
ВВ>Хайку или хокку. Первое более позднее
Хаику и хокку — это одно и то же См. словарь японского языка.
До них была немного другая (но похожая) стихотворная форма, но как называлась — не помню.
Здравствуйте, Astaroth, Вы писали:
A>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Хайку или хокку. Первое более позднее
A>Хаику и хокку — это одно и то же См. словарь японского языка. A>До них была немного другая (но похожая) стихотворная форма, но как называлась — не помню.
Я и не утверждал что это разное. Более поздним является само _название_ — хайку, которое стало употребляться этак в веке 17. А хокку изначально это просто первая строфа танка (той самой "другой" стихотворной формы), а впоследствии уже самостоятельный жанр — как бы принципиально незавершенное стихотворение.
Фаза первая) Никому никому никому.
Фаза вторая) Никому никому никому, только ему одному.
Фаза третья) Никому никому никому, только ему одному и его друзьям.
Фаза четвертая) Всем всем всем.
Фаза пятая) Кому кому кому.
Здравствуйте, _vovin, Вы писали:
_>После этого Алан Кей сформулировал три базовых принципа объектного подхода: _>1. Объект — базовая единица системы. _>2. Объекты обладают состоянием. _>3. Единственным способом взаимодействия между объектами является посылка сообщения. Объекты сами определяют как обрабатывать сообщения.
_>Соответственно объектно-ориентированным языком является язык, который взаимодействует с такой системой объектов посредством посылки сообщения. _>Заметьте, тут ничего не говорится про классы и наследование.
_>Но почему-то так вышло, что все обратились к модели Simula, т.е. навесили ООП ярлык ИНКАПСУЛЯЦИЯ, ПОЛИМОРФИЗМ, НАСЛЕДОВАНИЕ. И главными ценностями были провозглашены модульность и повторное использование.
Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время. Это язык, он создан чтобы люди понимали друг друга, а ООП всего лишь название. Например, глупо сейчас спорить о том, что "блядь" — это вполне цензурное слово, приводя в доказательство исторические справки (когда-то оно действительно было вполне обиходным, а сейчас режет слух, хоть обчитайся этих справок). Поздновато.
ООП — это именно ИНКАПСУЛЯЦИЯ, ПОЛИМОРФИЗМ, НАСЛЕДОВАНИЕ, — то есть то, что под ним сейчас понимает сообщество Computer Science. Все. Принципы Алана Кея — это конечно интересно, но это не ООП. Называйте их как хотите.
Теперь если разобраться по существу, то принципы Кея (а именно №3) определяют понятие инкапсуляции, и динамического связывания как способа достижения полиморфизма. Эти вещи были изучены исследователями, и сформулированны в более общем виде, без всяких "сообщений".
Инкапсуляция - это "абстрактные типы данных", которые задаются поведением, а не структурой. Полиморфизм - в общем случае возможность вызова функции с агрументами разных типов (для метода класса — экземпляр тоже является неявным аргументом), причем поведение может различаться в зависимости от типа аргумента (С++: виртуальные функции, перегруженные функции), а может и нет (С++: шаблонные функции). Наследование - отношение между абстрактными типами данных, позволяющее использовать один тип в контексте другого (отношение "подтипа"). Оно совсем не обязательно должно задаваться программистом явно (!) — об этом в определении ничего не сказано!
Легко видеть, что Smalltalk удовлетворяет этому определению . Оно более общо, нежели модели программирования С++, Simula, Oberon, Smalltalk, etc. В ЦК, знаете-ли, тоже не дураки сидят. Мы полетим ночью.
_> Но это является пагубным упрощением, которое практически сводит на нет всю идею объектного подхода. Где главным выигрышем является возможность непосредственного манипулирования динамическим миром объектов посредством гибкой операции посылки сообщения, минуя привычную чрезмерную серию трансформаций текст->код->запуск->взаимодействие->результаты->текст->...
Как раз напротив. В определении ООП ничего не говорится ни про динамичность или статичность типизации, ни про другие подобные характеристики языка, вроде сообщений. Там даже не сказано, что у класса должны быть "методы" в привычном смысле этого слова , и каким именно образом и в каком объеме реализуется полиморфизм. А вот схема смолтока — это один из частных случаев. Возможно , чем-то лучше, чем другие.
_> Поэтому ООП можно условно поделить на две категории — OBJECT-oriented и object-ORIENTED. _> В первом случае имеем полноценную динамическую систему (Smalltalk, Self, отчасти Objective-C, Ruby), во втором — процедуры, завернутые в классы (Simula, C++, Java, C#).
Стоит отметить, что вы сравниваете языки, а не определения ООП. Не надо мешать общеизвестное определение ООП, с особенностями системам типов упомянутых языков. Причем как тех (Simula, C++, Java, C#), так и других (Smalltalk, Self, отчасти Objective-C, Ruby), потому как все эти языки ему удовлетворяют. Каждый по своему, с особенностями. Но это не повод, чтобы разводить языковые войны .
Здравствуйте, Rumata, Вы писали:
R>Здравствуйте, WFrag, Вы писали:
R>>>Вот например, всем известно, что бывают у объектов эл-ты public, private и protected. А почему только 3? Почему нет какого-нибудь четвертого?
WF>>Кто тебе такую глупость сказал?
WF>>public, private, protected — это уже косвенное следствие инкапсуляции. R>Пардон, совсем пропустил это замечание. R>Ну дык именно, что косвенное. Кто-то решил, что их должно быть 3, т.к. это "следует из инкапсуляции". Но, т.к. понятие самой инкапсуляции, как я понимаю, само четко не сформулированно, следствия из него имхо строить довольно опасно.
Сформулировано предельно четко. Весь вопрос — "где". Идея, которая лежит в основе инкапсуляции — Abstract Data Types, типы, которые определяются набором операций над ними, и ничем другим. Совершенно математическая по духу концепция. Одной только инкапсуляции посвящены целые книги, например
Использование абстракций и спецификаций при разработке программ
Лисков Б., Гатэг Д.
М.: Мир
1989. 424 с.
Задача, решаемая применением инкапсуляции: разбить систему на набор по возможности слабо связанных компонентов, так, чтобы реализация одного компонента как можно меньше влияла на другие. Пример: алгоритмы STL, такие как transform, работают с любым типом контейнера, не зависимо от его внутренней структуры (список, массив, строка). Почему так? Потому, что контейнеры предоставляют одинаковый интерфейс через итераторы, который не зависит от способа реализации контейнера (т. е. не ломает инкапсуляцию, как, например, доступ по индексу).
Решение: выставлять наружу интерфейс в виде функций, по возможности определяющих поведение объекта, а не структуру. Пример: доступ по индексу — не лучший интерфейс для контейнера "вообще", он накладывает серьезные ограничения на способ хранения. Списки, к примеру, вы уже не попользуете. Такой интерфейс ломает инкапсуляцию, не смотря на то, что может быть реализован в виде функции — вы выдаете наружу структуру хранения. Еще один пример плохой инкапсуляции — использование сеттеров-геттеров.
"Плохая инкапсуляция" — это всегда плохо? Нет. Все хорошо в меру и к месту. Ключевое слово в предыдущем абзаце — "по возможности".
Применение инкапсуляции поможет писать программы быстрее? Вообще говоря нет. Думать придется больше. В ряде случаев это замедлит разработку . Так где преимущество? Оно в том, при разумном применении инкапсуляции система будет проще (благодаря уменьшению количества внутренних зависимостей), и, как следствие, менее "хрупкая" (т. е. будет устойчивее к изменениям). Начиная с некоторого (довольно большого) объема кода это критичный фактор, определяющий качество продукта (кол-во дефектов), а также цену вносимых изменений. Т. е. хорошая инкапсуляция принесет дивиденты при развитии и сопровождении системы (докрутке фич/модификации, рефакторинге, исправлении дефектов, просто при итеративной разработке). Это способ держать сложность системы под контролем.
Реализация: поддержка инкапсуляции языком не критична — инкапсуляцию можно применять на уровне соглашений в любом языке. Но поддержка на уровне языка приятна. Т. к. ее проверяет компилятор, есть уверенность, что в незнакомом коде инкапсуляция не нарушена. Хотя... Есть же еще спецназ от программирования, которых ничего не остановит!
#define private public
#include"header.h"
Так что не уверенность, а всего лишь надежда
private, protected, public — определяют уровни доступа "локальный", "для подклассов", "для всех". Почему их три? Попробуйте придумать еще.
Здравствуйте, Gaperton, Вы писали:
G>Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время.
А может, стоит как раз обратиться к определению Алана Кея? Оно, кстати, гораздо более компактное и простое. И, заметьте, никаких понятий вроде "абстрактные типы данных", инкапсуляция, полиморфизм и прочей шелухи
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время.
_>А может, стоит как раз обратиться к определению Алана Кея? Оно, кстати, гораздо более компактное и простое. И, заметьте, никаких понятий вроде "абстрактные типы данных", инкапсуляция, полиморфизм и прочей шелухи
"Пусть это будет просто, просто — насколько это возможно, но не проще"
Да пожалуйста. Есть только несколько маленьких нюансов.
1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml.
2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки.
3) Что остается? Smalltalk , все что на него похоже.
Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
А если не хотите забивать себе голову теорией, то все гораздо проще и компактнее. ООП — это когда есть классы.
Здравствуйте, Gaperton, Вы писали:
G>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml.
Не может. И что в этом такого страшного?
G>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки.
Здесь, в принципе, можно "притянуть", приняв вызов метода = посылка сообщения (что, кстати, обычно и делают).
G>3) Что остается? Smalltalk , все что на него похоже.
Да, эти языки являются наиболее адекватными реализациями модели Кея.
G>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию.
Хе, большинство статей, которые я помню, где авторы брали на себя труд объяснить, что такое объектный подход, они начинали именно с кеевского определения, в том или ином виде. А затем уже переходили к инкапсуляции, полиморфизму и т. д. И знаете, мне кажется, почему? Потому что слова "инкапсуляция", "полиморфизм" и "наследование" никак не отражают динамики объектной системы. Они описывают лишь свойства объектных систем, но не их поведение.
Кстати, именно такой взгляд на объекты приводит к появлению статей типа "Is OO Dead?"
G>Подобные подмены терминов ни к чему кроме путаницы не ведут.
Именно. Поэтому я и ратую за определение Кея
G>А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
Отчего же вызовут? Да, C# поддерживает некое подобие ООП, и давая волю фантазии при проектировании, придется себя ограничивать
Тем не менее и анализ, и моделирование предметной области Вы проводите, именно используя определение Кея .
G>А если не хотите забивать себе голову теорией...
Как раз именно хочу. Только теория теории рознь
Здравствуйте, serg_mo, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml. _>Не может. И что в этом такого страшного?
Уж не знаю, насколько это страшно , но перечисленые языки (Haskell, CLOS и OCaml) поддерживают ООП . Даже в простом, интуитивном смысле, хотя это легко и проверить формально по классическому определению. Что говорит о плохо составленом определении Кея — оно недостаточно общо, настолько, что не работает на целом классе языков.
G>>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки. _>Здесь, в принципе, можно "притянуть", приняв вызов метода = посылка сообщения (что, кстати, обычно и делают).
Ну, в общем-то все так и делают. Но это будет именно "притянуть", потому как "объекты сами определяют как обрабатывать сообщения" — здесь имеется в виду динамическая диспетчеризация. Тонкость. Любому объекту может быть отправлено любое сообшение, которое этот объект может корректно (!) отработать — вот важный элемент системы типов Кея. Именно поэтому Кей использует термин "сообщение", а не "метод". И это та часть определения, которую уже никак не притянешь, и не выбросишь — или это определение перестанет быть определением Кея.
G>>3) Что остается? Smalltalk , все что на него похоже. _>Да, эти языки являются наиболее адекватными реализациями модели Кея.
Ага. И единственными языками, которые формально удовлетворяют его определению. Что говорит о том, что это определение вполне конкретной системы типов, используемой в данных языках, а отнюдь не парадигмы ООП.
G>>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. _>Хе, большинство статей, которые я помню, где авторы брали на себя труд объяснить, что такое объектный подход, они начинали именно с кеевского определения, в том или ином виде. А затем уже переходили к инкапсуляции, полиморфизму и т. д. И знаете, мне кажется, почему? Потому что слова "инкапсуляция", "полиморфизм" и "наследование" никак не отражают динамики объектной системы. Они описывают лишь свойства объектных систем, но не их поведение.
Верно. Это именно свойства системы типов. Поэтому они и используются как ОО характеристика не зависящая от языка и системы типов. Оно и не должно отражать динамику объектной системы само по себе. Не вижу, кстати, ничего удивительного в том, что такая абстрактная характеристика плохо воспринимается.
Хотя у меня получается за 40 минут объяснить это определение так, что люди все прекрасно понимают. Берется определение, объясняется смысл каждого пункта с примерами, поясняется как именно принципы реализуются в С++, Java, как в динамически типизированных языках, почему COM не удовлетворяет этому определению. И вы знаете, прекрасно понимают. При этом, я прекрасно обхожусь без аналогий, аллегорий, и прочих метафизических переходов на яблоки — все предельно конкретно. ИМХО, люди не идиоты, а в мире не так много сложных вещей; надо просто уметь объяснять.
Кстати, хочу уточнить. Вы хотите сказать, что вам удасца избежать знакомства с этими тремя понятиями, программируя на смолтоке?
_>Кстати, именно такой взгляд на объекты приводит к появлению статей типа "Is OO Dead?"
Эт врядли. К появлению таких статей ведет то, что люди считают систему типов своего любимого языка фактическим определением ООП. На деле же ОО языки весьма разнообразны и многолики. Чтобы иллюзии ушли, рекомендую взлянуть на систему типов CLOS. После этого станет ясно, например, почему именно в определение введен скромный пункт "полиморфизм", а не "сообщения Smalltalk" или "виртуальные функции C++".
G>>Подобные подмены терминов ни к чему кроме путаницы не ведут. _>Именно. Поэтому я и ратую за определение Кея
Ну и напрасно. Непродуктивное это занятие, спорить о значении слов ("что такое ООП"). Особенно тех слов, относительно смысла которых весь остальной мир уже давно договорился.
G>>А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение? _>Отчего же вызовут? Да, C# поддерживает некое подобие ООП, и давая волю фантазии при проектировании, придется себя ограничивать
Ну, я имею в виду, у сторонников С#
_>Тем не менее и анализ, и моделирование предметной области Вы проводите, именно используя определение Кея .
Откуда такая уверенность? Вдруг я использую для этого SADT?
Здравствуйте, Gaperton, Вы писали:
G>private, protected, public — определяют уровни доступа "локальный", "для подклассов", "для всех". Почему их три? Попробуйте придумать еще.
Я бы ещё ввёл
private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Gaperton, Вы писали:
G>>private, protected, public — определяют уровни доступа "локальный", "для подклассов", "для всех". Почему их три? Попробуйте придумать еще.
ZEN>Я бы ещё ввёл ZEN>private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе.
Чтобы добиться такого эффекта, достаточно иметь возможность изменять модификаторы видимости содержимого базового класса в подклассе. Т. е. в подклассе правим protected на private для нашего мембера.
На самом деле, Синклер замечательно и исчерпывающе написал про модификаторы здесь
Здравствуйте, Gaperton, Вы писали: iZEN>>Я бы ещё ввёл iZEN>>private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе. G>Чтобы добиться такого эффекта, достаточно иметь возможность изменять модификаторы видимости содержимого базового класса в подклассе. Т. е. в подклассе правим protected на private для нашего мембера.
Отнюдь не одно и то же. Я не это имел ввиду.
(Да и сторонний разработчик не захочет объявить private.)
В моём случае мы обязываем будущие классы-наследники объявлять фактически final protected member. Причём мы не уверены, какие классы будут порождаться от нашего, но будем уверены, что member может быть переопределён только в наследниках и нигде больше (с областью видимости final protected, полиморфизм будет заканчиваться на близком наследнике однозначно).
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, serg_mo, Вы писали:
_>>Здравствуйте, Gaperton, Вы писали:
G>>>Видишь-ли в чем дело. Оно конечно все так. Но если речь идет об общеупотребимом смысле термина ООП, то разумно признать под ООП то, что понимает под ним большинство, причем уже продолжительное время.
_>>А может, стоит как раз обратиться к определению Алана Кея? Оно, кстати, гораздо более компактное и простое. И, заметьте, никаких понятий вроде "абстрактные типы данных", инкапсуляция, полиморфизм и прочей шелухи
G>
G>"Пусть это будет просто, просто — насколько это возможно, но не проще"
Во-во.
G>Да пожалуйста. Есть только несколько маленьких нюансов. G>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml.
Объектный принцип более широкое понятие чем язык программирования. В частности Erlang представляет собой вполне объектную систему на несколько другом уровне абстракции — в терминах процессов. SOA это в чистом виде транспортная объектная модель с навешанной кучей соглашений.
Если бы ООП всеми понималось как вначале, думаешь пришлось бы тридцать лет ждать появления SOA? Все remoting frameworks в Smalltalk это свой SOA.
G>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки.
Хе-хе. Совершенно отчетливо проглядывает желание НАЙТИ СЕРЕБРЯНУЮ ПУЛЮ.
Ну зачем всему и вся навязывать единственный правильный способ. Вот собирает человек марки, и должен этими марками всем в лицо тыкать?
Меня Haskell, CLOS, C++ вполне устраивают в своем текущем виде если применять их в соответствующих нишах. Объектный подход тоже имеет свои (достаточно широкие) рамки.
Я поражаюсь, насколько бездарно тратятся усилия (в том числе и мои) на борьбу с JSP+Oracle, когда то же самое можно достичь с помощью VisualWorks+GemStone раза в три проще!
G>3) Что остается? Smalltalk , все что на него похоже.
Читаем выше.
G>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение?
Я не против этого. Более того, я сам использую термин ООП (благодяря слову "ориентированное") в общепринятом смысле. Для оригинального определения обычно употребляется Объектный Подход или что-то вроде этого. Но терминология эта зыбкая, т.к. когда говорят ООП (при этом думают о наследовании и т.д.), то под этим подразумевают и Smalltalk, который реализует более общую и продуктивную концепцию.
Вот я против такого обобщения.
Когда говорят "ООП потерпел неудачу", пусть тогда уточняют, что это именно обрезанный статический взгляд на объекты не удался. Отсюда и фразы вроде "C# не поддерживает ООП".
Я за то, чтобы объектный подход (термин и само понятие) стал распознаваем. Нет термина, значит нет предмета.
Глупо замалчивать наличие такой вещи, лишая людей возможности выбора. Больше возможностей — лучше результа. Пусть тебе сам подход не нравиться, но давай другим людям возможность о нем у знать и решить самим.
G>А если не хотите забивать себе голову теорией, то все гораздо проще и компактнее. ООП — это когда есть классы.
А это вообще в корне не верно. Классы были в Симуле, откуда ООП и позаимствовало их как деталь реализации. Но ни в одном определении ООП их нет.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, Gaperton, Вы писали: iZEN>>>Я бы ещё ввёл iZEN>>>private protected. В этом случае member может переопределить только непосредственный потомок класса, но не все потомки. Этакое замыкание контракта наследования в потомке в отличие от final в текущем классе. G>>Чтобы добиться такого эффекта, достаточно иметь возможность изменять модификаторы видимости содержимого базового класса в подклассе. Т. е. в подклассе правим protected на private для нашего мембера.
ZEN>Отнюдь не одно и то же. Я не это имел ввиду. ZEN>(Да и сторонний разработчик не захочет объявить private.) ZEN>В моём случае мы обязываем будущие классы-наследники объявлять фактически final protected member. Причём мы не уверены, какие классы будут порождаться от нашего, но будем уверены, что member может быть переопределён только в наследниках и нигде больше (с областью видимости final protected, полиморфизм будет заканчиваться на близком наследнике однозначно).
Здравствуйте, _vovin, Вы писали:
G>>Да пожалуйста. Есть только несколько маленьких нюансов. G>>1) Ни один функциональный язык не может быть ООП языком по этому определению, так как состояния у объектов там нет — это противоречит самой идее функциональности. Есть только значения. Бедные Haskell, CLOS и OCaml. _>Объектный принцип более широкое понятие чем язык программирования.
Конечно. Но определение должно быть точным (или это уже не определение). Приведенные тобой принципы Кея неверны ни для какого функционального языка, понимаешь? Там у объектов нет и не может быть состояний, в силу свойства referencial transparency. Там функция — базовая единица системы. Functions are the first class citizens in that languages. Эту строчку ты найдешь в любом факе по ФЯ. Знаешь, насколько далек полиморфный вызов языка CLOS от посылки сообщения? Ты удивишься. Представь себе мультиметод — функция, которая "виртуальна" по всем своим аргументам. Это является обобщением известного "виртуального" вызова, и при этом невыразимо в терминах сообщений в принципе. Здесь ты никак не притянешь сообщения.
Да, при этом CLOS удовлетворяет известному определению ООП (инкапсуляция, наследование, полиморфизм). Как и Smalltalk. Вывод? Обычное определение ООП более общо, чем определение Кея, которое есть один из его частных случаев, так же как и системы типов C#, СLOS, Smalltalk, и Simula. Но при этом, ты его почему-то называешь "ограниченным" в сравнении с определением Кея. Ты неправ. Тебе на самом деле не нравятся системы типов конкретных языков, а не "инкапсуляция" с "наследованием" и "полиморфизмом".
_> В частности Erlang представляет собой вполне объектную систему на несколько другом уровне абстракции — в терминах процессов. SOA это в чистом виде транспортная объектная модель с навешанной кучей соглашений.
Вот как раз Erlang — это не объектная система ни в каком смысле, ни в классическом, ни в твоем. Кстати, авторы это языка тоже в этом уверены. А ты здесь путаешь народ. Я проверяю Erlang на соответсвие твоему определению, читай внимательно:
Базовый элемент языка Erlang как и любого другого функционального языка — функция (а не объект!), состояния у объектов нет (язык функциональный), а сообщениями обмениваются не объекты, а процессы, количество которых в реальной системе ограничено десятками тысяч (их нельзя использовать как объекты хотя-бы по этой, второстепенной причине!).
Кстати, "сообщение" в Erlang не приводит к вызову никаких методов, и тем более не возвращает результата. Ты просто не сможешь использовать процессы в роле объектов, потому как единственный способ доступится к процессу — это в свою очередь принять от него сообщение. Там сообщения — это наоборот данные, "объекты" произвольного типа (ты можешь послать другому процессу вообще любую структуру данных — например двоичное дерево), которые посылаются и принимаются примитивами SEND/RECEIVE, и диспетчеризуются полностью вручную. В конце концов, дизайн приложений на Erlang не является объектным. Могу прислать образцы кода, чтобы ты в этом убедился.
Ни одного (!) пересечения с определением Кейна, кроме слова "сообщение". Но с этой точки зрения — и обычный С с библиотекой MPI является такой же объектной системой.
G>>2) Из определения следует, что статически типизированные языки не могут быть ООП языками в принципе, поскольку явно обозначена динамическая диспетчеризация "сообщений". Уходят С++, С#, и другие статически типизированные языки. _>Хе-хе. Совершенно отчетливо проглядывает желание НАЙТИ СЕРЕБРЯНУЮ ПУЛЮ.
Это где, пардон, оно проглядывается? Прошу показать пальцем, я не понимаю.
_>Ну зачем всему и вся навязывать единственный правильный способ. Вот собирает человек марки, и должен этими марками всем в лицо тыкать?
Какой способ? Да не навязывает известное определение ООП никому никакого способа, доказательство тому — многообразие ООП языков.
G>>Весь вопрос — зачем. Авторы (и читатели) большинства статей подразумевают под ООП отнюдь не определение Кея. Хотите, чтобы вас понимали правильно? Используйте устоявшуюся терминологию. Подобные подмены терминов ни к чему кроме путаницы не ведут. А утверждения из разряда "С# не поддерживает ООП" (к чему вы придете пользуясь определением Кея) так вообще вызовет у читателей истерику. Вам нужно такое определение? _>Я не против этого. Более того, я сам использую термин ООП (благодяря слову "ориентированное") в общепринятом смысле. Для оригинального определения обычно употребляется Объектный Подход или что-то вроде этого. Но терминология эта зыбкая, т.к. когда говорят ООП (при этом думают о наследовании и т.д.), то под этим подразумевают и Smalltalk, который реализует более общую и продуктивную концепцию.
Стоп. "более общую и продуктивную концепцию" в сравнении с чем? С С#? Возможно. С ООП? Однозначно нет.
Наоборот, наследование, полиморфизм, инкапсуляция — это более общая концепция чем Smalltalk, С++, и CLOS. И терминология не зыбкая, она как раз предельно точна. Если у тебя есть в этом сомнения, готов их обсудить предметно, по пунктам, и привести необходимые доказательства.
_>Вот я против такого обобщения. _>Когда говорят "ООП потерпел неудачу", пусть тогда уточняют, что это именно обрезанный статический взгляд на объекты не удался. Отсюда и фразы вроде "C# не поддерживает ООП".
Совершенно согласен. Я тоже против такого обобщения.
_>Я за то, чтобы объектный подход (термин и само понятие) стал распознаваем. Нет термина, значит нет предмета. _>Глупо замалчивать наличие такой вещи, лишая людей возможности выбора. Больше возможностей — лучше результа.
Поностью с тобой согласен.
_> Пусть тебе сам подход не нравиться, но давай другим людям возможность о нем у знать и решить самим.
Почему ты решил, что я имею что-то против объектного подхода? Нет, он мне как раз весьма симпатичен. Я против замешивания на дерьме ООП (инкапсуляции, полиморфизма и наследования), и миссионерских фраз вроде "термин ООП стал жертвой обстоятельств". На самом деле, типа, все не так, как вы привыкли думать! И мы, узкий круг посвященных, знаем истину. Вот он, тайный, правильный смысл термина ООП!
На самом деле ты приводишь еще одну, кстати, объективно говоря, не самую гибкую из известных реализаций того же самого ООП. Я не против смолтока, а Кея считаю одним из самых выдающихся людей за историю Computer Science. Но откровенно сектантскую пропаганду я видеть уже устал — это уже третье на моей памяти письмо примерно одинакового содержания.
G>>А если не хотите забивать себе голову теорией, то все гораздо проще и компактнее. ООП — это когда есть классы. _>А это вообще в корне не верно. Классы были в Симуле, откуда ООП и позаимствовало их как деталь реализации. Но ни в одном определении ООП их нет.
Вообще-то я пошутил, а ты сразу всерьез. Да знаю я, что неверно. Но человек чего хотел? Простоты и отсутствия шелухи? Вот ему простота на блюдечке. Цитату из Эйнштейна про простоту видал в начале письма? Это как раз тот случай, когда проще, чем это возможно.
И я боюсь, что больше половины разработчиков считают именно так. Отсюда, в часности, и появление дурацких статей типа "ООП потерпел неудачу", где речь идет о языках вроде С++ и Java, а автор сокрушается, что они таки не серебряная пуля. Я такие статьи совершенно спокойно игнорирую — мало-ли, что на заборах написано.
Здравствуйте, Шахтер, Вы писали:
Ш>Здравствуйте, AndreyFedotov, Вы писали: ...
Ш>Фаза первая) Никому никому никому. Ш>Фаза вторая) Никому никому никому, только ему одному. Ш>Фаза третья) Никому никому никому, только ему одному и его друзьям. Ш>Фаза четвертая) Всем всем всем. Ш>Фаза пятая) Кому кому кому.
Здравствуйте, AndreyFedotov, Вы писали:
AF>Здравствуйте, Шахтер, Вы писали:
Ш>>Здравствуйте, AndreyFedotov, Вы писали: ...
Ш>>Фаза первая) Никому никому никому. Ш>>Фаза вторая) Никому никому никому, только ему одному. Ш>>Фаза третья) Никому никому никому, только ему одному и его друзьям. Ш>>Фаза четвертая) Всем всем всем. Ш>>Фаза пятая) Кому кому кому.
AF> Сколько помню это было про студенток...
Да, но как-то перекликается со спецификациями доступа в C++.
Здравствуйте, Gaperton, Вы писали:
G>Вот как раз Erlang — это не объектная система ни в каком смысле, ни в классическом, ни в твоем. Кстати, авторы это языка тоже в этом уверены. А ты здесь путаешь народ. Я проверяю Erlang на соответсвие твоему определению, читай внимательно:
G>Базовый элемент языка Erlang как и любого другого функционального языка — функция (а не объект!), состояния у объектов нет (язык функциональный), а сообщениями обмениваются не объекты, а процессы, количество которых в реальной системе ограничено десятками тысяч (их нельзя использовать как объекты хотя-бы по этой, второстепенной причине!).
G>Кстати, "сообщение" в Erlang не приводит к вызову никаких методов, и тем более не возвращает результата. Ты просто не сможешь использовать процессы в роле объектов, потому как единственный способ доступится к процессу — это в свою очередь принять от него сообщение. Там сообщения — это наоборот данные, "объекты" произвольного типа (ты можешь послать другому процессу вообще любую структуру данных — например двоичное дерево), которые посылаются и принимаются примитивами SEND/RECEIVE, и диспетчеризуются полностью вручную. В конце концов, дизайн приложений на Erlang не является объектным. Могу прислать образцы кода, чтобы ты в этом убедился.
Ты достаточно узко понимаешь что есть посылка сообщения. Наподобие того, что полиморфизм часто понимается как наличие таблицы виртуальных методов.
The first Smalltalks were in the middle of the progression of
designs. The objects in Smalltalk-72, for example, implemented a kind
of top down recognizer that parsed the messages and responded. There
were no separate methods, and each object was essentially a looping
process (like a machine on the internet) waiting for a message to
parse.
This is very similar to where several Prolog derivatives got to later
on (including Erlang). Hewitt's Actors used this idea in many
interesting and important ways.
Здравствуйте, _vovin, Вы писали:
_>Здравствуйте, Gaperton, Вы писали:
G>>Вот как раз Erlang — это не объектная система ни в каком смысле, ни в классическом, ни в твоем. Кстати, авторы это языка тоже в этом уверены. А ты здесь путаешь народ. Я проверяю Erlang на соответсвие твоему определению, читай внимательно:
G>>Базовый элемент языка Erlang как и любого другого функционального языка — функция (а не объект!), состояния у объектов нет (язык функциональный), а сообщениями обмениваются не объекты, а процессы, количество которых в реальной системе ограничено десятками тысяч (их нельзя использовать как объекты хотя-бы по этой, второстепенной причине!).
G>>Кстати, "сообщение" в Erlang не приводит к вызову никаких методов, и тем более не возвращает результата. Ты просто не сможешь использовать процессы в роле объектов, потому как единственный способ доступится к процессу — это в свою очередь принять от него сообщение. Там сообщения — это наоборот данные, "объекты" произвольного типа (ты можешь послать другому процессу вообще любую структуру данных — например двоичное дерево), которые посылаются и принимаются примитивами SEND/RECEIVE, и диспетчеризуются полностью вручную. В конце концов, дизайн приложений на Erlang не является объектным. Могу прислать образцы кода, чтобы ты в этом убедился.
_>Ты достаточно узко понимаешь что есть посылка сообщения. Наподобие того, что полиморфизм часто понимается как наличие таблицы виртуальных методов.
Издеваешься? "Посылка сообщения" есть "посылка сообщения".
_>Почитай что Алан Кей говорит по этом поводу: _>http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-November/070157.html
_>The first Smalltalks were in the middle of the progression of
_>designs. The objects in Smalltalk-72, for example, implemented a kind
_>of top down recognizer that parsed the messages and responded. There
_>were no separate methods, and each object was essentially a looping
_>process (like a machine on the internet) waiting for a message to
_>parse.
Ну, если так... Любопытно посмотреть, как ты в Эрланге сделаешь аггрегацию процессов и передачу процесса как параметра. А также как у тебя получится скопировать процесс (что, понятное дело, не проблема с объектами). Уж очень странная штука состояние процесса в Эрланге, — это только стек вызовов и "локальные переменные" на стеке .
_>This is very similar to where several Prolog derivatives got to later _>on (including Erlang). Hewitt's Actors used this idea in many _>interesting and important ways. _>[/q]
_>Читай и анализируй.
Что мне анализировать? Намек: я знаю Erlang не по цитатам в статьях о Смолтоке.
Нажал "отправить" слишком рано. _>Ты достаточно узко понимаешь что есть посылка сообщения. Наподобие того, что полиморфизм часто понимается как наличие таблицы виртуальных методов.
Мне кажется, что ты наделяешь пару примитовов SEND/RECEIVE магической силой. Они могут быть реализованы в любом языке как библиотечные функции. Анализируй это! Доказательство от противного: тогда любой язык — объектный! Компрене ву? Не бросается в глаза легкое несоответствие?
_>
_>The first Smalltalks were in the middle of the progression of
_>designs. The objects in Smalltalk-72, for example, implemented a kind
_>of top down recognizer that parsed the messages and responded. There
_>were no separate methods, and each object was essentially a looping
_>process (like a machine on the internet) waiting for a message to
_>parse.
_>This is very similar to where several Prolog derivatives got to later
_>on (including Erlang). Hewitt's Actors used this idea in many
_>interesting and important ways.
Лирическое отступление. Erlang от пролога наследует только похожий синтаксис. Плюс, первый интерпретатор был написан на Прологе. Все. Это concurrent non-pure strict dynamically typed functional language. Там нет ничего такого, что нет в других функциональных языках (ну, может, кроме binaries, да и процессы есть не везде — но к прологу все это мало относится). Т. е. prolog derivative — это последнее, что можно сказать об Erlang.
Кей конечно уважаемый человек, но не стоит ссылаться на каждое его слово как на библию, и тупо повторять все за ним. Я мог бы зацитировать здесь статью Joe Armstrong-а, одного из авторов Эрланга, где он рвет на клочки объектный подход. Но я же не привожу этот бред, потому как из статьи очевидно, что автор нихрена не понял в ООП (как и Кей в ФП). Что не мешает старине Джо оставаться гуру в функциональном программировании (а Кею — в ОП).
См. словарь японского языка.
