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

Создавая сложные проекты, разработчики в первую очередь сталкиваются с отладкой взаимосвязей между объектами приложения. Так как в сложных системах, при классическом подходе, невозможно разделить функциональность между объектами сохранив при этом их независимость. Сложные взаимосвязи объектов порождают циклические ссылки между модулями, запутывают код программы, понижают ее надежность. Кроме того, такой код тяжело распараллелить и выполнять в нескольких потоках. Ключевым элементом для описания взаимодействия объектов является событие. В 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]


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


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

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

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

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

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

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

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

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


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


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

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


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


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

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

Unknown user ©   (24.01.09 22:17)  0

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

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

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

---
All Your Base Are Belong to Us

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

> [26] int64   (25.01.09 17:27)

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

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

> @!!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-интерфейсах и графических средствах присутствует довольно естественное соответствие между манипулируемыми визуальными объектами и классами. Если выясняется, что создается большое количество классов, которые не имеют очевидного соответствия с тем, что происходит на экране, то, соотвественно, легко заметить, что связующий уровень
стал слишком большим."
(с)

>MsGuns

Ну тему я запостил в раздел Прочее, можно значит, и пофилософствовать :) Речь была не о визуальных контролах.

Допустим у нас есть многооконный графический редактор. Выделим 3 объекта: инструмент рисования, мышь и строка состояния. Эти объекты взаимодействуют между собой. При перемещении указателя мышки инструмент рисует линию, строка состояния показывает координаты курсора. Вот мне интересно как будет работать такое решение. Объекты передают друг-другу сообщения. Мышь отсылает широковещательные сообщения при изменении координат указателя. Эти сообщения принимает инструмент рисования, преобразовывая в координаты линии. Эти же сообщения принимает строка состояния. В данном случае объекты совершенно ничего не знают друг о друге. Они лишь умеют принимать, передавать и обрабатывать сообщения.

to Unknown user ©   (26.01.09 01:09) [41]:
>Вот мне интересно как будет работать такое решение.
Фигово будет работать. Потому как строка состояния должна показывать не абы какие координаты мыши, а относительно, например, текущего документа, или например, должна показывать длину линии.

Все же не понимаю, о чем тут спорить.

Идея эта далеко не нова. На сообщениях работает GUI (и не только GUI) Windows. В J2EE на уровне промышленного фреймворка специфицирована (и не единожды реализована) поддержка MDB (message driven bean - объекты, управляемые сообщениями). Еще есть WebShere MQ. И т.п.

Так что все это не ново, все давно исхожено и в каких-то задачах давно доказало свою применимость и полезность. В других же задачах - наоборот, на фиг не нужно и только ведет к лишнему усложнению (и/или тормозам).

Поэтому все зависит от задачи и спорить, по сути, не о чем. Это спор по поводу того, что лучше - грузовик или велосипед?

> Это спор по поводу того, что лучше - грузовик или велосипед?
>
>

Не очень внимательно читал, но по-моему это спор о том, что больше весит: метр или секунда?

to Юрий Зотов ©   (26.01.09 01:53) [43]:
>Так что все это не ново, все давно исхожено и в каких-то задачах давно
>доказало свою применимость и полезность.

Так об чем и речь. Если применять по делу. А если применять технологию только для того, чтобы её применить, то получаются графические редакторы, у которых строка состояния что-то там сама по себе показывает.

> то получаются графические редакторы, у которых строка состояния
> что-то там сама по себе показывает.


асинхронно и в отдельном потоке

> Unknown user ©   (24.01.09 22:17)  


Хорошая система, сам реализовывал на Delphi (отсылка сообщений, где сообщение объект в пределах процесса). Хотя принцип довольно старый, реализованный еще в 80-х годах, язык Smalltalk.

>Городской Шаман

Вот тут все пытаются выяснить какой в этом практический смысл? В чем улучшение по сравнению с традиционным в Делфи подходом? И действительно я когда начинаю искать преимущества, понимаю, что это только приводит к усложнению кода, добавляется еще один элемент, потенциально вносящий ненадежность. И ничего кроме абстрактных размышлений выдать не получается. Хотя понимаю, что решение красивое, кроме того узнал, благодаря здешним мастерам, что уже неоднократно реализованное (Actor Model, smalltalk, ...). Недостатки его понятны. Каковы же все таки достоинства?

> Игорь Шевченко ©   (26.01.09 00:04) [37]
> Весьма вероятно, что есть разные люди с разными точками
> зрения и с разными аргументами. В том числе и рациональными.
>  Есть и языки с нестрогим контролем типов и есть языки вообще
> без контроля типов.
> Но у контроля типов есть одно преимущество - компилятор
> ошибается гораздо реже, чем человек, а соответствие типов
> проверяет куда как быстрее - так дадим же ему делать эту
> нудную работу.
> В больших проектах строгая типизация вносит свой вклад в
> обнаружение ошибок, отсеивая какую-то часть - а чем больше
> отсеется, тем лучше.

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

> Каковы же все таки достоинства?

Вилли Фаррел, ведущий инженер-программист IBM, в своей статье по JMS (Java Message Service) основными достоинствами этого подхода называет его гибкость и слабое связывание.

"Реальная мощь корпоративных систем обмена сообщениями заключается в слабом связывании (loose coupling) приложений. На диаграмме из предыдущего раздела Приложение А передает сообщение, указывая конкретный адресат, например, "обработка заказа". Сейчас функцию обработки заказов обеспечивает Приложение B.

Но в будущем мы можем заменить Приложение B другой программой обработки заказов, а Приложение А не будет умнее. Оно по-прежнему будет продолжать передавать свои сообщения для "обработки заказов", а сообщения будут продолжать обрабатываться.

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

>Юрий Зотов

Ага, согласен. Вы не знаете, для Делфи уже есть готовые реализации Actor Model или аналогичного подхода?

to Юрий Зотов ©   (26.01.09 12:20) [50]:
Чем всё это отличается от контракта на уровне вызовов, реализованного, например, через интерфейс?

> vuk ©   (26.01.09 12:32) [52]

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

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

> vuk ©   (26.01.09 12:32) [52]
> to Юрий Зотов ©   (26.01.09 12:20) [50]:
> Чем всё это отличается от контракта на уровне вызовов, реализованного,
>  например, через интерфейс?

Можно я отвечу?
Наверное, как DCOM отличается от COM+

> Unknown user ©   (26.01.09 12:26) [51]

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

Хотя готовые, отлаженные движки, возможно, предпочтительнее.

to Юрий Зотов ©   (26.01.09 12:43) [53]:
Не Юр, это все понятно, но только в твоей цитате ни слова про асинхронность. Там только про то, что приложение А отправляет сообщения, а приложение B принимает. То есть это тот же контракт, но реализованный в другой форме. И с некоторым минусом. Если никто не принимает сообщения приложения А, то, вроде бы, считается, что всё в порядке. Так ли оно на самом деле?

А так, оно конечно да, для всяких нотификаций оно вполне приемлемо. У меня свой сервис простенький есть, с группами, подписками и т.д. Обеспечивает, при необходимости, в том числе и обратную связь от сервера к клиентам.

> vuk ©   (26.01.09 12:58) [56]

> Так ли оно на самом деле?

Зависит от возможностей движка и их использования в прикладном коде. Например, движок может посылать (в том числе автоматически) подтверждение приема, группа сообщений может обрабатываться в рамках одной транзакции и т.п. В реальных движках много всего понакручено.

Alkid ©   (26.01.09 12:19) [49]


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


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

> Игорь Шевченко ©   (26.01.09 13:24) [58]

Отнюдь. Фишка в том, что юнит-тестирование необходимо разрабатывать для программ, написанных на языках как с динамической, так и со статической типизацией, причём объём этих тестов зависит не от типа языка, а от задачи.

Alkid ©   (26.01.09 13:41) [59]


> причём объём этих тестов зависит не от типа языка, а от
> задачи.


Это спорное утверждение

> Unknown user ©   (26.01.09 10:30) [48]
>
> >Городской Шаман
>
> Вот тут все пытаются выяснить какой в этом практический
> смысл? В чем улучшение по сравнению с традиционным в Делфи
> подходом? И действительно я когда начинаю искать преимущества,
>  понимаю, что это только приводит к усложнению кода, добавляется
> еще один элемент, потенциально вносящий ненадежность. И
> ничего кроме абстрактных размышлений выдать не получается.
>  Хотя понимаю, что решение красивое, кроме того узнал, благодаря
> здешним мастерам, что уже неоднократно реализованное (Actor
> Model, smalltalk, ...). Недостатки его понятны. Каковы же
> все таки достоинства?


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

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

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

>[26] int64 (2009-01-25 17:27:00)
>Ну, да. Именно так. А что тебя удивляет?
а то, что ты, видимо, прилетел к нам из параллельного мира, где компы обладают бесконечно большим быстродействием и такой же бесконечно большой памятью. ничего, попишешь софт для нашей убогонькой техники — забудешь про сферических коней из теории. заодно отучишься применять квантор общности где надо и где не надо.

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

> ketmar ©   (27.01.09 00:47) [62]
>
> >[26] int64 (2009-01-25 17:27:00)
> >Ну, да. Именно так. А что тебя удивляет?
> а то, что ты, видимо, прилетел к нам из параллельного мира,
>  где компы обладают бесконечно большим быстродействием и
> такой же бесконечно большой памятью. ничего, попишешь софт
> для нашей убогонькой техники — забудешь про сферических
> коней из теории. заодно отучишься применять квантор общности
> где надо и где не надо.


Сейчас писать по для работы на процессоре менее PIII-1000 не имеет смысла, так как таких компьютеров уже почти не осталось. И человек, который не может купить сегодня компьютер мощнее, точно не купит ПО, дороже 5$ за копию.

Конечно я не имею в виду embeded-системы, но там все совсем по другому.

>[63] Городской Шаман (2009-01-27 00:56:00)
и каким образом это относится к моему тексту? что, между 1 гигагерцем и бесконечностью разницы совсем нет? что, это как-то оправдывает необоснованое применение квантора общности?

---
All Your Base Are Belong to Us