Приложения управляются событиями

Можно получить некоторое понимание отношения между кодом и кодом платформы путем рассмотрения того, что имеет место, когда запускается приложение. В основном приложение устанавливает ключевую группу объектов и передает управление в те объекты. Все больше объектов будет создаваться, когда программа работает, но в начале все, это требуется, является достаточным количеством структуры — т.е. достаточно сети базового объекта — для обработки начальных задач. Существует две основных задачи:

• Нарисуйте интерфейс исходного пользователя приложения.

• Обработайте события, полученные, когда пользователь будет взаимодействовать с тем пользовательским интерфейсом.

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

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

Механизм для получения и ответа на события является основным циклом событий. В группе базовых объектов приложения один объект, глобальный объект приложения, ответственен за управление основным циклом событий; это получает событие, диспетчеризирует событие объекту или объектам, которые могут лучше всего обработать его, и затем получают следующее событие. Это число иллюстрирует основной цикл событий для приложений Какао в OS X.

Используя объектно-ориентированную платформу

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

Для использования платформы необходимо принять структуру приложения, которую она определяет, и затем используйте и настройте столько же ее классов по мере необходимости для прессования определенного приложения к той структуре. Классы платформы взаимно зависят и стали группой, весьма отдельным образом. На первый взгляд потребность адаптировать Ваш код к структуре платформы для приложений могла бы казаться строгой. Но действительность как раз наоборот. Платформа предлагает Вам много путей, которыми можно изменить и расширить ее универсальное поведение. Это просто требует, чтобы Вы признали, что все приложения ведут себя теми же фундаментальными способами, потому что они все на основе той же структуры. В широком метафорическом смысле платформа Objective C походит на платформу дома, и Ваш код приложения походит на двери, окна, запасной путь и другие элементы, делающие дом уникальным.

С точки зрения использования платформы и интеграции Вашего кода с ним, существует два общих вида классов.

• С полки. Некоторые классы определяют стандартные объекты — т.е. объекты, которые готовы использоваться. Вы просто создаете экземпляры класса и используете экземпляры по мере необходимости.

• Универсальный. С универсальными классами платформы Вы можете — и должен при некоторых обстоятельствах — создают подклассы их и переопределяют реализации определенных методов. Путем разделения на подклассы их Вы вводите свой код в структуру приложения. Платформа вызывает методы Вашего подкласса в надлежащие моменты.

Разделение на подклассы универсального класса платформы является главным методом для интеграции Вашего специфичного для программы кода в структуру, предоставленную платформами. Но это не единственный метод, и во многих случаях не является предпочтительным методом. Как Вы узнаете в более поздней статье, Сенсорные платформы Какао и Какао также включают архитектуру и механизмы, все на основе шаблонов разработки, включающих расширение сотрудничества и координацию между объектами платформы и Вашими пользовательскими объектами.

При создании подкласса у Вас есть два основных решения сделать: какой класс наследовать от (суперкласс) и который методы того класса переопределения. Следующие разделы исследуют контекст для того, чтобы принять эти решения.

Наследование от сенсорного класса какао или какао

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

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

Следующее обсуждение исследует некоторые решения и стратегии, входящие в разделение на подклассы, и описывает некоторые общие требования. Это не покрывает подробно, как сделать подкласс. “Определение Класса” в Языке программирования Objective C описывает тот метод.

Переопределение метода

Возможно создать подкласс, не повторно реализующий методов суперкласса; например, подкласс мог бы добавить дополнительное состояние и определить новые методы, что доступ, которые утверждают и вызывают методы суперкласса. Однако для некоторых подклассов основная задача реализует определенный набор методов, объявленных суперклассом (или в протоколе, принятом суперклассом). Перереализация унаследованного метода известна как переопределение тот метод.

Большинство методов, определенных в классе платформы, полностью реализовано; они существуют так, чтобы можно было вызвать их для получения услуг, которые предоставляет класс. Вы редко должны переопределять такие методы и не должны пытаться. Другие методы платформы могут быть переопределены, но редко существует причина сделать так.

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

Вызвать или переопределить?

Методы платформы, которые Вы переопределяете в подклассе, обычно не будут методами, которые Вы вызовете сами, по крайней мере не непосредственно. Вы просто повторно реализуете метод и оставляете остальных до платформы. Фактически, чем более вероятно необходимо записать специализированную версию метода, тем менее вероятно необходимо вызвать его в собственном коде. В общем смысле класс платформы объявляет открытые методы так, чтобы, разработчик, можно было сделать одну из двух вещей с ними:

• Вызовите их для использования услуг, которые предоставляет класс.

• Переопределите их для введения собственного кода в модель программы, определенную платформой.

Иногда метод попадает в обе этих категории; это предоставляет ценную услугу на вызов, и это может быть стратегически переопределено. Но в большинстве случаев, если метод является тем, который можно вызвать, это полностью определяется платформой и не должно быть переопределено в коде. Если метод является тем, который необходимо повторно реализовать в подклассе, платформа имеет определенное задание для него, чтобы сделать и так вызовет сам метод в подходящее время. Это число иллюстрирует два общих типа методов платформы.

В этом числе, гипотетическом методе Вашего пользовательского класса (myMethod) вызовы setNeedsDisplay метод, реализованный платформой. Платформа выполняет некоторую работу для установки среды для рисования и затем вызывает объявленный платформой метод drawRect:, который переопределяется пользовательским классом, чтобы сделать фактическое получение.

Переопределение метода не должно быть грандиозной задачей. Можно часто вносить существенное изменение в поведении суперкласса тщательным переопределением метода, влекущего за собой не больше, чем одну или две строки кода.

Вызов реализации суперкласса

При переопределении метода платформы необходимо решить, заменить ли поведение унаследованного метода или расширить или дополнить то поведение. Если Вы хотите заменить существующее поведение, просто обеспечьте свою собственную реализацию метода; если Вы хотите расширить то поведение, вызовите реализацию суперкласса и обеспечьте Ваш собственный код.

Вы вызываете реализацию суперкласса путем отправки того же сообщения, вызвавшего метод к super. Путем отправки сообщения в super, Вы «включаете» код суперкласса для того метода в Ваше переопределение при вызове. Например, скажем, то, что гипотетическое Celebrate класс определяет названный метод performFireworks. После того, как платформа рисует и анимирует фейерверк в представлении, Вы хотите вывести на экран баннер в представлении. Следующее число иллюстрирует как вызов super работы в этом случае:

Таким образом, решение вызвать super основывается, как Вы намереваетесь повторно реализовать метод:

• Если Вы намереваетесь дополнить поведение реализации суперкласса, вызвать super.

• Если Вы намереваетесь заменить поведение реализации суперкласса, не вызывать super.

При дополнении поведения суперкласса другое важное рассмотрение состоит в том, когда вызвать реализацию суперкласса метода. Вы могли бы хотеть, чтобы код суперкласса сделал свою вещь, прежде чем Ваш код будет выполнен, или наоборот.