Шаблон декоратора для UITableViewCell

Question

Мне было интересно, пытался ли кто-нибудь когда-либо пытаться использовать шаблон декоратора, чтобы облегчить высушивание кода UITableView.

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

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

Имеет ли это смысл, или я просто воссоздаю колесо? Мне действительно не нравится создание подклассов UITableViewCells, и я думаю, что это был бы хороший способ обойти эту проблему.

Мне бы очень хотелось услышать мнение некоторых из вас, ребята, которые имеют гораздо больше опыта Objective-C и UIKit, чем я по этой теме.

Answer 1

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

Посмотрите, как Мэтт Галлахер обрабатывает пользовательский рисунок ячейки , его подход был благословлен Apple на WWDC в этом году.Кроме того, посмотрите «Советы и рекомендации по улучшению отзывчивости» и «Понимание рендеринга UIKit» сеансов из WWDC , так как они касаются реальных методов повышения производительности UITableView.

Answer 2

Разве шаблон декоратора обычно не основан на абстрактной базе или интерфейсе / протоколе в корне?Так как ваша база здесь не подлежит обмену (это должно быть UITableViewCell), это может быть сложно.

Может быть, вы можете сделать это с помощью прокси, то есть создать подкласс NSProxy, чтобы обернуть UITableViewCell.Я не знаю, сработает ли это, поскольку классы UIKit, как правило, довольно тесно связаны друг с другом.Прокси и реальная ячейка будут иметь разные идентификаторы, и если ячейка отправляет сообщения в табличное представление с self в качестве аргумента, это может привести к путанице в табличном представлении.

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

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

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