Делегирование — это основной шаблон проектирования. Это позволяет разделить обязанности между частями вашей программы. Идея состоит в том, что та часть вашей программы, которая, например, рисует на экране, вероятно, не должна общаться с вашей базой данных. На это есть несколько причин:
Производительность: если тот же объект, который рисует на экране, обращается к вашему хранилищу данных, вы столкнетесь с проблемами производительности. Период. Полная остановка.
Сопровождение кода: легче концептуализировать правильно модульный код. (Для меня, во всяком случае)
Гибкость: Если вы создаете подклассы в своем коде, это прекрасно, пока вы не начнете сталкиваться с монолитными классами, которые имеют все виды нежелательного поведения. Вы достигнете точки, когда вам придется перегружать поведение, чтобы отключить вещи, и ваше пространство имен свойств может стать загрязненным. Попробуйте категории, делегирование и блоки для альтернатив.
Тем не менее, я действительно столкнулся с ситуацией, когда подклассы были уместны. У меня есть киоск-приложение, в котором я хотел автоматически закрыть определенное меню настроек, если с ним не взаимодействовали в течение определенного периода времени. Для этого мне нужно было иметь доступ к сенсорным событиям во всем приложении. Я создал подкласс UIApplication и переопределил sendEvent:. Тогда это было уместно, хотя это крайний случай. Как сказал царь Соломон в Екклесиасте, перефразируя: «Всему свое время и место под солнцем».
Чтобы упростить написание, чтение, повторение и поддержку вашей программы, настоятельно рекомендуется следовать определенным правилам. Вы можете создавать подклассы многих классов, и Apple не отклонит ваше приложение из-за плохого кода при условии, что оно работает так, как рекламируется. Тем не менее, если вы не соблюдаете проверенные и проверенные методы, вы копаете себе могилу. Подклассы по своей сути не плохи, но категории, протоколы и блоки настолько увлекательны, что я бы предпочел их в любом случае.
person
Moshe
schedule
07.05.2013
