Объектное моделирование
Этот раздел определяет условия и представляет примеры объектного моделирования и значения ключа, кодирующего, которые являются определенными для привязки Какао и Базовой платформы Данных. Понимание условий, таких как ключевые пути является основным принципом использования этих технологий эффективно. Если Вы плохо знакомы с объектно-ориентированным проектом или кодированием значения ключа, этот раздел рекомендуется, читая.
При использовании Базовой платформы Данных Вам нужен способ описать Ваши объекты модели, который не зависит от представлений и контроллеров. В хорошем допускающем повторное использование проекте для представлений и контроллеров нужен способ получить доступ к свойствам модели без внушительных зависимостей между ними. Базовая платформа Данных решает эту проблему путем заимствования понятий и условий от технологии базы данных — в частности, модель сущностей и связей.
Моделирование связи сущностей является способом представлять объекты, обычно раньше описывал структуры данных источника данных в пути, позволяющем тем структурам данных быть отображенными на объектах в объектно-ориентированной системе. Обратите внимание на то, что моделирование связи сущностей не уникально для Какао; это - популярная дисциплина с рядом правил и условиями, документирующимися в литературу базы данных. Это - представление, упрощающее хранение и извлечение объектов в источнике данных. Источник данных может быть базой данных, файлом, веб-сервисом или любым другим персистентным хранилищем. Поскольку это не зависит ни от какого типа источника данных, это может также использоваться для представления любого вида объекта и его отношения к другим объектам.
В модели сущностей и связей объекты, содержащие данные, вызывают объектами, компоненты объекта вызывают атрибутами, и ссылки на другие переносящие данные объекты вызывают отношениями. Вместе, атрибуты и отношения известны как свойства. С этими тремя простыми компонентами (объекты, атрибуты и отношения), можно смоделировать системы любой сложности.
Какао использует измененную версию традиционных правил моделирования связи сущностей, упомянутого в этом документе как объектное моделирование. Объектное моделирование особенно полезно в представлении объектов модели в шаблоне разработки Model-View-Controller (MVC). Это не удивительно, потому что даже в простом приложении Какао, модели являются обычно персистентными — т.е. они сохранены в контейнере данных, таком как файл.
Объекты
Объекты являются объектами модели. В шаблоне разработки MVC объекты модели являются объектами в Вашем приложении, инкапсулирующими указанные данные и обеспечивающими методы, воздействующие на те данные. Они являются обычно персистентными, но что еще более важно, объекты модели не зависят от того, как данные выведены на экран пользователю.
Например, структурированный набор объектов модели (объектная модель) может использоваться для представления клиентской базы компании, библиотеки книг или сети компьютеров. Библиотечная книга имеет атрибуты — такие как заголовок книги, число ISBN и дата авторского права — и отношения к другим объектам — таким как участник библиотеки и автор. В теории, если части системы могут быть идентифицированы, система может быть выражена как объектная модель.
Рисунок 8-1 показывает объектную модель в качестве примера, используемую в приложении для управления сотрудником. В этой модели Отдел моделирует отдел, и Сотрудник моделирует сотрудника.
Атрибуты
Атрибуты представляют структуры, содержащие данные. Атрибут объекта может быть простым значением, таким как скаляр (например, integer, float, или double значение), но может также быть структура C (например, массив char значения или NSPoint структура) или экземпляр примитивного класса (такой как, NSNumber, NSData, или NSColor в Какао). Неизменные объекты такой как NSColor обычно считаются атрибутами также. (Обратите внимание на то, что Базовые Данные исходно поддерживают только определенный набор типов атрибута, как описано в Ссылке класса NSAttributeDescription. Можно, однако, использовать дополнительные типы атрибута, как описано в Нестандартных Персистентных Атрибутах в Базовом Руководстве по программированию Данных.)
В Какао атрибут обычно соответствует переменной экземпляра модели или методу доступа. Например, Сотрудник имеет firstName, lastName, и salary переменные экземпляра. В приложении для управления сотрудником Вы могли бы реализовать табличное представление для отображения набора объектов Сотрудника и некоторые их атрибуты, как показано на рисунке 8-2. Каждая строка в таблице соответствует экземпляру Сотрудника, и каждый столбец соответствует атрибуту Сотрудника.
Отношения
Не все свойства модели являются атрибутами — некоторые свойства являются отношениями к другим объектам. Ваше приложение обычно моделируется многократными классами. Во время выполнения Ваша объектная модель является набором связанных объектов, составляющих граф объектов. Это обычно постоянные объекты, которые Ваши пользователи создают и сохраняют к некоторому контейнеру данных или файлу прежде, чем завершить приложение (как в основанном на документе приложении). Отношения между этими объектами модели могут быть пересечены во время выполнения для доступа к свойствам связанных объектов.
Например, в приложении для управления сотрудником, существуют отношения между сотрудником и отделом, в котором сотрудник работает, и между сотрудником и менеджером сотрудника. Поскольку менеджер является также сотрудником, отношение сотрудника-менеджера является примером рефлексивного отношения — отношение от объекта до себя.
Отношения по сути двунаправлены, так концептуально, по крайней мере, существуют также отношения между отделом и сотрудниками, работающими в отделе, и сотруднике и прямых отчетах сотрудника. Рисунок 8-3 иллюстрирует отношения между Отделом и объектом Сотрудника и Сотрудником рефлексивное отношение. В этом примере отношение «сотрудников» объекта Отдела является инверсией отношения «отдела» объекта Сотрудника. Возможно, однако, для отношений быть пригодным для навигации только в одном направлении — для там, чтобы не быть никакой обратной связью. Если, например, Вы никогда не интересуетесь нахождением из объекта отдела, какие сотрудники связаны с ним, то Вы не должны моделировать то отношение. (Обратите внимание на то, что несмотря на то, что это - истина в общем случае, Базовые Данные могут наложить дополнительные ограничения по общему объектному моделированию Какао — не моделирование инверсии нужно считать чрезвычайно расширенной настройкой.)
Кардинальность отношения и владение
Каждое отношение имеет кардинальность; кардинальность говорит Вам, сколько целевых объектов может (потенциально) разрешить отношение. Если целевой объект является отдельным объектом, то отношение вызывают к - одно отношение. Если может быть больше чем один объект в месте назначения, то отношение вызывают к - многие отношение.
Отношения могут быть обязательными или дополнительными. Обязательное отношение является тем, где место назначения требуется — например, каждый сотрудник должен быть связан с отделом. Дополнительное отношение, как имя предполагает, дополнительный — например, не, у каждого сотрудника есть прямые отчеты. Так directReports отношение, изображенное на рисунке 8-4, является дополнительным.
Также возможно указать диапазон для кардинальности. Дополнительное к - одно отношение имеет диапазон 0-1. У сотрудника может быть любое число прямых отчетов или диапазон, указывающий минимум и максимум, например, 0-15, который также иллюстрирует дополнительное к - многие отношение.
Рисунок 8-4 иллюстрирует кардинальность в приложении для управления сотрудником. Отношение между объектом Сотрудника и объектом Отдела является обязательным к - одним отношением — сотрудник должен принадлежать одному, и только одному, отделу. Отношение между Отделом и его объектами Сотрудника является дополнительным к - многие отношение (представленный «*»). Отношение между сотрудником и менеджером является дополнительным к - одним отношением (обозначенный диапазоном 0-1) — у высокопоставленных сотрудников нет менеджеров.
Отметьте также, что целевые объекты отношений иногда принадлежат и иногда совместно используются.
Доступ к свойствам
Для моделей, представлений и контроллеров для независимого политика друг от друга необходимо быть в состоянии получить доступ к свойствам в пути, который независим от реализации модели. Это выполняется при помощи пар ключ/значение.
Ключи
Вы указываете свойства модели с помощью простого ключа, часто строка. Соответствующее представление или контроллер используют ключ для поиска соответствующего значения атрибута. Этот проект осуществляет понятие, что сам атрибут не обязательно содержит данные — значение может быть косвенно получено или получено.
Кодирование значения ключа используется для выполнения этого поиска; это - механизм для доступа к свойствам объекта косвенно и, в определенных контекстах, автоматически. Кодирование значения ключа работает при помощи имен свойств объекта — обычно его переменных экземпляра или методов доступа — как ключи для доступа к значениям тех свойств.
Например, Вы могли бы получить имя объекта Отдела, использующего a name ключ. Если Отдел возражает, или имеет переменную экземпляра или вызванный метод name тогда значение для ключа может быть возвращено (если это не имеет также, ошибка возвращается). Точно так же Вы могли бы получить атрибуты Сотрудника с помощью firstName, lastName, и salary ключи.
Значения
Все значения для определенного атрибута данного объекта имеют тот же тип данных. Тип данных атрибута указан в объявлении его соответствующей переменной экземпляра или в возвращаемом значении его метода доступа. Например, тип данных объекта Отдела name атрибут может быть NSString объект в Objective C.
Обратите внимание на то, что кодирование значения ключа возвращает только объектные значения. Если тип возврата или тип данных для определенного метода доступа или переменной экземпляра, используемой для предоставления значения для указанного ключа, не являются объектом, то NSNumber или NSValue объект создается для того значения и возвращается в его месте. Если name атрибут Отдела имеет тип NSString, тогда, с помощью кодирования значения ключа, значение возвратилось для name ключ объекта Отдела NSString объект. Если budget атрибут Отдела имеет тип float, тогда, с помощью кодирования значения ключа, значение возвратилось для budget ключ объекта Отдела NSNumber объект.
Точно так же при установке значения с помощью кодирования значения ключа если тип данных, требуемый надлежащим средством доступа или переменной экземпляра для указанного ключа, не является объектом, то значение извлечено из переданного объекта с помощью надлежащего -ввестиValue метод.
Значение к - одно отношение является просто целевым объектом того отношения. Например, значение department свойство объекта Сотрудника является объектом Отдела. Значение к - многие отношение является объектом коллекции. Набор может быть набором или массивом. При использовании Базовых Данных, это - набор; иначе, это обычно - массив), который содержит целевые объекты того отношения. Например, значение employees свойство объекта Отдела является набором, содержащим объекты Сотрудника. Рисунок 8-5 показывает граф объектов в качестве примера для приложения для управления сотрудником.
Ключевые пути
Ключевой путь является строкой разделенных от точки ключей, указывающих последовательность свойств объектов для пересечения. Свойство первого ключа определяется, и каждый последующий ключ оценен относительно, предыдущее свойство. Ключевые пути позволяют Вам указывать свойства связанных объектов в пути, который независим от реализации модели. Используя ключевые пути можно указать путь через граф объектов, любой глубины, к определенному атрибуту связанного объекта.
Значение ключа, кодирующее механизм, реализует поиск значения, данного ключевой путь, подобный парам ключ/значение. Например, в приложении управления сотрудника Вы могли бы получить доступ к имени Отдела через объект Сотрудника использование department.name ключевой путь, где department отношение Сотрудника и name атрибут Отдела. Если Вы хотите вывести на экран атрибут целевого объекта, ключевые пути полезны. Например, представление списка сотрудников на рисунке 8-6 сконфигурировано для отображения имени объекта отдела сотрудника, не самого объекта отдела. Используя привязку Какао, значение столбца Department связывается с department.name из Сотрудника возражает в выведенном на экран массиве.
Не каждое отношение по ключевому пути обязательно имеет значение. Например, manager отношение может быть nil если сотрудником является CEO. В этом случае механизм кодирования значения ключа не повреждается — он просто прекращает пересекать путь и возвращает надлежащее значение, такой как nil.