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

← →
Игорь Шевченко © (2009-01-26 01:05) [40]

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

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

← →
Unknown user © (2009-01-26 01:09) [41]

>MsGuns

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

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

← →
vuk © (2009-01-26 01:15) [42]

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

← →
Юрий Зотов © (2009-01-26 01:53) [43]

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

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

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

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

← →
Германн © (2009-01-26 02:18) [44]

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

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

← →
vuk © (2009-01-26 02:30) [45]

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

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

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

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

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

← →
Городской Шаман (2009-01-26 03:17) [47]

> Unknown user © (24.01.09 22:17)

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

← →
Unknown user © (2009-01-26 10:30) [48]

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

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

← →
Alkid © (2009-01-26 12:19) [49]

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

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

← →
Юрий Зотов © (2009-01-26 12:20) [50]

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

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

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

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

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

← →
Unknown user © (2009-01-26 12:26) [51]

>Юрий Зотов

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

← →
vuk © (2009-01-26 12:32) [52]

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

← →
Юрий Зотов © (2009-01-26 12:43) [53]

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

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

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

← →
int64 (2009-01-26 12:56) [54]

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

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

← →
Юрий Зотов © (2009-01-26 12:57) [55]

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

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

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

← →
vuk © (2009-01-26 12:58) [56]

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

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

← →
Юрий Зотов © (2009-01-26 13:07) [57]

> 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]

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

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

← →
Городской Шаман (2009-01-26 18:40) [61]

> 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.

← →
Городской Шаман (2009-01-27 00:56) [63]

> 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

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