вас наверно путает отличие классического интерфейса от системы сообщений ?

ну с классическим все как бы понятно.. 
http://liveworkspace.org/code/1f1605eb39d1...9fd8e704db01c7f

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

для начала разгрузим через функции 
http://liveworkspace.org/code/1d220cb1240b...a2503e8f7cccc23

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

П.С. оператор, используем, так как оператор. не перегружаем..


следующий шаг это функторы :

http://liveworkspace.org/code/e2b08967aa19...441f61144050136

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


Это сообщение отредактировал(а) mes - 25.11.2010, 23:47

вот мы добились теперь целостности интерфейса :
  http://liveworkspace.org/code/f4279497086c...c0009551a5ec23e

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

Добавлено через 11 минут и 24 секунды
вот  у нас независимость от того какой из хэндлеров реализует поведение функции :
http://liveworkspace.org/code/00d5dc2a7dc1...fffd4e435c48c85

вот внешне сохранив вид интерфейса, пришли к более удобной (для распределенного программирования) "технологии" событий.. 
   

это основное.


как-то двусмысленно  

ну и самая мелочь.. так как точку нам пергрузить нельзя, а запятая не очень логична, то следует подобрать более подходящий оператор.. например << :
http://liveworkspace.org/code/25dea7a061ec...b1f94957a3d994e

Добавлено @ 00:12

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

Добавлено @ 00:12
сейчас попробую более подходящие примеры подобрать..

Добавлено @ 00:14
вот например сортировка.. ясно что ей нужен предикат и какими требованиями он должен обладать.. 
наличие например в предикате вывода в консоль, это не предпологаемое поведение.. 
т.е в данном случае нам подходит классический делегат (колбяк)

Добавлено @ 00:16
а вот например дернул пользователь мышку.. кто именно будет обрабатывать эту ситуацию и как - неизвестно.. 
(имеется ввиду пользовательский уровень)..  тут подходит  - событие..

Добавлено через 12 минут и 13 секунд
если для делегата важно наличие некоего интерфейса, посредством которого, он будет выполнять желания объекта..
то в случае с событием, объект сам знает что ему делать, и смотрит лишь что произойдет (ждет события).. 



Это сообщение отредактировал(а) mes - 26.11.2010, 00:18

вот модель делегирования:


Добавлено @ 00:30
это событийная модель :

среда не несет знаний о поведении...

Это сообщение отредактировал(а) mes - 26.11.2010, 00:32

ну вот например.. съимитируйте поведение через классические интерфейсы.. 
http://liveworkspace.org/code/9e5d8b87f078...257ff54be6cf0e4

Добавлено через 1 минуту и 25 секунд
при этом t1, t2 t3 могут быть разных типов, главное поддержка интерфейса 

соединение пусть пока так подключается  к другому (или само на себя) :


http://liveworkspace.org/code/d777ee9f6841...f5de734a9bc669a

Это сообщение отредактировал(а) mes - 26.11.2010, 02:08

вникаю..

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

http://liveworkspace.org/code/a6738364943c...3d3911a522284cf

fn - обработчик текущего уровня.. 
fw - передача на нижеследующий уровень..

Добавлено @ 10:17


это можно затуплить и форичить.. тогда составление иерархии можно будет автоматизировать..

Это сообщение отредактировал(а) mes - 26.11.2010, 10:42

примерно так :
http://liveworkspace.org/code/fa80f69f7186...337f4523435ac2e

Это сообщение отредактировал(а) mes - 26.11.2010, 10:44

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

и тогда передача по сети будет


Это сообщение отредактировал(а) mes - 27.11.2010, 14:07

жесть какая, 43 страницы
вы когда закончите, напишите вкратце решение проблемы, а то всё читать долго =\

mes, спасибо. я тут. не забил. работаю.

я понимаю.. просто как появляется как идея сразу отмечаю 

решение будет лежать тут: http://code.google.com/p/discoly/

Добавлено через 25 секунд

еще раз спасибо.

Добавлено через 1 минуту и 49 секунд

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