Привет всем, а вот поделитесь опытом, в каких случаях стоит

использовать именно event dispatcher? , а то я как то всё на интерфейсах делаю.

две совершенно не связанные вещи

Блин, блин, блин, да откуда вообще пошла эта битва диспатчеров и интерфейсов? Между ними вообще ничего общего нет, это совершенно разные технологии. Может в сети какой-то тутор есть, после которого все начинают задаваться этим вопросом?

ну наверно типо для коммуникации между классами

Коротко диспетчер ничего не знает о тех кто будет обрабатывать сообщение. Для интерфейса нужен конкретный объект

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

ну я не задал вопрос, я предположил просто.

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

привязка на событие

И...

ну в этом случаи я бы сделал делегат

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

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

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

но он освобождает от зависимости того, полем которого является этот делегат

Ну да, о чём я и написал, то обратная зависимость сохраняется :)