Модель приложения, основанная на сообщениях.

← →
Unknown user © (2009-01-24 22:17) [0]

Предлагаю подисскутировать на указанную тему. Ниже я изложил свои мысли. Если где-то подобное уже реализовано - расскажите. Если я заблуждаюсь - аргументируйте.

Создавая сложные проекты, разработчики в первую очередь сталкиваются с отладкой взаимосвязей между объектами приложения. Так как в сложных системах, при классическом подходе, невозможно разделить функциональность между объектами сохранив при этом их независимость. Сложные взаимосвязи объектов порождают циклические ссылки между модулями, запутывают код программы, понижают ее надежность. Кроме того, такой код тяжело распараллелить и выполнять в нескольких потоках. Ключевым элементом для описания взаимодействия объектов является событие. В VCL событие порождает вызов специальных процедур - нотификаторов, что является, по-сути, вызовом из объекта A методов объекта B, управление при этом передается объекту B. Такой подход не позволяет выполнять код, вызывающий данное событие в отдельном потоке. Также таким способом тяжело организовать отношения один – ко многим, когда одно событие должно обрабатываться несколькими объектами независимо.

Я предлагаю использовать следующий подход. Объекты приложения, наследованные от специального класса TAppObject, между собой напрямую не взаимодействуют, то есть сами не вызывают методы других объектов. Для организации взаимодействия объектов используются сообщения. Сообщения передаются и принимаются объектами при помощи специального объекта – диспетчера сообщений TAppDispatcher. Диспетчер содержит список всех зарегистрированных объектов, участвующих в обмене сообщениями. Каждый из зарегистрированных объектов получает ссылку на объект – диспетчер и взаимодействует только с ним, через функции отправки и получения сообщений. Каждое сообщение содержит ID отправителя и получателя. Если вместо ID получателя указано 0 – сообщение широковещательное и адресуется всем зарегистрированным в диспетчере объектам. Подобным образом устроена система сообщений Windows, однако она работает только с оконными элементами управления.

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

← →
Alkid © (2009-01-24 22:26) [1]

Таких схем уже реализовано вагон и маленькая тележка. Даже обобщённое название для сего придумано - Actor Model. На первой работе мы что-то подобное реализовывали.

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

Мое резюме такое - подобная архитектура имеет право на жизнь и оправдана в некотором наборе приложений. На роль "серебрянной пули" все же не тянет :)

← →
Mystic © (2009-01-24 23:10) [2]

Smalltalk изучал?

← →
Unknown user © (2009-01-24 23:16) [3]

>Alkid

Да, действительно. Я сам начал реализовывать такой подход в одном проекте и столкнулся с неприятными моментами о которых вы упомянули. Сложность отладки таких приложений перечеркивает все те достоинства, что может дать описанный подход. Действительно идея хороша, но нет соответствующих инструментальных средств для ее реализации.

Можно подробнее о том как вы это реализовывали, смогли ли отладить, оправдал ли надежды данный подход?

← →
Unknown user © (2009-01-24 23:17) [4]

>Mystic

нет, расскажи что за зверь.

← →
TUser © (2009-01-24 23:23) [5]

Шли WM_any например

← →
Unknown user © (2009-01-24 23:25) [6]

>TUser

Ну это уже детали реализации, использовать систему сообщений Windows или не использовать ее вовсе.

← →
Mystic © (2009-01-24 23:37) [7]

> нет, расскажи что за зверь.

Язык программирования, в котором все основано на сообщениях. Даже вызов обычной процедуры/функции это отправка сообщения

← →
Unknown user © (2009-01-24 23:47) [8]

>Mystic

Круто. Создатели преследовали идеи, которые я изложил выше или причина такого подхода в ином?

← →
ketmar © (2009-01-24 23:55) [9]

>[0] Unknown user © (2009-01-24 22:17:00)
а) Miranda IM
б) Objective C
в) Smalltalk
в) полная фигня, если нет читаемых исходников компилятора.

---
All Your Base Are Belong to Us

← →
ketmar © (2009-01-24 23:56) [10]

>[9] ketmar © (2009-01-24 23:55:00)
последний пункт — «г», конечно же (гусары!)

---
Do what thou wilt shall be the whole of the Law.

← →
vuk © (2009-01-25 00:00) [11]

to Unknown user © (24.01.09 22:17):
>Подобным образом устроена система сообщений Windows, однако она
>работает только с оконными элементами управления.
Не только. Еще и с потоками.

>По сути, мы имеем набор объектов, которые могут быть представлены как
>«черные ящики». Нам не важно как объект устроен, важно только чтобы он
>определенным образом реагировал на входные сообщения, генерируя
>выходные сообщения или выполняя любые другие заданные действия. При
>этом вся отладка взаимодействий объектов сводится к отладке внутренних
>функций объекта и его реакций на сообщения.
Хм... Заменим понятие сообщения на понятие вызова и получим классический подход. Что при этом поменялось? А ничего. Ящик остался ящиком. И стоило огород городить?

← →
Mystic © (2009-01-25 00:03) [12]

> Круто. Создатели преследовали идеи, которые я изложил выше
> или причина такого подхода в ином?

Ты изложил идеи в терминах процедурного языка программирования, а в Smalltalk даже условного оператора нет. Есть отправка сообщения объекту типа Boolean, в котором два параметра: блок кода, который надо выполнить в случае, если значение переемнной равно True, и блок кода, который надо выполнить в случае, если значение переменной равно False

← →
dmk © (2009-01-25 00:07) [13]

>Ключевым элементом для описания взаимодействия объектов является событие.
Я так 7 лет назад писал. + Фотошоп так устроен, + все пакеты Adobe CS так устроены. И чего тут нового? ИМХО нормальный классический подход.

← →
Eraser © (2009-01-25 00:09) [14]

> [0] Unknown user © (24.01.09 22:17)

> Модель приложения, основанная на сообщениях.

> Предлагаю подисскутировать на указанную тему.

а что тут дискутировать то? ) если кому то умолешенном взбредет в голову целиком всю логику реализовывать на сабже - посочувствую. а в целом, если инструмент применить в нужном месте - может весьма облегчить жизнь.

← →
ketmar © (2009-01-25 00:10) [15]

>[12] Mystic © (2009-01-25 00:03:00)
есть ли смысл пояснять?

---
Do what thou wilt shall be the whole of the Law.

← →
Игорь Шевченко © (2009-01-25 00:10) [16]

> Для организации взаимодействия объектов используются сообщения.
> Сообщения передаются и принимаются объектами при помощи
> специального объекта – диспетчера сообщений TAppDispatcher.
> Диспетчер содержит список всех зарегистрированных объектов,
> участвующих в обмене сообщениями. Каждый из зарегистрированных
> объектов получает ссылку на объект – диспетчер и взаимодействует
> только с ним, через функции отправки и получения сообщений.
> Каждое сообщение содержит ID отправителя и получателя.
> Если вместо ID получателя указано 0 – сообщение широковещательное
> и адресуется всем зарегистрированным в диспетчере объектам

И нафиг это надо ?

← →
ketmar © (2009-01-25 00:12) [17]

>[16] Игорь Шевченко © (2009-01-25 00:10:00)
>И нафиг это надо ?
сделать из языка со статический типизацией эмулятор динамического. ректальный, как обычно.

---
Understanding is not required. Only obedience.

← →
Unknown user © (2009-01-25 00:15) [18]

>Игорь Шевченко

Переход к ассинронному исполнению, многопоточность.

← →
Игорь Шевченко © (2009-01-25 00:21) [19]

ketmar © (25.01.09 00:12) [17]

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

Unknown user © (25.01.09 00:15) [18]

> Переход к ассинронному исполнению, многопоточность.

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

Я повторю вопрос: А нафиг это надо ?

То есть, если не трудно, парочку примеров, где твой подход дает сщественный выигрыш по сравнению с традиционным.

← →
ketmar © (2009-01-25 00:31) [20]

>[19] Игорь Шевченко © (2009-01-25 00:21:00)
>Любой "эмулятор динамической типизации" есть безусловное зло.
ППКС.

---
Do what thou wilt shall be the whole of the Law.

← →
Unknown user © (2009-01-25 00:42) [21]

>Игорь Шевченко

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

← →
Игорь Шевченко © (2009-01-25 01:33) [22]

Unknown user © (25.01.09 00:42) [21]

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

Э..пример будет ? Типа что "такая-то задача при решении традиционным образом глючит и тормозит а при моем подхоже наичнает безошибочно летать".

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

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

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

← →
Медвежонок Пятачок © (2009-01-25 02:12) [23]

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

← →
int64 (2009-01-25 11:12) [24]

Unknown user © (24.01.09 22:17) 0

> Так как в сложных системах, при классическом подходе, невозможно
> разделить функциональность между объектами сохранив при
> этом их независимость.

Любая система при любом подходе должна разделять функциональность между объектами, сохраняя их независимость.

← →
ketmar © (2009-01-25 15:31) [25]

>[24] int64 (2009-01-25 11:12:00)
прям таки так? просто таки обязана?

---
All Your Base Are Belong to Us

← →
int64 (2009-01-25 17:27) [26]

Ну, да. Именно так. А что тебя удивляет?
Ты первый раз это слышишь? Или не был согласен с этим раньше?
Я больше скажу: "И СЦЕПЛЕНИЕ между объектами обязано быть как можно тоньше".
Вот.
http://en.wikipedia.org/wiki/Coupling_(computer_science)

← →
@!!ex © (2009-01-25 18:06) [27]

> [26] int64 (25.01.09 17:27)

Ой... Истина в последней инстанции...
А вы не пророк случаем? :))

← →
Alkid © (2009-01-25 18:20) [28]

Снова встряну. Господам интересующимся, сомневающимся и восхищающимся Actor Model"ю советую посмотреть в сторону Erlang.

← →
int64 (2009-01-25 18:34) [29]

> @!!ex © (25.01.09 18:06) [27]
> > [26] int64 (25.01.09 17:27)
>
> Ой... Истина в последней инстанции...
> А вы не пророк случаем? :))

Я проповедник.
Проповедовать азбучные истины труднее всего - их сложно доказывать.

> [29] int64 (25.01.09 18:34)

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

> Игорь Шевченко © (25.01.09 01:33) [22]
> Я извиняюсь еще раз, программисты не создают "мультипоточные
> приложения путем использования потокобезопасных классов",
> они вполне конкретные задачи решают. Вот на примере чего-
> то конкретного и хотелось бы уяснить преимущества предлагаемой
> модели объектов и сообщений промеж них, причем, диспетчируемых
> через единственное место.

"Диспетчеризация через одно место" :))))

Ладно, если серьёзно, то на Actor Model построен язык Erlang на котором корпорация Эриксон пишет софт для своих телекоммуникационных задач. Язык изначально создавался для реализации высоконадежных систем и очень распараллеленых систем.

Вот тут про него написано в обзорном порядке: http://en.wikipedia.org/wiki/Erlang_(programming_language)

Alkid © (25.01.09 20:48) [31]

Я в курсе про Erlang - в смысле, читал про него обзорные статьи.

Речь не о том, у нас сайт вроде про delphi и предложение свое автор (по моему скромному мнению) делает тоже в рамках программирования на Delphi.

Поэтому еще раз - мне бы хотелось уяснить преимущества подхода автора на конкретных примерах на Delphi (не на Erlang, не на APL, не на INTERCAL),
потому как мне кажется одной диспетчеризацией сообщений заместо прямого взаимодействия из Delphi Erlang никак не получить.

> Игорь Шевченко © (25.01.09 21:01) [32]

Да, я понимаю. Просто Эрланг представляет собой некую квинтэссенцию идей, часть которых может быть реализована на Дельфи. В частности, когда я реализовывал подобные схемы, получались следующие бонусы:

Сильная изоляция объектов друг от друга. Объекту-источнику сообщения надо было знать минимум или ничего о приемнике (приёмниках) сообщения. Для разных уведомлений, действующих по принципу "выстрелил и забыл" - самое то. Облегчение программирования асинхронной работы (при сохранении возможности синхронного вызова через тот же диспетчер). Повышение уровня изоляции объектов так же снижало воздействие ошибок в одном объекте на другой. Динамическая диспетчеризация вызовов, duck typing. В перспективе планировалось так же на основе этого диспетчера реализовать абстрагирование местоположения объекта, т.е. реализовать распределённость.

Вместе с тем наблюдались и отрицательные стороны такой организации:
1. Большое количество инфраструктурного кода, который приходилось писать руками (вот где шаблонов и метапрограммирования не хватало!)
2. Затрудненность отладки асинхронных и, отчасти, схем взаимодействия.
3. Снижение производительности.

Alkid © (25.01.09 22:10) [33]

Я вижу еще одну отрицательную сторону - ослабление контроля за типизацией со стороны компилятора и, как следствие, перенос обнаружения ошибок с времени компиляции на время выполнения.

> Игорь Шевченко © (25.01.09 22:27) [34]

Ты знаешь, это вопрос крайне неоднозначный. Есть люди, которые считают статическую типизацию злом и в их аргументах есть своё рациональное зерно. Если интересно: http://www.mindview.net/WebLog/log-0025

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

С одной стороны: чем проще - тем лучше. С другой стороны (особенно, когда пишем движок): чем общнее - тем лучше.

Резюме: на задачу надо смотреть. Поэтому все споры в отрыве от задачи - бессмысленны.

Alkid © (25.01.09 22:45) [35]

> Ты знаешь, это вопрос крайне неоднозначный. Есть люди, которые
> считают статическую типизацию злом и в их аргументах есть
> своё рациональное зерно

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

>Alkid

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

Мы живем в мире, состоящим из взаимодействующих объектов. Это основной довод в пользу ООП. Программа стает более структурируемой и понимаемой, если объединить вместе в один объект данные и процедуры/функции. Один из китов ООП это инкапсуляция. То есть сокрытие реализации внутри объекта. Если эту идею развить до совершенства, то и сами объекты должны быть изолированы друг от друга.

Читал-читал сабж..
Извиняюсь за грубость, но создалось впечатление, что автор решил показать тут себя крутым "науковцем" и накрокозябрил этажеркой толпу силлогизмов, мало соотносящихся как друг с другом, так и с практическими проблемами программирования в Делфи.
Причем там вообще потоки - не понял совершенно. Т.е. если юзер переводит фокус из одно эдита в другой, то обработку событий потери фокуса надо делать в одном потоке, а получение его други - в другом ?

Вообще потоки надо воспринимать как ДОПОЛНИТЕЛЬНЫЕ возможности распараллирования естественно там, где оно, это распараллирование, необходимо. Причем тут взаимодействие на уровне визуальных объектов - вообще непонятно.

> Мы живем в мире, состоящим из взаимодействующих объектов.
> Это основной довод в пользу ООП. Программа стает более
> структурируемой и понимаемой, если объединить вместе в один
> объект данные и процедуры/функции. Один из китов ООП это
> инкапсуляция. То есть сокрытие реализации внутри объекта.
> Если эту идею развить до совершенства, то и сами объекты
> должны быть изолированы друг от друга.

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому что им известны эти способы и они умеют ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне затрудняется их просмотр и анализ ментальной модели, которую по существу реализует код. Всецело нарушаются правила простоты, ясности и прозрачности, а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения правила представления. С этой точки зрения множество классов приравнивается к внедрению знаний в данные. Проблема данного подхода заключается в том, что слишком часто "развитые данные" в связующих уровнях фактически не относятся у какому-либо естественному объекту в области действия программы - они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них предметных областей (GUI-интерфейсы, моделирование, графические средства), возможно, является то, что в этих областях относительно трудно неправильно определить онтологию типов. Например, в GUI-интерфейсах и графических средствах присутствует довольно естественное соответствие между манипулируемыми визуальными объектами и классами. Если выясняется, что создается большое количество классов, которые не имеют очевидного соответствия с тем, что происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим."
(с)

Модель приложения, основанная на сообщениях. Найти похожие ветки