2011-01-03 2 views
24

Теперь, когда блоки, наконец, поддерживаются для разработки iphone/ipad, полностью ли они устраняют необходимость в делегатах или же делегаты по-прежнему более чисты в качестве полной реализации интерфейса, в то время как блоки более подходят для одиночных задач?Кодовые блоки полностью заменяют делегатов?

ответ

9

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

Таким образом, я должен согласиться с комментарием «более подходящим для одиночных задач» (и даже тогда только определенными изолированными задачами).

40

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

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

EDIT: так, некоторые примеры:

UIScrollViewDelegate правильно протокол делегата, потому что (я) есть широкий спектр вещей, которые, возможно, должны быть сообщены; (ii) их, возможно, необходимо будет сообщать в любом порядке и в любое время; и (iii) они будут сообщены по причинам, не зависящим от делегата.

NSURLConnection +sendAsynchronousRequest:queue:completionHandler: правильно берет блок для доставки результатов, потому что (i) есть только один результат для отчета; и (ii) отчет возвращается как прямое следствие действий, предпринятых вызывающим.

+0

Пожалуйста, объясните немного больше, если будут какие-то примеры, которые были бы замечательными. Спасибо – Sandy

+0

Я не получил сообщение? – Sandy

+8

@ Sandy Я сторонник того, что блоки - это хороший способ доставить результаты конкретных действий, но плохая основа для более общего разговора. Предоставление блока похоже на слушателя, говорящего «так ты говоришь со мной»; протокол делегата похож на говорящего: «Вот как я буду говорить с тобой». Если говорящий в основном решает, когда говорить, тогда он должен диктовать, как он говорит. Если слушатель просто просит, чтобы что-то было сделано, и результаты сообщались тогда, имеет смысл, что он говорит «... и отчитывается так». – Tommy

8

Я пытался решить, оставить ли я комментарий к другим ответам или оставить свой ответ. Я решил, и вот он.

Я разработчик C#, прежде всего, поэтому я могу легко увидеть, как я могу заменить весь шаблон делегирования блоками, потому что C# всегда рассматривал глаголы как граждан первого класса. Фактически, это было одним из самых трудных вещей, с которым можно привыкнуть, когда я начал работать с Java и платформой Android. Этот опыт упростил, когда я узнал Objective-C и Cocoa.

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

Я не думаю, что нужно заменить другого. Я думаю, что два шаблона должны использоваться там, где каждый из них наиболее подходит; однако я нашел несколько случаев, когда я определенно предпочел бы шаблон наблюдателя над шаблоном делегирования в Cocoa.

Например, имея дело с результатом UIAlertView, я считаю, что он должен основываться на блоках вместо делегатов. Это всегда было для меня немного странным, но блок был недоступен, когда была разработана определенная часть API. В результате я никогда не был уверен, что Apple считает, что это должен быть предпочтительный подход или если это был единственный подход в то время.

Недавно я интегрировал GameKit в одну из своих игр и обнаружил, что большинство асинхронных вызовов (фактически, все, что я использовал) не используют делегатов; они используют блоки. Я бы предположил, что если они смогут переписать UIAlertView сегодня, они, скорее всего, будут использовать блоки вместо делегатов для обработки обратных вызовов после ввода пользователем. Конечно, это просто спекуляция.

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

+0

Отличный короткий ответ. – poiuytrez

+0

Действительно, в iOS 8 UIAlertView был изменен с помощью ViewController. И UIAlertViewController имеет действия, которые используют блоки. – dcorbatta

1

Я занимаюсь своими исследованиями по этому предмету, и я нашел эту статью очень поучительной, написанной Джастином Дрисколлом, и я надеюсь, что она тоже поможет кому-то другому.

Вот ссылка: Communicating with Blocks in Objective-C

0

Делегаты - Вы можете использовать делегат, если вы хотите знать процесс/События/государства. Например, в NSURLConnectionDelegate вы получите статус данных с двумя или более методов делегата .didReceive: NSData connectionDidFinishLoading

блоки - Вы можете использовать блок только тогда, когда вы ожидаете результат или ошибку

Лучшие ссылки - http://blog.stablekernel.com/blocks-or-delegates/