Обмен сообщениями/событиями в приложении

[Woolf]

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

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

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

[Johnson]

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

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

Имхо, бред и домыслы. По крайней мере на счет "прогрессивных".
Условия - это операторы ассемблера. Пытаться не использовать процессорные команды - бред.
Да и без условий все равно не обойтись, иначе как вы будете проверять, нужное ли действие выполнить?
А делегаты (как и большинство способностей отражений) - всего лишь хорошее подспорье для соблюдения закона Деметры и принципов ООП в целом.

По мне, так делегаты только мешают отследить логику работы скрипта.

Я понимаю, что это личное мнение, но моё мнение несколько другое. Делегаты очень даже удобны и, мне кажется, наоборот помогают в осознании логики работы.
Тут срабатывает правило "Keep it simple" - нужно держать код простым. Плюс, как можно больше однотипных действий следует вынесено в отдельные методы - тоже одна из догм ООП.
Мне их очень не хватало именно в таком виде в джаве.
С выражением "не совать их куда попало" - соглашусь, нужно знать меру. К тому же они все равно несколько медленнее прямых вызовов.

PS: Макс, тебе не вредно будет полистать это.

[seaman]

Избавляться от if-ов путем повсеместного внедрения делегатов? Жесть!

[Макс]

Избавляться от if-ов путем повсеместного внедрения делегатов? Жесть!

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

[Woolf]

Плюс, как можно больше однотипных действий следует вынесено в отдельные методы - тоже одна из догм ООП.

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

[Макс]

Фига!

[Johnson]

Разве не ясно что свичи и условные операторы - они статичны! Они никуда из рабочего потока не денуться, и условия в них заложеные, переопределить не всегда возможно (а в свиче просто невозможно). Так же нельзя по желанию добавлять или удалять условия.
А с аналогом свича на делегатах, это делается легко. Это всё даёт необычайную гибкость.

Хоть один пример необходимости такой гибкости можешь привести?
Я лично не могу. И ни разу не требовалась такая реализация. Нужен гибкий выбор - это делается несколько по-другому. Да и непредусмотренный заранее выбор - это не всегда хорошо.

[DbIMok]

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

[Johnson]

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

Я тоже за их разумное использование (но не до фанатизма).
А ещё я за кеширование ссылок на объеты и скрипты (при надобности).

[Paul Siberdt]

Дык, сижу и не могу найти применения делегатам, когда все, что нужно и так грамотно хранится манагерами в ссылках. Обращайся - не хочу.

[Макс]

Фига!

[Johnson]

Ну вот пример пришёл на ум - это создание пользовательских наборов функций на лету:

Макросы всю жизнь делались на таблицах, картах или словарях.

[Макс]

Ну вот пример пришёл на ум - это создание пользовательских наборов функций на лету:

Макросы всю жизнь делались на таблицах, картах или словарях.

Ну это уж кто как любит и может. Кстати, в моём способе - словарь. Словарь делегатов.

[DbIMok]

все, что нужно и так грамотно хранится манагерами в ссылках.

мессенджер это тот же "манагер". помимо делегатов один и тот же функционал можно реализовать разными способами.

[broken]

Вот тут небольшое сравнение некоторых менеджеров сообщений
http://forum.unity3d.com/threads/173492-Comparison-of-Unity(C-)-Messaging-Events-Systems