Multiple Delegate

[svyatogor]

Отличный разбор проблемы! Заодно стало яснее процедура обработки сообщений.

ИМХО практика использования делегатов конечно убога, по сравнению с событиями в том же C#, но деваться некуда, пока лишь небольшая часть API перешла на использования блоков в качестве колбэков.

[Nodepad]

Вам не кажется, что было бы гораздо проще и выразительнее создать UIView, которая бы агрегировала UITextField, и перенаправлять все вызовы делегата ручками?
Message forwarding и objc-рантайм — это, конечно, очень мощные инструменты, но читать, поддерживать и отлаживать такой код потом становится сложно, даже человеку, его написавшему. Если же вам в действительности нужно множественное делегирование, то стоит его реализовать более выразительно и предсказуемо.

[Fanruten]

Мне показалось, что Multiple Delegate будет интересен в качестве примера.

А так, в тексте прям предложение есть

Пример немного притянутый, но все же.

[Yan169]

mainDelegate объявлен как weak. Что будет, если он умрет раньше, чем прокси? Правильно: doesNotRecognizeSelector: (uncaught exception).

Это стандартные грабли, на которые натыкаешься при играх с NSProxy и делегированием. Обойти которые можно через предварительное создание кэша сигнатур возможных селекторов, чтобы даже если все делегаты умерли, можно было успешно завершить форвардинг без крэша. А поскольку создавать кэш для вообще всех возможных сигнатур нелепо, в инициализатор прокси обычно передают протокол, из которого (и рекурсивно из всех родительских протоколов) выдергиваются сигнатуры для обязательных и опциональных методов.

Я делал практически то же самое в своей библиотечке FastElegantDelegation. Также можно посмотреть пример с сингл-прокси в библиотечке PSTDelegateProxy, где к слову изначально была та же проблема.

[Fanruten]

Большое спасибо за комментарий. Немного дополнил статью.

[Yan169]

А если главный делегат не реализует опциональный метод протокола, а один из дополнительных — да?
Тут граблей много. :)