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

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

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

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

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

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

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

Smalltalk изучал?

>Alkid

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

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

>Mystic

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

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

>TUser

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

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

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

>Mystic

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

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

---
All Your Base Are Belong to Us

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

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

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

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

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


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

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

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


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


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

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

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

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

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


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

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

---
Understanding is not required. Only obedience.

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

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

ketmar ©   (25.01.09 00:12) [17]

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

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


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


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

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

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