Оптимизируйте свое приложение с шаблонами разработки
В программировании Objective C один способ добавить поведение, определенное для Вашего приложения, посредством наследования. Вы создаете подкласс существующего класса, или увеличивающего атрибуты и поведение суперкласса или изменяющего их в некотором роде. Но существуют другие, более динамические способы добавить специфичное для приложения поведение, которые не включают разделение на подклассы. Эти динамические методы и подходы основываются на шаблонах разработки. Поскольку это обвиняет, объясняет, принятие шаблонов разработки в Вашем коде способствует возможности многократного использования и расширяемости и Ваших классов и классов платформы.
Шаблон разработки: шаблон для проекта, решающего проблему программирования
Шаблон разработки является инструментом абстракции, используемой в объектно-ориентированной разработке программного обеспечения, а также других полях. Это - шаблон для проекта, решающего общую, повторяющуюся проблему в определенном контексте. Шаблон разработки является таким образом своего рода руководством для определенного, конкретного проекта: «инстанцирование» образца, в некотором смысле. Существует некоторая гибкость в том, как можно применить шаблон разработки, и часто вещи, такие как язык программирования и существующая архитектура могут определить, как применяется образец.
Несколько тем или принципов проекта влияют на шаблоны разработки. Эти принципы разработки являются эмпирическими правилами для построения объектно-ориентированных систем, тех, которые “инкапсулируют аспекты структуры системы, варьирующиеся” и “программа к интерфейсу, не реализация”. Они выражают важное понимание. Например, принцип инкапсуляции говорит, что, если Вы изолируете части системы, варьирующиеся и инкапсулирующие их, они могут варьироваться независимо от других частей системы, особенно если Вы определяете интерфейсы для них, которые не связываются к специфическим особенностям реализации. Можно позже изменить или расширить те переменные части, не влияя на другие части системы. Вы таким образом устраняете зависимости и сокращаете связи между частями, и следовательно система становится более гибкой и проще измениться.
Когда Вы пишете программное обеспечение, преимущества, такие как они делают шаблоны разработки важным рассмотрением. Если Вы будете находить, будете адаптировать и будете использовать образцы в проекте своего приложения, то то приложение — и объекты и классы, которые это включает — будет более допускающим повторное использование, более расширяемым, и проще измениться, когда будущие требования потребуют его. Кроме того, приложения, основывающиеся на шаблонах разработки, обычно более изящны и эффективны, чем программы, которые не являются, потому что они требуют, чтобы меньше строк кода достигло ту же цель.
Можно найти адаптацию шаблонов разработки всюду по Сенсорным платформам Какао и Какао и во время выполнения Objective C и язык. Некоторые из этих основанных на образце механизмов, которые Вы получаете почти «бесплатно», но другие требуют некоторой работы с Вашей стороны. И можно применить шаблоны разработки к коду собственного приложения, когда ситуация гарантирует его. При использовании тех же образцов, которые платформы используют, код имеет тенденцию согласоваться лучше с кодом и работой платформ более изящно.
Самый важный шаблон разработки: Контроллер представления Модели
Шаблон разработки Контроллера представления Модели (обычно известный как MVC) присваивает объекты в приложении одна из трех ролей: модель, представление или контроллер. Образец определяет не только ролевую игру объектов в приложении, это определяет способ, которым объекты связываются друг с другом. Каждый из трех типов объектов разделяется от других абстрактными границами и связывается с объектами других типов через те границы. Набор объектов определенного типа MVC в приложении иногда упоминается как уровень — например, уровень модели.
MVC является центральным к хорошему проекту для любого приложения. Преимущества принятия этого образца являются многочисленными. Много объектов в этих приложениях имеют тенденцию быть более допускающими повторное использование, и их интерфейсы имеют тенденцию быть лучше определенными. Приложения, имеющие проект MVC, также более легко расширяемы, чем другие приложения. Кроме того, много технологий и архитектуры, которую может использовать Ваше приложение, основываются на MVC и требуют, чтобы Ваши пользовательские объекты играли одну из ролей MVC.
Вы не можете знать о нем, но Вы уже создали приложение, основывающееся на MVC: TrackMix (в Вашем Первом Приложении Mac). Экземпляр Track класс является объектом модели; AppDelegate объект является объектом контроллера; и окно и все представления, которые это содержит, являются уровнем представления приложения.
Полная информация о Контроллере представления Модели находится в «Контроллере представления Модели» в Понятиях в Программировании Objective C.
Объект модели
Объект модели инкапсулирует данные приложения и определяет логику и вычисление, управляющие и обрабатывающие те данные. Например, объект модели мог бы представлять символ в игре или контакт в адресной книге. Иногда уровень модели приложения является эффективно одним или более графиками связанных объектов. Большая часть данных, которая является частью постоянного состояния приложения (ли то постоянное состояние сохранено в файлах или базах данных) должна находиться в объектах модели после того, как данные загружаются в приложение. Поскольку объекты модели представляют знания и опыт, связанные с определенной проблемной областью, они могут быть снова использованы в подобных проблемных областях. «Чистый» объект модели не должен иметь никакого явного соединения с объектами представления, представляющими его данные и позволяющими пользователям редактировать те данные — это не должно касаться проблем представления и пользовательского интерфейса.
Пользовательские действия в уровне представления, создающие или изменяющие данные, передаются через объект контроллера и результат в создании или обновлении объекта модели. Когда объект модели изменяется (например, новые данные получены по сетевому соединению), это уведомляет объект контроллера, обновляющий надлежащие объекты представления.
Объект представления
Объект представления является объектом в приложении, которое видят пользователи. Объект представления знает, как нарисовать себя и мог бы реагировать на пользовательские действия. Главная цель объектов представления состоит в том, чтобы вывести на экран данные от объектов модели приложения и включить редактирование тех данных. Несмотря на это, в представлении приложения MVC объекты обычно разъединяются от объектов модели.
Поскольку Вы обычно снова используете объекты представления и реконфигурировали их, просматриваете объекты, обеспечивают непротиворечивость между приложениями. Для OS X платформа AppKit обеспечивает наборы классов представления. В AppKit объект представления в конечном счете наследовался от NSView класс.
Объекты представления узнают об изменениях в данных модели через объекты контроллера приложения и передают инициируемые пользователями изменения — например, текст, введенный в текстовом поле — через контроллер, возражает против объектов модели приложения.
Объект контроллера
Объект контроллера выступает в качестве посредника между один или больше объектов представления приложения и один или больше его объектов модели. Объекты контроллера являются таким образом кабелепроводом, через который объекты представления узнают об изменениях в объектах модели и наоборот. Объекты контроллера могут также выполнить задачи установки и координирования для приложения и управлять жизненными циклами других объектов.
Объект контроллера интерпретирует пользовательские действия, сделанные, в поле зрения возражает и передает новые или измененные данные к уровню модели. Когда объекты модели изменяются, объект контроллера передает это новые данные модели к объектам представления так, чтобы они могли вывести на экран его.
Решение проблем с шаблонами разработки
Объектно-ориентированная система, такая как приложение является динамичной. Какой объект может сделать во время выполнения, не ограничивается набором поведения во время компиляции. Объект может отправить сообщения в другие объекты, и цель того же сообщения может варьироваться обстоятельством во время выполнения. Объект может также сотрудничать с переменной группой других объектов во время выполнения, с помощью множества методов, для эффективного выполнения работы приложения. Для объекта или сети объектов сделать это, это должно использовать в своих интересах много методов и архитектуры платформы, которая является адаптацией шаблонов разработки.
Следующие разделы описывают многие из этих методов и архитектуры. Считайте их частью Вашего Objective C, программируя инструментарий.
Делегация: действие от имени другого объекта
В делегации объект вызвал действия делегата от имени, и по требованию, другой объект. Это другой, делегирование, объект обычно является объектом платформы. В некоторый момент в выполнении, это отправляет сообщение своему делегату; сообщение говорит делегату, что некоторый случай собирается произойти и просит некоторый ответ. Делегат (обычно экземпляр пользовательского класса) реализует метод, вызванный сообщением, и возвращает надлежащее значение. Часто то значение является булевым значением, говорящим объект делегирования, продолжить ли с действием.
Делегация является таким образом средними значениями для введения специализированного поведения в работы класса платформы — не имея необходимость разделять тот класс на подклассы. Это - общий и мощный проект для расширения и влияния на поведение платформ.
Вспомните AppDelegate объект в приложении TracMix Вы создали при работе через Первое Приложение Mac. XCode автоматически присваивает его, чтобы быть делегатом объекта приложения. Делегат приложения обрабатывает applicationDidFinishLaunching: сообщение отправило к нему приложением.
Существует два программируемых компонента делегации. Класс делегирования должен определить свойство (условно названный delegate) содержать ссылку на делегата. Это должно также объявить протокол, который должен принять класс делегата (см. следующий раздел для больше на протоколах). Много классов платформ предлагают делегацию как подход, который приложения могут проявить для увеличения поведения платформы с чем-то, что является определенным для приложения.
Делегация, однако, не ограничивается классами платформы. Можно реализовать делегацию между двумя пользовательскими объектами в приложении.
Протокол: включение коммуникации между объектами, не связанными наследованием
Протокол является объявлением программируемого интерфейса, методы которого любой класс может реализовать. Экземпляр класса, связанного с протоколом, вызывает методы протокола и получает значения, возвращенные классом, формально принимающим и реализующим протокол. Эта коммуникация между объектами furthers определенная цель, такими как парсинг кода XML или копирование объекта. Объекты по обе стороны от интерфейса протоколов могут быть отдаленно связаны друг с другом наследованием. Протокол таким образом, как делегация, альтернатива разделению на подклассы и часто часть реализации платформы делегации.
Основы, которыми служит Apple, объявляют десятки протоколов. Кроме того, Ваше приложение может объявить пользовательские протоколы, которые могут принять Ваши классы. Протоколы являются частью Вашего инструментария программирования.
Центр уведомления: уведомление заинтересованных наблюдателей события
Центр уведомления является подсистемой платформы Основы, широковещательно передающей сообщение — уведомление — ко всем объектам в приложении, которые являются зарегистрированными наблюдателями события. (Программно, это - экземпляр NSNotificationCenter класс.) Событие может быть чем-либо, что происходит в приложении — приложение, вводящее фоновое состояние, например, или пользователя, начинающего вводить в текстовом поле. Уведомление сообщает наблюдателю, что случай произошел или собирается произойти, таким образом давая наблюдателю возможность ответить надлежащим способом. Уведомления, широковещательно переданные центром уведомления, являются способом расширить сотрудничество и сцепление среди объектов приложения.
Например, объект контроллера в приложении Mac может наблюдать уведомление NSColorPanelColorDidChangeNotification узнать как цвет, выбранный пользователем для определенной задачи. Как этот пример указывает, уведомление является объектом, имеющим имя, указывающее определенное событие и имело ли то событие место или собирается произойти. Это также переносит ссылку на объект, отправляющий (или отправляющий), уведомление центру уведомления, и это может содержать словарь дополнительной информации.
Любой объект может наблюдать уведомление, но сделать так он должен зарегистрироваться для получения его. В регистрации это должно указать селектор, идентифицирующий метод, который будет вызван поставкой уведомления; сигнатура метода должна иметь единственный параметр: объект уведомления. При регистрации наблюдатель может также указать объект регистрации.
Центральные уведомлением уведомления подобны сообщениям делегации; когда определенные события имеют место, оба отправляются в произвольные объекты. Однако методы, обрабатывающие уведомления, в отличие от методов делегации, не могут возвратить значение. И уведомление через центр уведомления синхронно, так же, как с делегацией.
Платформа AppKit определяет много методов делегации без возвращаемых значений, соответствующих уведомлениям. Если делегат реализует такой метод, он обрабатывает уведомление. Например, если делегат реализует windowDidMove: метод, это обрабатывает уведомление NSWindowDidMoveNotification.
Пользовательский объект в Вашем приложении может определить и отправить свои собственные уведомления, и другие пользовательские объекты в Вашем приложении могут наблюдать уведомление.
Действие Target: инкапсуляция сообщения, которое будет отправлено, когда событие имеет место
Проект целевого действия концептуально прост. Объектно-ориентированные памяти элементы, составляющие выражение сообщения и, когда определенное событие имеет место, соединяет эти элементы и отправляет сообщение. Элементы являются селектором, идентифицирующим сообщение (действие) и объект получить сообщение (цель). Класс цели реализует метод, соответствующий действию и цели, и когда это получает сообщение во время выполнения, реагирует на событие путем выполнения метода.
Действие Target является прежде всего функцией средств управления и в Сенсорных платформах Какао и в Какао. Управление является объектом пользовательского интерфейса, таким как кнопка, ползунок, или переключите это, пользователи управляют (путем щелчка, касаясь, перетаскивая, и т.д.) для сигнализации их намерения к приложению. Большинство средств управления Какао соединяется с одним или более объектами ячейки, хранящими цель и действие; Сенсорное управление Какао, с другой стороны, хранит и действие и цель.
Наблюдение значения ключа: уведомление наблюдателя, когда изменяется значение
Наблюдение значения ключа (или KVO) позволяет объекту наблюдать свойство другого объекта. Когда значение того свойства изменяется, объект наблюдения уведомляется. Это узнает о старом значении, а также новом; если наблюдаемое свойство к - многие отношение (например, массив), это также учится, какой из содержащих в нем объектов вовлечен в изменение. KVO помогает приложениям стать более связными путем хранения объектов в модели, контроллере, и уровни представления синхронизировались с изменениями.
Подобный NSNotificationCenter уведомления, многократные наблюдатели KVO могут наблюдать единственное свойство. Кроме того, KVO является более динамичным, потому что он позволяет объектам наблюдать произвольные свойства, не требуя никакого нового API, такие как имя уведомления. KVO является легким механизмом связи точка-точка, не позволяющим наблюдать определенное свойство всех экземпляров.
Другие проекты платформы на основе шаблонов разработки
Сенсорные платформы Какао и Какао также включают другие проекты на основе шаблонов разработки, включая следующее:
Иерархия представления. Представления приложение подарки располагаются в иерархической организации, базируемой визуально на включении. Этот образец позволяет приложениям обрабатывать отдельные представления и составы представлений унифицированно. В корне иерархии объект окна; каждое представление под тем корнем имеет одно родительское представление и нуль или больше дочерних представлений. Родительские представления включают дочерние представления. Иерархия представления является структурным компонентом и получения и обработки событий.
Цепочка респондента. Цепочка респондента является серией объектов — главным образом просматривает, но также и окна, контроллеры представления и сам объект приложения — вдоль которого могут быть переданы событие или сообщение действия, пока один объект в цепочке не обрабатывает событие. Это таким образом - механизм для совместной обработки событий. Цепочка респондента тесно связана с иерархией представления.
Регистратор. В образце Регистратора работа, которую выполняет приложение, перенаправляется — или «возвращается» — от одного контекста выполнения до другого. (Контекст выполнения является очередью отгрузки или очередью работы, связанной с основным потоком или вторичным потоком.) Вы применяете образец Регистратора прежде всего, когда работа, выполняемая во вторичной очереди, приводит к задаче, которая должна, должен быть выполнен на основной очереди — например, в операциях, обновляющих пользовательский интерфейс.
Категория. Категория предлагает Вам способ расширить класс путем добавления методов к нему. Как с делегацией, это позволяет Вам настроить поведение без разделения на подклассы. Категории являются функцией Objective C, описанного в Коде Objective C Записи.
© 2013 Apple Inc.Все права защищены. (Последнее обновление: 23.04.2013)