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


"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому что им известны эти способы и они умеют ими пользоваться.
Все ОО-языки несколько сколнны "втягивать" программистов в ловушку избыточной иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне затрудняется их просмотр и анализ ментальной модели, которую по существу реализует код. Всецело нарушаются правила простоты, ясности и прозрачности, а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения правила представления. С этой точки зрения множество классов приравнивается к внедрению знаний в данные. Проблема данного подхода заключается в том, что слишком часто "развитые данные" в связующих уровнях фактически не относятся у какому-либо естественному объекту в области действия программы - они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них предметных областей (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]

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